Being a “professional” software engineer is distinct from tinkering with projects in your garage. It can take some time to fully appreciate this distinction.

This morning, while sipping my milk, I came across this article and it made me chuckle.

Many of us are familiar with this journey, and it made me reflect on who I was ten years ago, when I first started being a professional software developer—that is, being paid by someone to create stuff and solve problems.

I wanted to share some of my own reflections in addition to what Chris wrote.

Get the big picture

Being an engineer isn’t just about dealing with tech stuff or ensuring that your part works as planned. You need to see the big picture. Understand what you’re doing, why you’re doing it, for whom, and in what context. This understanding will enable you to make better decisions and suggestions.

We don’t live in a perfect world with unlimited time and resources. Realizing this has helped me become less stubborn and accept that sometimes, we must do our best with what we have before achieving the ideal.

Behave like engineers, not preachers or sheep

Don’t adopt or advocate for a technology just because you’ve heard it’s powerful or because it’s what you’re accustomed to. You are not a “Java Developer” or a “React Developer”; you are a developer. Just like a mechanic isn’t defined by their use of a screwdriver or hammer.

Always explain why your suggestion is the best fit for the problem your team is trying to solve, even if it’s for the tenth time. And be open to challenges; it’s not personal.

I believe that part of why engineers in other fields may not view us as “real” engineers is because we’re often not good at this aspect. Preaching is not scientific, and engineering requires some solid scientific foundation. The “cargo cult” Chris mentions is symptomatic of this issue.

Communicate with humans, not machines

We are, in a way, scribes. Each time we write code, we’re inscribing a tiny part of history.

Writing code is the culmination of a process agreed upon by people to accomplish something that will operate on a machine. You’re the one bringing it to life.

The codebase is the ultimate specification shared between machines and humans; both need to understand it equally. While the computer executes the code, future developers need to grasp your intent. You’re speaking to the future.

We are no longer using hieroglyphs in real life, but many of us like to use them when writing code. Use words in your code, not fancy symbols and acronyms for the sake of saving few characters, we don’t care, we have giant screens nowadays. By doing so, you will save a lot of time for your future colleagues.

A codebase should be read like a book without needing to consult the documentation to understand what a function or a piece of code does, this is the documentation.

Architecture and testing above anything else

With a solid architecture at both the application and system levels, and a robust (automated) testing strategy, you can address many of the most critical issues that software/platforms may face over their lifespan.

Good architecture means you won’t need to overhaul a large part of the system when making changes. Automated testing gives you the confidence to modify aspects without fear of breaking existing features.

Don’t misunderstand; other aspects are important, too. However, neglecting these two areas can be exceedingly costly in the long run.

And that’s all for today. There’s more to discuss, but these are the insights I wanted to share for now!