Being a Software Engineer is not about writing code

Over the last ~13 years of being a being in the Software Engineering business, I've had many conversations with people about people's passion for the business. The typical answers I received about their passion were along the lines of:

• The thrill of chasing some obscure bug, and fixing it;

• Having a piece of software built at the end and being proud about it;

• They were able to make something faster or cost fewer resources and they liked squeezing all the performance they were able to.

And when you talk about what frustrates them in their work, I've come to expect answers like:

• Lack of quality in the software or needing to deal with a legacy system;

• Meetings;

• Being distracted by questions or ad-hoc requests, preventing them to get into a flow state of mind.

When I summarise their answer that they believe being an effective Software Engineer is about writing code, the answer has almost always been yes. And this is where I disagree.

I believe the job we as Software Engineers fulfil for our bosses or clients is not to write code. Writing code is the tool we use to earn our pay, not the primary product we deliver for them. We also wouldn't say that a carpenter's job is about sawing and hammering nails into wood, just like we wouldn't say that a teacher's job is about standing in front of a group of people talking. This is all confusing the thing we do and the tools we use, for the added value we deliver for the one that pays our salary.

So what does the person who holds the pursestring care about when deciding to hire a Software Engineer? I would say they care about having their problems solved and that things get better over time.

Why do I believe this distinction to be important to write this blog about? Because I believe the attitude of 'Software Engineering is about writing code' is optimizing for the wrong thing and that it's, in the long run, hurting your career growth.

Some examples:

• The boss comes to the team and tells you to build a tool to calculate the cost for projects they do. Sure, you could pull out your IDE and build a snazzy React Web app hosted in AWS, powered by a Serverless solution. Or you could instead create a spreadsheet and onboarding documentation such that the boss how to update it when changes are required.

• Harry from sales comes knocking at your desk and asks if we could build a labelling mechanism into our product because customers have been asking about it. Yes you say, and after some time you build this thing. Or instead, you could ask why the customers ask for labelling (play the "5 why's"-game if you have to) to identify the actual problem at the root of this request and suggest a more effective alternative that goes beyond solving just symptoms.

• You are so frustrated by the legacy code base that keeps slowing you down every day, that you decide to walk up to the project manager and complain about how shitty their code is, that it's slowing you down in the code you need to write and suggest to consider some alternative architecture. The project manager answers that this inconvenience doesn't sound like a priority right now. Or you could instead have presented that the product's future growth is stagnating and the time between releases is increasing and you are worried about losing our competitive edge and ask if we should do anything to mitigate this risk.

Any business will have problems they rather would not want to deal with, and solving this pain has some form of value to them. And this is where you (and any other employee working at that company) come in. And their paying customers similarly have problems they are willing to pay to have solved by that business. This is where the whole 'adding value' is coming from I believe.

And business typically wants to scale due to their profit motive. Besides that this is a problem statement all in itself, software has this awesome property to be easy to change (if designed well!) and therefore can be adjusted over time to do more with less over time as you better understand the underlying problem being solved by your business.

I believe that at the heart of understanding how you add value to a company you are enabling yourself to make a bigger impact, rise through the ranks faster and expose yourself to more growing opportunities. All this because you aim to truly understand the needs of your employer and optimise for that. And probably you'll still be able to also optimise your satisfaction too, as you can see that the stated likes above in the article synergise nicely!