One misconception I encounter more frequently than I’d like is the belief that a software engineer only “builds” when they’re actively typing code.
Aspiring programmers transitioning from hobbyist to professional often discover that the essence of a software engineering career encompasses much more than just coding, including a wide range of skills and responsibilities beyond purely programming.
Depending on your project’s stage (or your role or the team or stage in your career), you might spend most of your time on lots of other tasks: talking to customers, creating prototypes, designing architecture plans, communicating those plans, documenting, gathering requirements, testing, assessing risks, etc
Yet, even experienced engineers will sometimes describe this work as “just doing X, Y, and Z before we start building.” I understand why we frame it this way—it feels like the real construction happens when our hands are on the keyboard.
However, I wish we wouldn’t do this because it can create the impression that we’re not doing what we’re paid for or what’s necessary for our jobs. By downplaying these other activities, we send the wrong message to stakeholders and people who don’t know better. It cheapens the other essential and often difficult time-consuming work.
So let’s not do that. All those other tasks—basically planning activities—are part of building too. It’s not just when you’re writing code for the production environment.