Software Developer Personalities

In this post, we’ll look at a list of different developer profiles that can be found in companies.

This post is based on this English article (https://neilonsoftware.com/difficult-people-on-software-projects/developers/). I do not intend to claim authorship over it; in fact, the original blog contains much more detail on each profile. Here, we’ll see them as per my personal experience.

Also, note that the “normal” profile isn’t listed here. In my experience, out of every 100 developers, 50 are “normal” (or mostly normal) and the other 50 fall into the following categories.

The Rock Star

The first one we’ll talk about is the Rock Star. Most of you reading this post are probably developers, meaning you have LinkedIn, and I’m 100% sure you’ve received the typical recruiter message saying “we’re looking for a rock star,” or “we’re building a group of rock stars.” In my opinion, there are very few true “rock stars” and they are rare.

Even so, within a company, you can spot them because they have the following traits:

• They can solve any problem assigned to them efficiently and quickly.
• Their code barely has bugs.
• They usually take on the most difficult tasks.
• They are a source of wisdom for their colleagues.

Of course, they also have their negatives:

• Indispensable for the project. They usually know absolutely everything about the project and how it’s implemented. This might seem like an advantage, but it’s actually a downside because if they leave, nobody knows how anything works.
• Arrogance. Everyone knows that arrogance is common in our world, and some of the so-called rock stars genuinely treat anyone who doesn’t see things their way as an idiot.
• Everything has to be done their way. Since they can detect what’s needed, they directly impose their opinions or ideas.

Finally, a side effect of having a rock star on the team is that colleagues tend to slack off a bit, since all the moderately challenging tasks are taken by this person.

Aspiring Manager

Once tired or worn out by the challenges of being a developer—such as keeping up to date and continuous retraining—this person decides to change their vision for the future and start managing people.

There’s nothing we can do to stop it. Ultimately, it’s a life-changing decision and nothing you say will make them reconsider.

Their positive traits are scarce, but there’s one that is very important to me:

• When the boss isn’t around, they lead the meetings.

Personally, I consider myself a developer and I don’t enjoy reading tickets in daily meetings or retrospectives, etc. In fact, I spend half of the meetings working, while people discuss things I care nothing about. Thanks to the aspiring manager—despite being the most experienced developer—I don’t have to lead those meetings.

But unfortunately, there are important downsides:

• They’ve stopped programming and spend their days managing people or trying to prove to the boss that they deserve a promotion to manager.
• Since they’re always “managing,” they spend their days in meetings, sending emails. So they aren’t very reliable for development work.
• Finally—unfortunately for everyone—there is often no place for them in the company. They want to be a manager but the company doesn’t need more managers. Their only hope is for their own manager to leave, the company to grow significantly, or to change jobs.

Still, they’re good people, and we wish everyone who decides to become a manager the best of luck. In Spain, this is very common, as generally you have to be a manager to earn more, so many companies have managers who don’t want to be managers.

Bull in a China Shop

Here we have someone who only cares about finishing their tasks and going home, no matter the state they’re in, as long as they “work” (they don’t, at least not well).

Usually, this profile arises from the pressure and deadlines generated by the project, and after maybe a year or more, they’ve picked up bad habits and haven’t let go of them.

Of course, there are plenty of negative points here:

• Testing? What’s that? Can you eat it? Because of deadlines, nothing is tested—not automatically nor manually.
• This leads to code full of bugs. When everything follows the happy path, it works perfectly, but as soon as something breaks, errors pop up everywhere.
• This is because, during development, they don’t care about quality; they’ve forgotten what the SOLID principles are and why they’re useful. The phrase “code review” is something they once heard and have no idea where it happens.

Unfortunately, when you have someone like this on your team, it’s really, really hard to “fix” them. The only solution is patience, taking your time on their reviews and explaining every detail along with the reasons why. Also, explaining to them that rushing will get them nowhere and it’s better if they write code well, cleanly, and maintainably for the long run.

The Diva

A person totally convinced they are irreplaceable, resulting in a rather arrogant attitude.

Main traits include:

• Good developers, though not as good as a Rock Star—though they believe otherwise.

And therefore, their cons:

• They don’t work for the company; deep down in their minds, they do whatever they want in their own way, and actually think everything is wrong and don’t always listen to their manager.
• They believe they are irreplaceable; in their mind, nobody knows how to do anything and everyone does everything wrong, so they never imagine they’ll be fired because “no one knows more than me.”
• Because of that, they carry themselves with an inflated ego, and don’t care what others (including the manager) say.

The One Who Overestimates Tasks

The classic person who, tired of missing deadlines, has reached a point where they ask for way more time than they actually need.

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

• Those who overestimate time know what they’re doing and are conscious of it. So everything should be finished before the deadline, and well tested.

The downsides are mostly for the boss or entrepreneur rather than colleagues:

• Time. All they want is extra time, which is quite inefficient for the company.
• Their time estimates have absolutely no value; if you trim their estimate by 20% they’ll accept it, just like if someone extends it.
• Unfortunately for colleagues who aspire to management roles, these types tend to be seen very positively by upper management, as they always make their deadlines, and the work is complete—so they often get promoted.

The One Who Underestimates Tasks

The exact opposite of the previous profile: those who always give shorter time estimates than they actually need to complete a task.

Truth is, there are not many positive points to this profile, if any.

On the other hand, there are several downsides:

• They never deliver on time. Because they always say it’ll take less time than it actually does, things end up rushed, poorly done, and usually late.
• Since their estimates make no sense, you cannot properly plan a development roadmap for your project.

Everyone in the industry knows it’s very common to give less time than necessary for tasks—but in this case, it’s extreme. They often think estimating is useless.

Personally, I’ll say that for me, estimation isn’t extremely important. It depends on the project and participants, but what works best for me is, "by this date, everything here needs to be done," instead of estimating task by task. But that’s just my opinion.

The Code Hijacker

The typical person who’s written a critical part of the system the company can’t do without, and won’t let anyone else touch it.

Thankfully, this profile is now seen less and less thanks to microservices and distributed apps, but it still exists.

When we talk about a code hijacker, we’re talking about someone who’s spent most of their time on one part of the system and treats it like their child—they know it inside out, and thus, don’t want to share it.

Plus, they clearly know that as long as no one else is familiar with the code or how it works, their job in the company is safe.

But, when they leave—and they will—it'll be a massive headache for whoever comes next.

The Code Idealist

This person is obsessed with writing elegant, perfect code and has completely forgotten that they work for a company that needs results.

Of course, focusing on quality brings benefits:

• The code is good. An idealist stands out for writing elegant, readable, and maintainable code—which is great. Sometimes, though, they go overboard and make things unnecessarily complex.
• Usually, their code will be tested and re-tested, preventing bugs or breakdowns in production.
• In fact, they’re strong developers, and with unlimited time, they could build the whole system if needed. They have solid overall skills and expertise in at least one or two areas (backend/frontend/devops).

But unfortunately, they also have downsides:

• Despite what the idealist thinks, they don’t have all the time in the world. Tasks and features have deadlines to be met and shown to clients so they can pay the company and the company can pay us. The idealist forgets this business value.
• Often, not all the code has to be as if Picasso himself painted it. It’s enough to do things simply and quickly, with a minimum of quality—obviously—but nothing extreme.
• Unlike the previous code-hijacker, our idealist “hijacks” people to bring them to their cause. It’s every developer’s dream to have unlimited time and do things well—which often leads to a bigger impact on the project.

The idealist is a good person and actually a very good developer. They genuinely believe that doing things extremely well is what’s best for the company’s future.

They stand out most in leading-edge companies that don’t have such tight deadlines or budget constraints, and can afford a few months or even years.

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

If I had to choose a profile I identify with, this would be it—without a doubt.

The Incompetent One

Unfortunately, we all have colleagues who lack the spark needed to be good at writing code.

For the same reason that not everyone can be a football player or a musician, not everyone can write code.

Personally, I notice this is becoming more common, and it’s due to high salaries in the IT field. Everyone’s getting into programming, but not everyone is cut out for it, and worse, many don’t even like it—they do it just for the money.

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

Also, these are usually people who aren’t just sitting back but are actually struggling, trying things until they either find the solution or give up and ask for help.

The problem comes when you have more than one on your team, and mainly these issues arise:

• Reviewing their code. They need constant supervision, as their code is often riddled with bugs or even the ticket features aren’t 100% complete, which can be frustrating.
• They often complain they can’t complete tasks due to lack of training, and when you ask how they’re doing, they get defensive. You always have to make it clear you’re there to help.
• They commonly try to apply for all the management openings because they’re frustrated as developers.

Personally, I think anyone can learn—anyone can get into IT these days. The best way to handle this profile is patience and explaining things thoroughly, one or ten times, as many as needed, as long as they’re willing to listen. Don’t be a diva.

The Company Soldier

Your typical colleague who does what they're told, without asking or questioning whether it’s right or not.

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

• They do what they’re told—not a line of code more, not a line less. They get it done and go home.
• The “level” of the soldier can be anything, from incompetent to rock star.

But despite being a good employee, having soldiers has its cons:

• They don’t give opinions. They’ve reached a point where they do as told, don’t complain, and don’t even suggest improvements, whether they know them or not.
• If they know something is wrong, they won’t tell you, and will just do it anyway—the consequences become clear later.
• This kind of person is made this way by companies “training” them, as if it were a dictatorship—obedient but free, which means they’re constantly looking for new jobs and will leave at the first chance.

The Tech Enthusiast

We’ve reached a point where there are new JavaScript frameworks every day, or new technologies emerging daily. This person is passionate about everything new and wants to try it—of course, at work.

Having such a team member can be very beneficial. Since they've experimented with many things in the past, they have ideas that can really help the project's progress. For example, if you’ve never worked with cloud platforms, this person probably has a basic idea of how a cloud system could work, either from personal experience or a previous job.

This has its upsides, but also the downside that their personal learning or improvement interests mean their technology choices aren’t always best for the company.

Say they decide they want to learn Java or Node.js when all your code is in C#. You might end up with all microservices in C# except one—done in whichever technology they wanted to experiment with.

The same goes for databases or any technology.

Sometimes they’re actually right about their suggestions. That’s why it’s important, when you have this person on your team, to make it clear there’s a fixed stack, but if they see something can be improved, they're free to make a presentation justifying it.

That way, everyone’s happy—the colleagues, the company, and the tech enthusiast themselves.

Old-School Developer

A person whose only skill is maintaining old (legacy) code and who is unable to use new technologies or create anything new.

Let’s be honest: nobody wants to maintain old code. Most of us—possibly 100% of readers—want to create new processes, new apps, everything new all the time. So having someone who doesn’t want change isn’t completely negative.

You can almost always feel free to assign them all the bugs and all the minor changes that require domain knowledge to execute since this person will have worked for years on that code and knows it inside out.

That said, it’s almost impossible to convince them to change or improve. In the world of microservices, there isn’t as much problem, but with monoliths, it’s very difficult to introduce any change or improvement, as their response when you ask them to do X or Y will be something like, “We’ve always done it this way,” “It takes too long to do this, we’re not going to redo it,” and so on to avoid change.

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

Thankfully, this type rarely becomes a manager. But when they do, the company is at serious risk—updating will never happen, every improvement will be denied, and inevitably, the company is destined for failure.

Conclusion

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

Of course, not everyone fits into one or the other; typically, people are a combination of several, as well as having some part that’s “normal.”

Unfortunately for many, maintaining old code isn’t a choice but an obligation, and although they’d like to change, due to the company’s circumstances they can’t. To all of them, my deepest sympathy. Study and change companies—you’ll be better off for it.