Code Audience
2024-12-03
When I talk about my job to people who aren’t software engineers (which is almost everyone), they often assume that the hardest part of software engineering is writing code. I understand why they think that; writing code is indeed a significant barrier to entry in this profession. To explain, I use an analogy: it’s like being an author of a novel. Being able to read and write is essential, but it’s just the medium used to create stories, characters, and ideas.
I’d like to expand on this analogy in written form, so I don’t bore people face-to-face. It’s fascinating that what we write is a trade-off for multiple audiences, and this serves as a useful indicator of a software engineer’s expertise.
Computers
Obviously, the primary intention is for computers to execute our code. We must use a language they understand, with no tolerance for ambiguity or syntactical errors. This is the first phase of a software engineer: learning to write code.
Humans
In companies, software development is a team sport. Whatever one person writes is reviewed and expanded upon by others. Humans can tolerate some ambiguity but have limited abilities to reason about complex systems. Therefore, it’s a good idea to reduce complexity by categorising functionality so it can be abstracted (e.g., a front-end and a back-end), adhering to standards (e.g., linters and architectural patterns), and using consistent approaches throughout the codebase. This is the second phase of a software engineer: learning to build software.
The Future
Products grow, and requirements change. Software is often tweaked, updated, and built upon. What we write today can significantly impact the ease of development tomorrow. The ability to predict future requirements and build accordingly is an extremely valuable skill, it can mean the difference between a simple update or a significant refactor.
This skill requires a good understanding of your product so you can predict possible requirements. You need a strong understanding of software cost and business impact to make efficient trade-offs and justify spending extra time future-proofing certain features. You need influence among product decision-makers so you can guide them towards a future where product requirements and software capabilities align. This is the third phase of a software engineer: learning to build a company.