"You are not a software engineer" - What am I then?

The job of software engineer, or any technical role for that matter, is extensive. You might spend more time than you would like on meetings, you might spend your afternoon sending emails to your stakeholders, you might actually only get to write code for a couple of hours a day. Depending on your personality type, this can make you thrilled or make you unhappy. I am writing this for the latter. In this article, I offer a different view, in which our job is solving business problems and making our customers happy, while coding is only a marginal tool in this context. I have perhaps hit a nerve with this one, but this mindset is even more important when working as a service provider. So please take a moment to listen.

"But I am a coder, I don't want to deal with any of this."

Yes, I understand and I am too. Coding is fun, coding challenges us, coding is the reason most of us embarked on this journey. But, if you think about it, code is made primarily for human consumption. Yes, machines need to understand it as well, but if it wasn't for the people, we would still write in assembly, or binaries even. When you throw in daily collaboration with your team, managers, and clients, your job is really about dealing with people, not computers.

Let me put it this way. You may put in the work and produce 10,000 lines of the cleanest, most optimised code there possibly is. But if it doesn't bring value to the business, you might as well throw it away.

What is your drive?

You don't want to just play around and not produce anything of worth to someone, I hope.

According to recent models of motivation ("Drive" by Daniel Pink), our actions are fuelled by autonomy, mastery, and purpose.

In healthy working environments, autonomy is easy. You have the power to decide how to implement the solution, to choose the way of working that enables you to do this, and to influence decisions.

Mastery is the urge to improve your skill set and be proud of all the work you have done. This motivates us. To change projects, gather new experiences and work with new technologies. Since the field of IT is a fast-moving freight train, I assume you are already doing this.

Purpose can be tricky, though. The desire to do something that is of meaning and importance, greater than ourselves. Maybe helping an already successful enterprise earn 5% net profit more than in the previous year is not your thing. Maybe you want to help humanity find the cure for cancer. Boarding on some ideas is easy, while for others it is not. I will not provide an answer to this. It is entirely up to you. I will give you a hint though. It is everywhere. It involves feelings.

"I am in the business of creating value."

If your code fails to bring value, whose fault is that?

Remember the cost of fixing a bug, depending on the stage of the software development lifecycle. An hour spent in requirements engineering will save you many more down the road. You might use a framework designed to prevent this from happening, prescribing you the points in time when you should do requirements engineering. But, all the magical frameworks in the world will not help you if you don't understand what you are building.

"I am in the business of satisfying customers."

If you consider yourself to be a one-man business, your customer is every person you interact with. Your customers are your team members, management, stakeholders, users. Keeping them happy is of importance for your business, even if you need to make a couple of trade-offs. Sometimes, you might feel disconnected from the customer. Either he is really busy and doesn't come by, or you see him perhaps once, at a release review. Establishing that link creates a fertile ground for collaboration. Having it is your right, and responsibility.

Anybody can code

After all, we live in a world where anybody can code.

"Have you heard? The other supplier was X times cheaper".

All over the world, you can find coders capable of writing code. And doing it cheaply!

Why would the customer choose you, over another provider?

"We use sound design principles, and our architecture is flawless!"

Yes, kudos for that, you should really maintain that. Selling your work like that totally makes sense - if all your customers are engineers. To others, that doesn't mean much. The fact that we are proud of our work is not a good selling point - considering the end result is the same: working software.

Own the market

As competing on price is not an option, we might just have a few other tricks up our sleeve. If the customer enjoys working with you because you communicate more clearly, you understand his business and you are actively helping him in making better decisions for his business; these are the skills that make a difference.

By Stefan Djelekar