What They Didn’t Teach You About Being a Software Engineer

According to the author’s personal experience, most professional software developers rarely write entire applications from scratch; instead they spend the majority of their time fixing bugs, navigating massive legacy codebases, and collaborating with teammates to understand existing implementations.

The piece stresses that deep domain knowledge—whether in banking, restaurant POS systems, or logistics—is far more valuable than merely knowing algorithms, because it enables engineers to contribute meaningfully and transition easily between related jobs.

Documentation is often overlooked in university curricula, yet writing clear, maintainable code and comprehensive docs saves significant time and effort when working with others’ code.

Code itself is considered a secondary tool; the primary goal for engineers is to deliver business value, turning software into solutions that users find useful, while ensuring the code remains reliable and scalable.

The author discusses strategies for dealing with incompetent colleagues, such as focusing on efficiency, recording evidence, seeking additional resources, delegating tasks, implementing fallback mechanisms, and confronting issues directly without becoming a “jerk.”

Uncertainty is a constant in software development—requirements are often vague, stakeholders change their minds, and engineers must spend weeks gathering and clarifying specifications before writing the first line of code.

Assuming that all software components, third‑party libraries, operating systems, and even hardware can fail encourages developers to design fault‑tolerant systems, improving overall reliability.

In conclusion, aspiring software engineers should accept these realities, embrace continuous learning, and remember to stay true to their passion while navigating the challenges of the profession.