ChatGPT already knows - Part 5

In the previous post, we examined how the omnipresent hyper-specialization in IT pushes software engineers into areas of human weaknesses and how nerd culture (involuntarily) reinforces the push. We also collected a little list of ideas how we can position ourselves as software engineers, aligned with humans strengths, preserving our value as software engineers in the face of modern AI solutions.

In this post, we will discuss the first 6 items from the list at the end of the previous post, what it needs to become a “full-range engineer” (and of cause explain what “full-range engineer” means).

Leaving the comfy chair

The first five ideas basically prime the sixth, central idea. Hence, I will discuss the first five ideas together in this section. They are all about leaving the comfy software engineer chair our encompassing system put us into or we voluntarily chose to sit in (because it was the line of least resistance).

The first thing we need to do to become more effective is to understand the non-IT domains we interact with and are affected by. We cannot effectively navigate in a complex and ambiguous environment if we have no idea what the other stakeholders are talking about. Hence, understanding other domains is a prerequisite.

We need to understand the business domain, finance, sales and marketing, management, controlling, compliance, security and so on. If we are developers, we need to understand operations. If we work in operations, we need to understand software development. Etcetera.

This does not mean we need to become experts in all those domains. This is not possible. But we need to understand these domains good enough we can effectively communicate with experts from those domains and understand what they are saying – not only hear the words, but also understand their meaning.

Then we need to embrace complexity, uncertainty and ambiguity. This is probably the hardest part. Most people prefer simple settings with clear rules without ambiguity. We feel safe in such settings. This is a primeval preference deeply ingrained in human nature. As already written in a previous post, it helped us to survive as a species in past times.

Still, it does not help. The world of today is complex, messy, ambiguous at best, often simply inconsistent. This is also reflected in our work environments. Simple solutions for complex problems do not exist. If someone tells you, you only need to follow simple and clear rules, you are not part of the solution but just a cog in someone else’s game. ¹

Hence, better start to accept that simple and obvious rarely helps, long-term planning does not work, signals are often not what they appear to be and control is an illusion (the last part is hardest to accept – I also struggle with that one from time to time). ²

We do not need to love this. It is okay if we feel uncomfortable with it from time to time. But if we accept it, we are able to see differently and to act differently. We are able to respond differently to situations, we detect earlier if something starts to drift in the wrong direction. We start to see systems, interaction patterns and feedback loops where other people just see rules and processes. We become more effective.

The next part of our journey towards effectiveness is to improve our communication and collaboration skills as well as our empathy. Communication and collaboration sucks in most companies. There are endless meetings, but the information flow is a small trickle at best because people do not listen properly, communicate poorly, do not understand what is important to the other person, do not collaborate in a reliable way, and so on. So much communication goes nowhere. So much energy is wasted. (And we have not even started with company politics.) ³

If we learn to communicate better, we will become better at sending and receiving information. Training empathy means to better understand the motivations of our peers, their needs and pains. This does not mean we need to sympathize with everyone. Sometimes, the motivations of other people simply conflict with our motivations. But we will understand a lot better what drives our peers, what their words actually mean and how to reach them when talking to them. We won’t be communication bottlenecks anymore (if we were before) and people will like working with us because they know we communicate reliably. And we can also help mitigating some other communication bottlenecks if we detect them.

Be aware that better communication and collaboration skills include people outside our teams, including non-IT people. Most software engineers are quite good at communicating and collaborating with their team peers. Interacting with people outside this small trusted group of people often is a very different story.

All these activities help to broaden our area of effectiveness, i.e., where and to what extent we can work effectively in an environment we as software engineers typically live in. Again, this list is not exhaustive. Thus, we always need to keep our eyes open, to ask ourselves in which areas we are not yet effective and what we can do to improve our effectiveness. Being open-minded and a bit curious certainly helps on this journey.

Shouldn’t we rather focus on efficiency?

A note about efficiency before moving on: I always wrote about improving our effectiveness. Shouldn’t I rather give advice how to improve our efficiency?

In short words: No.

Today’s working world is obsessed with efficiency, putting huge amounts of time, money and resources into making pointless, often even counterproductive work more efficient. Before we need to think about efficiency, we first need to become effective. Effectiveness is about doing the right thing (needed to solve the task at hand). Efficiency is about doing the thing right (minimizing resource consumption for a given unit of work).

As Dr. Russ Ackoff once said citing his friend and colleague Peter Drucker:

Peter Drucker made a very fundamental distinction between doing things right and doing the right thing. […] Doing the wrong thing right is not nearly as good as doing the right thing wrong.

It is completely pointless being obsessed with efficiency if we are doing the wrong thing. In IT in general and software engineering in particular we are doing so many wrong things in highly efficient ways, piling up more and more accidental complexity along these ways that I wrote a whole 15 part blog series about it. Thus:

Efficiency is not our problem. A lack of effectiveness is.

Thus, if we want to preserve our value of software engineers, if we really want to make a difference competing with modern AI solutions in a highly complex, uncertain and ambiguous environment, we need to focus on effectiveness. Efficiency will follow naturally.

Additionally, AI solutions may be highly efficient in their area of expertise, but they have no idea of effectiveness. They do what they are told to do. But they do not have any idea if it was the right thing to do or not, if they are effective or not. We as humans are able to make such distinctions. But we need to leave our comfy chair and do our homework to become effective.

Become a “full-range engineer”

The ideas discussed in the previous sections are kind of a prerequisite for becoming what I like to call a “full-range engineer”. I deliberately chose that term to contrast it with the highly popular “full-stack engineer”.

While “full-stack engineer” is all the rage at the moment, in the end it means nothing than being a more efficient feature coding machine.

Sorry for sounding harsh but from the perspective of decision makers who may ponder in the relatively near future if they want to replace you with an AI solution, it is exactly like this: “Full-stack engineer means I do not need to hire a frontend engineer, a backend engineer and a database engineer. I only need to hire a single engineer and can employ them wherever needed. Get three engineers at the price of one. More efficiency. Yay!”

That is what decision makers tend to hear if they hear “full-stack engineer”, no matter what it means to you: More efficiency. Yay!

And this is also what they hear if they hear “AI”: More efficiency. Yay!

Hence, knowing how to write frontend, backend and database code will not give you any competitive advantage competing with modern AI solutions in their area of strength. Do not get me wrong: There is nothing wrong with having coding expertise in more than a single area. But in the end, it is still just coding expertise.

Writing code is less than 10% of the work that needs to be done if you want to turn a business idea into a working software solution. Sure, it is an important part of the work but it is also the part of the work modern AI solutions can take over best.

Therefore, I recommend becoming a “full-range engineer”, also taking the other 90% into account. You should be effective along the whole IT value chain, not only the coding part. Again, this does not mean you need to be an expert in everything. Again, this is not possible. But you should be able to accompany non-IT people along the IT value chain. You should help them to understand which consequences their needs and demands have regarding the IT solution side, short-term and long-term, locally and globally. And you should help them making the best decisions possible.

This way you become most effective, i.e., optimize your value from the perspective of the other (non-IT) people – including those decision makers who may ponder in the relatively near future if to replace you with an AI solution. As a full-range engineer, you do a lot more than just writing code based on more or less ready-to-implement requirements. You support people. You make people feel heard and understood. You lead people to better understanding and better decision making. You are effective and help other people to become more effective, this way generating and improving business value for your company.

Additionally, decision making in complex enterprise contexts is always highly specific. What is good advice for company A may be bad advice for company B. There are no blueprints or easy solutions (even if some people still believe it). It always depends – on your very specific and unique setting. Nothing can be found in the Internet about what is the right decision in your context. This also means that AI tools do not have a basis to learn how to make these decisions even if they were able to handle all the complexity involved. But as a full-range engineer, you are able to make such decisions and help other people making such decisions.

To refer back to quite the beginning of this blog series: This is very different from being a “hardcore developer”, being in love with nifty details of your favorite programming language and frameworks, always in search of more “deep” details, always trying to become an even better coder. Remember: ChatGPT already knows.

The times of differentiating oneself by knowing more details about something than others are coming to an end in software development. It is just a matter of time until the modern AI tools know better how to write code than any human.

Summary

In this post, we discussed what it needs to become a “full-range engineer”. We have seen that this is quite different from what software engineers often strive for today.

However, it is focused on becoming more effective. This way, we are able to create more value in highly complex, uncertain and ambiguous environments – the kind of environments we typically live and work in. Thus, we are also able to improve our own value as “full-range engineers” – now competing with AI solutions in our area of strength.

In the next post, we will explore why we need to be a bit rebellious to take this road and discuss if a changed positioning of software engineers is enough for the future of our industry (Spoiler: No, it is not). Stay tuned …