It’s unhealthy, unsustainable, and wrong to think of a programmer as being a “translator” who merely translates a specification, written by someone else, into computer code.

There is no historical precedent from other professions of working this way. If we look at other professionals who master an advanced body of knowledge, like attorneys or a medical doctors, then they discuss directly with their client, without an intermediate layer of managers or bureaucracy, and listen to their client’s needs and apply their body of knowledge to help solve the client’s problem in the best possible way.

From a supply/demand perspective, then if we look at writing code as an isolated skill, then this is becoming easier and easier to learn (due to easier languages, richer framework, and amazing tooling), which means that the barrier of entry is continually lowered, which increases the supply and competition.

Moreover, the rise of low-code/no-code tools gives even more people the ability to perform coding-like tasks. And a last thing that boosts the supply is that the COVID lockdown taught even the most conservative company that working remotely is feasible, so they can hire in many new locations. Right now we have a hot job market, but historically those things don’t last forever, unfortunately.

So in a world where the supply of generic coding skills increases, how can programmers differentiate themselves from the competition?

I think the key is to learn the business of their company — and then start to think of themselves as, primarily someone who solves business problems, and secondarily, someone who solves these problems by writing code.

How does a programmer create value?

Code has no inherent business value in itself. Code only adds value when it contributes to solving a business problem; for example, automating a task, which previously required expensive manual work, which reduces the operating cost of the company, which increases the bottom line.

Now, it would be easy to say that a Business Analyst / Product Manager should be the one understanding the business and then handover a detailed specification over to the programmer who can then translate the specification into code.

However, in my view, a natural evolution is already happening:

• A company used to have backend developers, frontend developers, and maybe even DBAs.
• This made sense because everything was really complicated; for example, memory leaks in C++ could give even the most chilled programmer gray hairs, and operating an Oracle Database was so non-intuitive that it required a dedicated, full-time specialist to keep it running.

However, everything is becoming easier, from automatic memory management to DBaaS.

Why we got Product Teams and Full-Stack Engineers

During the last ten years, we have seen the rise of Full-Stack Engineers and Product Teams (instead of Technology Teams), because:

1. It’s actually possible to master the full stack, because developing comparable functionality becomes easier and easier as we evolve forward.
2. Because a full-stack engineer can deliver complete features (rather than a “layer” of it), which is insanely important from a business perspective, because this increases speed to market — as there are fewer handovers and less coordination — which means that the feature can get into production faster and generate business value sooner and seize business opportunities before they vanish or are seized by a competitor.

The coming rise of the Full-Stack Product Engineer

I think the next natural evolutionary step after the Full-Stack Engineer role is that the Full-Stack Engineer and Product Manager (or Business Analyst, at first) will slowly start to merge together into a single role, meaning that we end up with a person who can talk with the business or customers to understand their problem, and also write the code to solve the problem. In my view this is a natural state of things that aligns with how other professions with an advanced body of knowledge operates.

I feel the need — the need for speed!

Why is this beneficial? Two reasons: (1) Because we can get an even faster speed to market – from idea to production – due to even fewer handovers and even less coordination – and speed becomes evermore important to businesses in our fast-changing world, and (2) many “micro decisions” need to be taken when writing code and the more an engineer knows about the business context, the better (micro) decisions they can take.

So my recommendation is to really learn the business domain that you are writing code for. Don’t wait for someone to teach you, actively pursue the knowledge. This will both make you more valuable to your business right now, because you can make better “micro decisions” and can communicate more easily. And you will be aligned with the long-term evolutionary trend of software development.