I’ve spent a few years now working as a software engineer working in a variety of industries including oil and gas, power systems modelling and advertising technology and there are a few common factors that I’ve noticed amongst software engineers. These traits are not exclusive to software engineers, but it’s the only commercial industry that I’ve worked in, so I can’t really comment on other industry sectors.
First of all, the vast majority of software engineers I’ve interacted with are smart individuals. They can figure out technical stuff and come up with solutions, usually pretty quickly – that’s pretty much the core purpose of any software engineer’s role. Experienced engineers can often look at unseen technical documents and figure out highly technical concepts extremely quickly. But there are traits that make some software engineers really good, and others that, well, make some software engineers produce poor quality output and make them difficult to work alongside.
The good
Able to communicate at a variety of levels
One trait that is fairly uncommon amongst software engineers is an ability to communicate technical concepts in a clear manner at different levels. It’s inevitable that people who work in technical concepts for the majority of their day also think and communicate at a deeply technical level. But I’ve found there aren’t that many individuals who can translate those concepts into the appropriate level for the relevant audience. I’ve seen it so many times when software engineers revert to low level details in meetings when it just isn’t appropriate.
It’s something that comes with experience, but the engineers who a really good at this are able to understand the audience, and also switch the level of detail on the fly. Really good engineers know the low level technical details inside out, but can translate this into concepts at higher levels such as architectural concepts, and business requirements. It’s such an important skill, because in software engineering we spend a lot of time figuring out what software systems we want to produce, and this involves speaking to technical directors, project managers, product owners, engineers, all of whom have different levels of knowledge of software systems. Yeah, you can bury your head in the sand and just work on your project tasks and think communicating with other people outside your team isn’t your problem, but I don’t think you’ll progress as far.
Constant learner
Tech technology moves at an alarmingly fast rate. Pick up any software engineering book from around 20 years ago and the software engineering world was a very different place. Now we have an abundance of programming languages, cloud computing technologies, CI/CD tooling and AI tools all claiming to be the next best thing. But good engineers accept that new tools will come long and spend their effort in learning new technologies that will have a material impact in their work. Good engineers can separate the wheat from the chaff and dedicate time to learning.
Persistent
A common scenario in software engineering is a problem that occurs frequently, but isn’t critical. These problems are often moved down the priority list while other high-priority work is talked. But in many cases these problems mask bigger issues that often rear their ugly head down the line. Good engineers see these problems and are persistent in questioning why they are happening. These engineers often discover issues that have laid dormant for a while and often fix issues that many other engineers simply give up on.
Honest
Most software engineers will make a big mistake at some point. But a good engineer will admit to their mistake in an honest and timely manner. This is much better that thinking that no one will notice and hiding your head in the sand. This is also true of knowledge – an engineer who admits they do not know how something works is someone who is much easier (and more efficient) to work with than the engineer who pretends to know.
Knowing when something is ‘good enough’
Ah, the classic problem of over-engineering a solution. Every software engineer does this, no matter how well-defined the requirements are. As we implement our features we introduce extra functionality that is, of course, a good idea. Of course we need all these extra monitoring tools, of course we need the most high-performant library to eek out every bit of performance. But the reality is that we don’t. Most often, what product managers want is something working, and usually in a timely fashion. You can see the look of despair in their eyes during software stand-ups when engineers explain that they’ve spent their time implementing features that were never requested. Good engineers fight this urge and know when what they’ve got is good enough.
The bad
It’s a bit unfair to label a category of software engineers as bad. We’re all pretty busy, so it’s inevitable some things slip. But there are some common factors that seem to be linked to poorer quality outputs.
Getting the code to work and thinking you’re done
You’ve implemented that feature, had a quick scan of the output in the logs and you feel great – you push that code and get the pull request sorted. Time to move on to the next task.
The problem is that software engineers can be a bit lazy when it comes to testing. It’s not the exciting bit, but it’s the bit that saves you from a LOT of stress down the line. Sure, AI tools can write those tests for you, but I personally think you have to get your hands dirty and understand how that new feature you’ve implemented actually works in different scenarios.
An unhealthy reliance on AI tools
Yip, I’ve said it – I don’t think a good software engineer can be fully reliant on AI tools to perform their job well. Sure, we all use AI tools to be productive, but I don’t think AI tools should be used to perform all software engineering tasks. Good software engineers understand what to build and what not to build. This is what makes experienced software engineers very powerful when coupled with AI tools. But if you simply tell an AI tool to build something without having any understanding of the technical consequences of one design choice over another, then results will be poor. This is my opinion, of course, and we’ll see if this point ages well.
Leaves that last 15%
Someone told me years ago that the last 15% of a task is the hardest bit. You’ve done the meat of the task but you have a bunch of loose ends that need tied up. Be it tests, documentation or minor changes to UI – they’re not much fun and to be honest, we’d all rather be working on interesting feature implementation. But good engineers know that these small tasks at the end of a piece of a work make a difference down the line. Bad engineers choose not to finish that 15%.
The ugly
My way, or the highway
There are a few traits in software engineers that I think aren’t conducive to efficient work and go beyond the category of ‘bad’ software engineers. Probably number one is the individual who refuses to believe that any way other than their way is right way. The individual may even give the impression that they are considering other opinions, but this is often a facade, with those opinions ignored after team discussions. I’ve come across scenarios where software engineers have been so infuriated working with such individuals that they simply leave employment with the company. I’ve found that such engineers rarely change their ways of working, and I think the only way to deal with such toxic individuals is to minimise contact. Or if that isn’t possible, work somewhere else.
Final thoughts
Scanning through these points, it’s obvious that many are not exclusive to software engineering. They will certainly have crossover in other fields. As we move through the era of AI I’m sure many of the points above will become redundant. But I genuinely believe that we will always need experienced software engineers who know their shit and keep the tech world turning with robust, reliable software.