Beyond Coding: Unlocking the True Essence of Software Engineering

When the public thinks about software engineers, what comes to mind? For many, it’s one of a series of brilliant hackers, think Neo from The Matrix, a faceless SDE grunt by day, a loner hacker by night, pounding out thousands of lines of code while gobbling up gallons of bad coffee. 

This view is so pervasive that at times it translates into how engineering managers see their ICs, thinking of them as task receptacles rather than problem solvers. This is a very dangerous misconception and is one of the main drivers of software engineers’ disengagement and job dissatisfaction. 

Software engineers are not coders. The essence of software engineering lies in problem-solving skills, where working software is just the final step on a long road rather than the goal. 

The Misunderstood Role of a Software Engineer 

The coder-first mentality is still largely prevalent in software engineering interviews. The “coding interview” is designed to test how well a software engineer can code, and little else. I won’t go into detail on the problems with this approach here; I’ve written about that in my Interviewing series. (Find the articles here, here, here, and here.) Suffice it to say that most SDEs know that the skillset needed for a spectacular coding interview performance is very different from that needed for a spectacular on-the-job performance. 

So what’s the difference? The difference is realizing that software engineers are problem-solvers. Said Martin Fowler, a renowned software developer, author, and speaker: “Seeing engineers only as coders is like valuing painters only for their ability to use a brush. Coding is a tool, a very important one, but it’s the understanding of problems and crafting of solutions where the true engineering lies.” 

When managers misunderstand the role of software engineers, they miss the chance to treat them like empowered creators, assigning tasks instead of business problems, and gauging their output by the number of CRs they produce rather than the complexity of the business problems they solve. This makes it harder for the engineers to be deeply engaged in their work. Over time, they learn that it’s easier to just do what they’re told than to try and move the needle.   

In the emerging world of AI-assisted development, those engineers are the most at risk. With the increasing sophistication of tools like Copilot, Phind, Code Llama, and Amazon’s CodeWhisperer, there’s less and less need for engineers to write boilerplate code, the typical meat-and-potatoes of day-to-day software development. This has the potential to 10x an engineer’s productivity, resulting in a corresponding reduction of the number of such engineers needed. 

To be clear, AI is a great asset to software engineers, freeing them from the more mundane coding tasks and allowing them to focus more on the problem they’re trying to solve. Thus, it’s even more important for managers to encourage their engineers to focus on the higher-level and lean on emerging tech like AI to optimize their work. 

The Core of Software Engineering: Problem Solving

Software engineering is not, primarily, about coding, even though coding has historically taken most of an engineer’s day-to-day time. It’s about deconstructing a highly ambiguous problem into small, bite-sized pieces. It’s about taking a business problem and coming up with a comprehensive solution, and, in the process, dealing with a whole lot of ambiguity. 

It’s the ambiguity that differentiates your rockstars from your average developers, and learning to deal with that ambiguity requires ample opportunity to do so. It’s not going to happen if the engineer never gets a chance to operate on the scale of business problems rather than coding tasks. 

Ambiguity lies at the heart of software development. This is why Microsoft has a separate Competency called ‘Dealing with Ambiguity,’ something explicitly tested for during interviews. This is why Amazon prizes the ability to deconstruct ambiguous problems as a core moving-to-Senior criteria. It’s not easy. 

So, when we as managers take that ambiguity away from our engineers, they’re missing the bulk of what those engineers can really offer. 

Let’s take a specific example to illustrate my point. Imagine you’re the engineering manager for a software company that specializes in educational technology. Your platform helps students learn programming through interactive exercises and projects. Recently, you've noticed a high drop-off rate at a particular module which is causing concern.

A proposed solution by the product team is to simplify the exercises within the module, making them less challenging in the hope of reducing the drop-off rate.

As an engineering manager, you add a task to your workflow to make the exercises easier. But if your team is made up of problem solvers, not just code implementers, they'll engage in critical thinking. They might raise questions such as:

• Is the difficulty of the exercises the real reason for the drop-off, or could there be other factors at play?
• What does the data tell us about the points where students stop progressing? Are there patterns or commonalities?
• Could enhancing the instructions or providing additional support materials be a better approach than diluting the educational content?
• What if we involved students directly, gathering feedback to understand their challenges and motivations?

The engineers might conclude that simplifying the exercises is the way to go, or they might discover that a more nuanced approach is needed, such as introducing a mentoring system, gamifying the learning experience, or providing clearer stepping stones to build up to the more challenging content.

In other words, instead of blindly taking up the task, your engineers are going to ask questions. The outcome of these questions may very well be “Yes, this feature makes total sense, let’s do it.” Or it may lead to a much better, much more impactful way to spend the team’s energy.  

Developing an engineer’s problem-solving skills 

The development of an engineer’s problem-solving and ambiguity-busting skills begins in lower school. There, this discipline is called ‘critical thinking.’ When my son (who’s now in high-school) used to rail about why they had to write those stupid compare-and-contrast essays for his Language Arts class, I used to tell him about reports I used to have who’d read a Product Requirements Spec, scratch their balding pate, and then go implement something entirely unsuitable, just to have to reimplement it later. 

Critical thinking is the go-to tool for a software engineer, but it only develops when given a chance, and may, at times, misfire. This is where it’s important that your team has a collaborative, got-your-back culture. An environment like this enables growing problem solvers to practice their skills without fear of failure... or, more exactly, fear of repercussions. The team collaborates to identify and mitigate risks, and when things do go south, stand together to address them.  

Note, too, that critical thinking goes hand-in-hand with creativity, and both of those flourish only in the psychologically safe environment described above.  

So, as a manager, you not only need to delegate business problems to your directs, you also need to put in mechanisms/guardrails in case of failure, and a team culture of psychological safety. This can be a tall order. 

The tools you can use to achieve this are: 

• Effective delegation 
• Transparency 
• Effective 1:1s 
• Effective performance management 
• Implicit trust in your team 

Hopefully, you’re already well-versed in these tools. If not, please scan the Empathic Insights archives for articles addressing these or reach out to us if you would like more hands-on coaching. 

Conclusion 

 Look, it’s all too-easy to silo your engineers or small-time coding tasks. It feels safe, because you’re taking on the burden of thinking through the work that needs to be done. But those who do this miss out on the opportunity to empower their engineers, accelerate their career growth, and leverage their skillset to the maximum extent possible.  

On the other side of the spectrum, implicit trust feels scary. If things go wrong – and things will eventually go wrong – you’re going to be left holding the bag. But for all the costs such a model might introduce, the benefits are far, far greater, because when your engineers learn to be effective critical thinkers there is nothing that comes up in the course of your business they won’t be able to handle.