Software Developers' Personalities

In this post, we’ll see a list of different developer profiles you can find in companies.

This post is based on this one in English (https://neilonsoftware.com/difficult-people-on-software-projects/developers/), I don’t intend to claim authorship, and in fact, the original blog has profiles with much more detail. Here, I’ll go through them according to my own personal experience.

Also, keep in mind this list doesn’t include the “normal” profile, in my experience, out of every 100 developers, 50 are “normal” (or mostly normal) and the rest are distributed among the following categories.

The Rock Star

The first profile we’ll see is the Rock Star. Most of you reading this are developers, which means you have LinkedIn, and I’m 100% sure you’ve received that typical recruiter message saying “we’re looking for a rock star” or “we’re assembling a group of rock stars.” In my opinion, there are very few true “rock stars” out there, they’re exceedingly rare.

Still, if we look at the whole company, we can spot them because they have these characteristics:

• They’re able to solve every problem sent their way quickly and efficiently.
• Their code hardly has any bugs.
• They usually take on the hardest tasks.
• They’re a source of wisdom for their coworkers.

Of course, there are negative sides:

• Indispensable for the project: they usually know absolutely everything happening in the project and how it’s implemented. This might seem like a benefit, but it’s actually a problem, if they leave, no one knows how anything works.
• Arrogance: everyone knows there’s a lot of arrogance in our world, and some of these so-called rock stars call anyone who doesn’t think like them an idiot.
• Everything has to be their way: as we know, they can detect what’s needed and straight up impose their opinions or ideas.

Finally, a side effect when there’s a rock star on the team is that coworkers start slacking off a bit, because the moderately difficult tasks all go to them.

Aspiring Manager

Once tired or burnt out from the challenges of being a developer, like constant learning and keeping up-to-date, this person decides to change their career vision to start managing people.

There’s nothing we can do to avoid it, ultimately, it’s a “life-changing” decision and nothing you say will make them change their mind.

Their positive traits are few, but there’s one that I think is very important:

• When the boss is out, they lead the meetings.

Personally, I consider myself a developer and I don’t like reading tickets in daily meetings or retrospectives, etc. In fact, I spend half the meetings working while people talk about things I don’t care about. Thanks to the aspiring manager, even though I might be the most experienced developer, I don’t have to lead those meetings.

But unfortunately, there are important downsides:

• Unfortunately, they stop programming and spend all day managing people or trying to prove to the boss that they deserve to become a manager.
• Since they’re always “managing,” they spend all day in meetings, sending emails, so you can’t really rely on them for development.
• Finally, to everyone’s dismay, they don’t quite have a place in the company. They want to be a manager, but the company doesn’t need more managers, so their only hope is: their manager leaves, the company grows enough to need a new manager, or they leave for another company.

Still, they’re good people and we wish all aspiring managers the best. In Spain, it’s very common, since generally you have to be a manager to earn more, which is why many companies have managers who don’t actually want to be managers.

Bull in a China Shop

Here we have someone who only cares about finishing their tasks and going home, regardless of how things are done, as long as they “work” (which they don’t, at least not well).

Usually, this kind of person is a product of the pressure and deadlines of the project; maybe after a year or more, they’ve picked up bad habits and never dropped them.

Of course, we have lots of negative points here:

• Testing? What’s that? Due to the deadline, nothing is tested, neither automatically nor manually.
• Which leads to code full of bugs, it works on the happy path, but when something goes wrong, errors start popping up everywhere.
• This happens because during development they don’t care about quality. They’ve forgotten what SOLID principles are and why they’re useful. "Code review" is something they heard about once, but don’t know where it happens.

Unfortunately, when you have someone like this on your team, it’s very, very difficult to “fix” them. The only solution is patience, take their reviews calmly and explain every detail with reasons why. Also, explain that rushing won’t get them anywhere, and that it’s better to write good, clean code that’s maintainable in the future.

The Diva

A person fully convinced they are irreplaceable, becoming somewhat arrogant.

Among their main traits, we can include:

• Good developers, but not as good as a Rock Star, even though they might think otherwise.

And so, their downsides:

• They don’t work for the company, deep down, they do what they want and their way. They actually think everything’s wrong and rarely listen to their manager.
• They think they’re irreplaceable: in their mind, nobody knows how to do anything and everyone else does everything wrong, so they never even consider being fired, because “nobody knows more than me.”
• Because of this, they’re always acting grandiose and egotistical, and don’t care what others say, even their manager.

The Overestimator

The typical person who, tired of missing deadlines, now always asks for much more time than they actually need.

Generally speaking, it’s better to say you’ll need more time rather than less.

• The overestimator knows what they’re doing and is aware, so everything should be finished sooner and well tested.

The downsides are more for the boss or entrepreneur than for colleagues:

• All they want is time, which is pretty inefficient for the company.
• Their estimates are pointless: if you reduce their estimate by 20%, they’ll accept it just as if someone increases it.
• Unfortunately for colleagues who want to become managers, these types of developers usually have a very good image in the eyes of higher management because, of course, they always meet their deadlines and their work is done, so they often end up getting those positions.

The Underestimator

Just the opposite of our previous subject, the underestimator always claims they’ll finish a task faster than they will.

In this case, there are not many positives, if any.

Instead, there are several negatives:

• Never on time: since they always say it’ll take less time than it will, everything ends up done quickly, poorly, and, commonly, late.
• Since their time estimates are worthless, we can’t plan a clear development path for our project.

It’s widely known in the industry that underestimating tasks is common, but in this case, it’s an extreme. They also tend to think estimates are pointless.

Personally, I’ll say that for me, estimation isn’t extremely important (though it depends on the project and participants). The way I work best is, "by this day, everything has to be done," instead of estimating task by task. But that’s just my personal opinion.

The Code Hostage-Taker

The classic character who has written a critical part of the system that the company depends on and won’t let anyone else touch it.

Thanks to God, this profile is becoming less common with the rise of microservices and distributed applications, but they still exist.

When we talk about a code hostage-taker, we’re talking about someone who spent most of their time working on one part and treats it like their baby. They know it inside and out and don’t want to share it.

Because they’re also sure that as long as nobody else knows the code or how it works, their job is safe.

However, when they leave, as they will, it becomes a huge problem for the next person.

The Code Idealist

This person is obsessed with writing elegant, perfect code, completely forgetting that they work for a company that wants results.

Of course, focusing on quality gives us benefits:

• Good code: an idealist stands out for writing elegant, readable, maintainable code, which is great. Sometimes, they might get a bit too "cool" and add more complexity than needed.
• Their code is usually tested and retested, which helps avoid bugs or production failures.
• They’re good developers, and with time, could build the whole system if needed. They have a good overall level in everything and are experts in at least one or two areas (backend/frontend/devops).

But unfortunately, there are downsides:

• Despite what the idealist thinks, they don’t have all the time in the world, and features need to be done by a deadline and shown to clients so they pay the company, and the company pays us. The idealist forgets that detail, adding business value.
• Very often, not all the code has to be as if Picasso had painted it. Just keep things simple and fast, with minimum quality, but nothing taken to extremes.
• Unlike the previous case where a developer hijacked the code, our idealist hijacks people to join their cause. Every developer dreams of having all the time in the world to do things right, which can have a bigger impact on the project.

The idealist is a good person, in fact, often a very good developer, and genuinely thinks that doing things extremely well will be best for the company’s future.

Top companies are where they shine most, since these don’t have such tight deadlines and have enough financial buffer for several months or even years.

But if the company is small, they’re doomed to failure and/or frustration, as bosses want to see results.

If I had to choose one profile I relate to most, this would be it, no question.

The Incompetent One

Unfortunately, we all have coworkers who are missing that spark to be good at writing code.

Just as not everyone can be a footballer or musician, not everyone can write code.

What’s more, I personally notice this is becoming more common, probably due to the high salaries in tech, everyone’s getting into programming, and clearly, not everyone is cut out for it. What’s worse, many don’t even like it, and only do it for the money.

Personally, I think programming can be a very stressful job. If you’re only in it for the money, seriously reconsider it, you’ll be healthier for it.

Also, these are usually not people who are slacking off, they’re there, working hard and trying things until they find a solution or eventually give up and ask for help.

The problem comes when you have more than one in the team, and mainly:

• Reviewing their code. They need constant supervision since their code is often full of bugs, or the ticket’s requirements aren’t fully met, which can be very frustrating.
• They often complain they can’t complete their tasks due to a lack of training, and when you ask how things are going, they get defensive, you always have to remind them you’re there to help.
• Usually, they apply for all the management openings, since they’re frustrated as developers.

Personally, I think everyone can learn. In IT nowadays, everyone joins, and the best way to deal with this person is patience and explaining things in detail, once or ten times, as long as they pay attention, you can repeat yourself as often as needed. Don’t be a diva.

The Company Soldier

The typical colleague who does whatever they’re told, without asking questions or considering whether it’s right or not.

From a company or manager perspective, a soldier’s traits are perfect:

• Does what they’re told, no more, no less, does the job and goes home.
• A soldier’s "level" can be anything from incompetent to rock star.

But even though they’re a good employee, there are negatives to having soldiers:

• They don’t offer opinions, they’ve reached a point of just doing what they’re told without complaining or even suggesting improvements, even if they know how.
• If they know something is wrong, they won’t tell you, they’ll just do it anyway, and the consequences will appear later.
• These people end up this way because the company “trained” them like a dictatorship: obedient but restless, so they’re always job-hunting and will leave at the first chance.

The Tech Maniac

We’ve reached the point where there are new JavaScript frameworks or tech daily. Our subject is passionate about everything new and wants to try it out, of course, at work.

Having an employee or coworker like this can really benefit the team, after trying so many things, they have ideas that could really contribute to the project. For example, if you’ve never worked in the cloud, this person might have a rough idea of how a cloud system works, just because they’ve tinkered at home or in a previous job.

This obviously has its positives, but also the downside that their personal quest to learn or improve with some tech doesn’t always lead them to make the best choices for the company.

For instance, if they decide they want to learn Java or Node when all your code is in C#, you might end up with all your microservices in C# except one, the one they chose to experiment on.

The same thing happens with databases or any other technology.

They might be right sometimes, and that’s why, when you have someone like this on your team, it’s important to explain there’s a fixed stack, but if they see something can be improved, they’re free to create a presentation justifying it.

That way, everyone’s happy, the colleagues, the company, and them.

The Old-School One

A person whose only skill is maintaining old (legacy) code, but who can’t use new technologies or create anything new.

Let’s be honest, nobody wants to maintain old code. Most of us, maybe even 100% of you reading this, want to build new processes, new apps, everything new all the time. So, having someone who doesn’t want to change isn’t entirely negative.

You can almost always feel free to assign them all the bugs and all the minor changes that require good domain knowledge, since they’ve worked on that code for years and know it inside out.

However, it’s almost impossible to convince them to change or improve. In the world of microservices, it’s not so problematic, but with monoliths, it’s very hard to make changes or improvements, they’ll reply with things like “we’ve always done it this way,” “it’ll take too long to redo this,” and other excuses to avoid changing.

Plus, their resistance to change can demotivate new team members or even older members who get tired of their excuses and evasions.

Thank goodness, this kind of person doesn’t usually become a manager. But when they do, the company is in serious danger, they’ll never update anything, will deny all improvements, and, inevitably, the company is headed for failure.

Conclusion

In this post, we’ve looked at different profiles within the world of software development.

Of course, not everyone fits into just one category, they’re usually a mix of several, in addition to their “normal” side.

Unfortunately, for many, maintaining legacy code isn’t a choice but an obligation, and even if they’d like to change, they can’t because of the company. To all of them, my sincerest condolences, keep learning and change companies. Your health will thank you.