10 Software Engineer Types You’ll Meet In Every Company
And how to best work with them
There are countless articles and listicles out there covering the various aspects around software engineering and more specifically, the people who do this work, how they do it and why, how to spot the good ones, the bad ones. Frankly, there is little left to be said, and every time I see another story on the matter, I realise it’s more or less a verbatim copy of all the others. The one article that I was looking for many times, I have not yet come across, so finally decided to write it myself. Perhaps others can share their experiences and contribute towards a more accurate picture of all the software engineer types that many of us have already met.
I wanted to go one step further, though. I felt it would be better not to write a judgemental article and stir controversy, but rather one that offers a blue-print to software engineer types and how to work best with each type, because I believe in diversity and the value that each type brings to a team, while also highlighting their shortcomings. Just like the saying goes “the right tool for the right job”, I hope that by the end of this article we’ll all agree that “the right engineer for the right task” also applies.
The Lone-wolf 🐺
The lone wolf often becomes the outcast, which unfortunately becomes a vicious circle as they’ll repeatedly find themselves working alone. The assumption is frequently that they’re not good engineers. In my experience, there is no evidence to support the assumed lesser skills of a lone wolf compared to someone very team-oriented. Some engineers are very self-sufficient, and rely on the web, forums and even books to verify their thought-process and gain additional information or context. The coding skills of a lone wolf can be surprisingly good, and regularly you’ll find they’re coding polyglots too.
They do struggle a bit in teams, though. Every so often, it’s paired with their personality, other times they just don’t know how not to own an entire epic or story. They like having tight control over the output of their work, which can at times become a problem in pull-request reviews. It’s not all lost, though. Lone-wolf developers can be well utilised for fixing bugs, creating technical spikes and even proofs of concept paired with good documentation. This allows them to work on their own, have control and ownership over the entire slice of work, yet still contribute to the team’s success.
The Lazy 😴
Of course, I’m not referring to an actual lazy software engineer. Lazy and uninterested individual contributors are a management and Human Resources concern. What I’m referring to here is the engineer who wants to achieve the most with the least amount of effort and never wants to deal with that particular piece of code ever again. At first, you might think this is not someone you’d be really keen to work with, but hear me out.
There is a theory (don’t ask me what famous software developer came up with it), which claims that the best engineers are the laziest ones. Obviously, that’s overly generalised, but the crux of it all is that the lazy engineer will try to be as efficient as possible and will attempt to write bulletproof code that adheres to both DRY and KISS principles — which is not easy. Heck, because they’re so lazy, they’ll also try and future-proof as much as possible, though — and this is their potential downside — inadvertently also introducing premature optimisations that could be costly to the company.
Having said all the above, I do think that a lazy software engineer is often a great candidate for mission-critical and architectural code where development cost is less of a concern than iron-clad, scalable and robust implementation.
The Happy-go-lucky 🤡
Not a care in the world. Half the time in standups, you’ll feel like they’re either high or completely zoned out. They’ll say yes to anything, and nothing will present any real concerns to them. Que sera, sera. On the upside, they’ll take any feature or bug you’ll throw their way without complaints and for the most part, deliver decent code, and when you leave 17 comments on their PRs, they’ll happily oblige and implement even the craziest suggestion which was probably just you being a troll. They’re easy to work with, as long as nothing breaks.
The downside of it all is that you never have a good idea of how long delivery will take. Because they sit on a fluffy technicolor cloud all day, nothing truly ever matters, be that delivering on time, testing the code properly, or even reading the requirements in the story, which will inevitably lead to frustration on the team. They’re the type of engineers I think are best at working on repeat stuff, the mundane, literally anything that has been done before and everyone else is bored of.
The Helicopter 🚁
The helicopter engineer is an interesting one. They’re decent coders, often come with a vast array of languages under their belt, but they never find themselves too concerned about the nitty-gritty details. More often than not they feel most comfortable in a helicopter view, looking at the larger picture where everything else is just “implementation detail”. They definitely think and diagram more than code, but this could either be an early sign they’re more fit for software architecture than feature development, or an indicator of a highly senior engineer who is meant to provide that level of technical leadership.
While they’re great at coming up with overall solutions, it can mean they struggle down in the trenches. Perhaps they are rusty in a particular language, or really not that bothered by the itty-bitty stuff, which could render them slow in comparison to the rest of the team. To best utilise their skills, they’re best left to figure out the answers to the bigger questions, do a proof of concept or two, and generally deal with strategic aspects.
The Trench-master 👷♂️
The Trench-master engineer is the exact opposite of the previous type. Where they truly shine is the implementation detail or dealing with one piece of the larger puzzle, and do so to the very last detail. They thrive in the trenches, and their pride and joy is a pristine, textbook PR that even the nitpickers can’t find issues with. They’re excellent tinkerers, too, and they rarely if ever give up on finding the root cause of a bug.
While they’re fantastic problem-solvers, and often the most experienced in a particular programming language or framework, this skillset can also work against them as there’s an involuntary tendency to get bogged down in the implementation details, and lose focus of delivery. That being said, when code quality is of the utmost importance, and the task really requires someone who has intimate details of every single trick in the book for a particular language or library, they’ll be the one to work with.
The Designer 🖌️
The developer who will try to avoid anything that has to do with back-end, middle-ware, or even business logic in the front-end. Some might judge them and dismiss them as programmers, but I think it would be a grave mistake. If you spent more than 20 minutes writing CSS and semantically correct, accessible HTML, you’ll know styling and layouts can become increasingly tricky to code in modern web applications. CSS in particular has become quite complex and nuanced over the years. I say give them all the fancy UI stuff to deal with, and let the rest of the team deal with the other bits. Pretend you have a web beautician on the team. They’ll thank you for the tasks and in turn you’ll always have well-implemented, pixel-perfect UIs.
The Refactorer 🧱
The software engineer who never heard of Martin Fowler or the concept of continuous improvement. Don’t get me wrong, they possess a very valuable skillset. Cleaning up code, getting rid of tech debt, is something they’ll often find extremely exciting.
That however comes at a cost because they’ll also often lose sight of the deliverable, and when they do deliver the original code has been rewritten three times, and that last iteration can turn out to be so overly abstract that no one else understands it any more. Everyone will be convinced it is the most efficient way to solve the problem, but months later when the code goes into maintenance and maybe needs to be extended, everyone else will spend valuable hours just to figure out how it all works.
The Pragmatic 📏
I happen to be part of this category. The pragmatic software engineer always tries to find a balance between delivery and implementation, and will greatly enjoy no bullshit conversations and straight-forward development paths. They’ll be generally excellent at prioritising stories and bugs, and they tend to work very well with scrum masters and product owners. When it comes to code, they’ll love relying on good tests but will always avoid writing overlapping ones between unit, integration and E2E.
All of the above though doesn’t necessarily make them faultless, though. They won’t fuss much about writing the coolest code — which will piss off nitpickers, or adhere to every single programming principle in the book. Good enough is something you’ll hear them say at times, and they’ll even sometimes acknowledge potential technical debt being created by their actions, but they’ll justify it in a way that’s hard to argue with. The pragmatic engineer is quite multipurpose, they fit just about any type of work, and you can almost always bet they’ll deliver on time or within the ballpark of their estimation.
The Entrepreneur 🤑
The entrepreneur is a very cost-conscious engineer who will always look at cost vs benefit. While their heart is in the right place — genuine $$$ cost-saving for the company — their penny-pinching approach shouldn’t be left unchecked. When mission-critical decisions are made, The entrepreneur is best paired up with The Pragmatic and potentially The Helicopter engineer; otherwise you could end up with a house of cards, mountains of technical debt and potentially dangerous code out in the wild.
Having said that, The Entrepreneur will do great when coming up with potential MVPs, or getting something out there in a rush and under pressure. While on their own rarely will they produce something robust and scalable in the long run, it could make the difference between imminent financial collapse of the company and unprecedented success. We all know how brittle the first iOS was, and we also know who made it happen, but the timing was perfect, and it made all the difference.
The Philanderer 😉
Have you ever worked with an engineer who every Monday at standup talks about yet another library, language, or framework they played around with? Did you also notice that they’ll be the first to find the “solution” to even the mundainest of problems in something that’s either in beta or is trending? Well, they’re The Philanderer. They just cannot stay true long enough to anything in software development. They’re always eyeing something else, and whatever they’re currently working on makes them feel depressed and bored.
It’s not all bad, though. An undeniable ace The Philanderer will have over every other engineer is their vast knowledge of alternative solutions and technologies in software development. They’re a fantastic resource to work with when the technology needs a new direction or exploratory work needs to be done for a greenfield project. They’ll be good at leading either a tech transition, or helping set up a new architecture with The Helicopter engineer.
Of course, there may be other types out there, but I think I covered a large majority of them. It’s also worth noting that you may find yourself and others being part of more than one category, or even adapt to a few of these as and when required. I also noticed that with seniority over time, many engineers are able to combine these categories. Let’s call them seasoned cross-functional engineers, and if you find yourself to be one of them, pat yourself on the back with one hand, with the other keep making the world a better place one line of code at a time.
Hang on…
While I have you here, maybe check these articles out too. They’re not half-bad, if I may say so myself. 😁
Attila Vago — Software Engineer improving the world one line of code at a time. Cool nerd since forever, writer of codes and blogs. Web accessibility advocate, Lego fan, vinyl record collector. Loves craft beer!
