How one question stumped me and made me rethink my career
As I thought about the question and prepared my answer, I noticed something about the response I was going to give. If you had asked me this question earlier in my career I would have said something such as testing your code, building applications in a specific architecture, or building a highly scalable fault-tolerant widget. While these still hold true, they aren’t the first things that come to my mind when I think about software now.
I boiled my thoughts down to three aspects that capture what software engineering means to me.
The engineer sat in a dark room, alone, frantically clicking away on their keyboard, which was dimly light from the light of their monitor. This is the stereotype and image many people imagine when they think about people in the software industry, and it couldn’t be farther from the truth.
Whether it is a project overview meeting, weekly check-ins (or sometimes the overbearing daily stand-ups — looking at you scrum), or the sea of email threads, the software engineering process will have you engaging with many people across many teams.
As modern software evolves we find ourselves picking up specialized paths. You may be a backend engineer who may have to talk to the frontend team about integrating or the devop team on how to get your backend to production. You will also find yourself talking with product managers or clients discussing due dates and possible blockers. Software engineering can be quite chatty, and this always surprises newer engineers in the industry. (I know I was!)
This communication is not to be viewed as a negative because it directly relates to my next aspect of software engineering.
I have met very few engineers who work in a complete vacuum without ever having to work with fellow colleagues. As an engineer, you can expect to be in constant collaboration with your team. This can range from doing code reviews to bouncing possible solutions to a problem. You will always be working with other engineers in some form.
This collaborative effort, in my opinion, is what makes software engineering fun. If you are stuck on a problem, you can grab a fellow engineer and try to come up with a solution. I can not tell you how many times I was stuck on a for a long time only to have ten-minute whiteboarding not only solve my problem but come up with a solution I would have never considered.
This leads me to another point of collaboration. Working with brilliant and talented engineers gives you the benefit to grow your skill set as well. Code reviews always seem daunting but the collaboration of the review can only help you spot mistakes and learn from others.
The final application/product that we delivered to the world didn’t just appear. There were a lot of collaborative efforts that had many teams and people communicating to ultimately deliver some form of documentation.
This documentation could be as simple as API contracts on how users can interact with it or it can be more detailed as a design document for a new development feature. Regardless of which one it may be documentation is critical to a successful software engineering process.
In my experience, the earlier documentation is done the better the overall software process will be. The purpose of the documentation is to formalize what the end goal could be. It may seem cruel at first, but in the initial stages of documentation, teams should look to poke holes in it.
It is much easier to find issues and course-correct before the product is made public and making changes may mean breaking changes. Having this documentation also allows teams to cooperate and cross communication with stakeholders throughout the entire software process.