Looking for Developers? Meet the 10 Developer Archetypes you will find

I’ve learnt one important lesson in my years of building different products with Altar.io & 10kstartup:

Don’t look for the perfect developers, look for a balanced team.

That’s our sweet spot for one reason: there is no such thing as perfection and building a good product is never a one-man-show.

Creating and keeping a balanced dev team is a very challenging art, due to these 2 characteristics of developers: (i) generally speaking they are not the most skilled communicators and; (ii) they tend to be fiercely competitive, especially when it comes to tests of intellect.

The 10 Developers Archetypes:

  • The Average Coder
  • The Wolf
  • The Narcissus
  • The Idealist
  • The Shy One
  • The Hitchhiker
  • The Imploder
  • The Safe Player
  • The Bad Ass
  • The Puritan

 

The Average Coder is perhaps the most common. He might sell himself in different ways, but but he tends to be average in everything he does – with the exception of gaming. He has average standards and mediocre ambition, he wants a predictable workflow in his backlog to deliver it quietly and he’s not very keen on bug fixing because, in his point of view, that means moving back in his backlog.

Comic Situation: 

Should you hire this developer?
Being the most common archetype, the Average Coder is the easier to get in the market. Eventually you’ll be hiring some Average Coders in your team, but it’s important they don’t come onboard until your developer team is at least 20-strong.

Note: we don’t have average coders @Altar.io.

Warning if you consider hiring one:
Small teams need commitment and this person will never question your decisions or suggestions, which means he / she is not committed.


 

 The Wolf is a dream developer, totally unbalanced and eternally optimistic. You will try to include him in all projects because he’s hyper productive, codes very quickly and never delivers less than solid code.

He makes great architecture decisions, he is always aware of best practices and new technologies and he already tried and benchmarked different architectural decisions before he presents the solution to be adopted.

He is a good team player, talks when necessary and he understands and respects business and product decisions. Is he / she a problem solver? Well, you’ll never be worried when one is around because things will be solved. They often also have the rare ability to read your mind and predict your needs, which is kind of weird but indeed handy.

Comic Situation:  

Should you hire The Wolf?
Positively! You should find all the Wolves in town but sadly there aren’t many.
Unlike 80% of developers, The Wolf understands business and product priorities even if they don’t meet his dream roadmap. He’ll try to help as much as possible to get the team together to achieve your goals. Only 1 developer out of 1000 is probably a Wolf. We have a good eye for Wolves, so we proudly have more than a few working @Altar.io.

 

Warning if you consider hiring one:
Wolves are ambitious and constant learners, so their stability and loyalty will quickly disappear if they’re not feeling stimulated with projects and by their peers. They also tend to be optimistic in their judgement of projects and have difficulty saying ‘no’ – so sometimes they’ll accept work and timelines that are nearly impossible to achieve.

 


 

Very similar to The Wolf but he comes with significant differences that have a tremendous impact – possession of a much bigger ego and poorer communication and team skills.

While most developers are highly competitive, the Narcissus takes it to a higher level. He wants to be recognized as a genius at the point that he often falls in his own trap: he tends to over-engineer simple things to create the “perfect systems” and refuse to compromise, he always refactored code to be fully irrepressible even if this takes 1000% of the expected time and even if it is not exactly what you wanted.

In a nutshell he goes with Maximus motto: “What we do in life, echoes in eternity!” The best way to manage a Narcissus is to present them with a very specific challenge and discuss the solution in detail. Just like the Wolf, they’ll find the best solution, within budget and in a very reasonable timeframe. He is a nice chap and tends to be smooth with his fellow developers although he often recreate their code to openly display who’s in charge.

Comic Situation: 

Should you hire this developer?
You should only have a one in your team – but you’ll need someone strong enough to keep them in check. But remember he doesn’t like to be controlled because he feels overshadowed.

Warning if you consider hiring one:
If you give him big challenges and let him decide alone he will over-engineer as much as he can, because he wants to appear as the one-man-maestro that architectured and executed a masterpiece alone.


 

Mickey is an Idealist, only thinks about solutions in a quintessential form and has a very limited capability to compromise.
He proposes to adopt a new framework / architecture because the project will be more modular and scalable.
He wants to migrate the whole system to this new standard disrespecting the fact that it doesn’t have a meaningful community yet and that his peers will not know how to work with it.
Discussions about budget and timings will be rebuffed with arguments about how vital it is that their preference is chosen – and that you’d understand why “if you had vision”.

His motto is:

“Discard any language / framework that is > 3 months OR has a community > 300 developers OR > 3 developers in your team heard of it”.

Comic Situation: 

Should you hire this developer?
This developer is always on top of the latest trends – He knows all the new features of the new versions of all bleeding edge frameworks. Like the Narcissus, you should only have one if these guys in a bigger team.

With the correct structure around them they might make a difference, finding the best architectural option that no one else thought about.

Warning if you consider hiring one:
He likes to bring disruption but you’ll need to moderate the speed of new adoption. When you challenge his ideas for a change, he’ll endlessly argue with you to try to prove he’s correct: It’s important to remember while the facts and figures they’ll sprout are correct (i.e. faster, more scalable, more modular, etc) it doesn’t necessarily mean it’s a good idea to adopt it at this stage..

Also remember, if you aren’t using the latest – and riskier – technologies, they’ll soon lose interest in the project. If they have the space to shine they will be loyal – but otherwise don’t expect too much commitment to you or the project.


 

With their small ego, limited ambition and hatred of the spotlight, this person is the opposite of a Narcissist. If at all possible, he’ll work from home. If he makes it into the office, you’ll find him hidden in a quiet spot you didn’t know existed, trying desperately to avoid meetings.

While his work is diligent, it’s bland and unexciting. He will never surprise you neither for the positive or the negative side.

Comic Situation: 

Should you hire this developer?
Personally, I don’t have an opinion about the Shy One because we tend to have strong characters in our team @Altar.io But if you hire a Shy One, you can be assured of one thing – they won’t bring disorder to your team dynamics or disrupt the workflow or product.

Warning if you consider hiring one:
As they’re shy by nature and not great communicators, often what’s delivered will be outside the project’s specifications because they ‘didn’t want to disturb you’.


 

Fast programmer, delivers in half of the time, but never really closes his work. He is the antipode of the puritan, he wants to get things done and see things working and he will hitchhike his way to deliver faster than you could expect. He doesn’t document and he doesn’t follow documentation, he never follows instructions from QA and when he delivers something he doesn’t want to go back to the mess he created. He is a natural fast problem solver and he doesn’t believe in such things like design to scale or thread-safe.

Comic Situation:

Should you hire this developer?
If your team is strong enough, it’s good to have a Hitchhiker onboard. The best use for them is emergency problem solving and rough prototyping – and they’ll reach their goals far quicker than you originally thought possible. But everything will have to be refactored afterwards. Knowing how to deal with Hitchhikers – and in particular placing them in the right team – is something we value @Altar.io.

Warning if you consider hiring one:
He will tease the idealist and the puritan on a daily basis. Also you should never put him alone developing a big feature because he does not follow the standards or documentation. While their code will (somehow) work, it will be difficult for their peers to understand and change.
Hitchhikers are normally loyal by default but highly unstable – the result of which means if they receive a better offer, they’ll be out the door.


 

The Imploder tends to be a decent coder, possessing deep knowledge and is a productive worker. The problem is he’s an awful team player. He considers different opinions as direct challenges to his own bright mind, so won’t cooperate when the decisions aren’t his and his alone. Disagreeing with The Imploder runs the risk of them (subtly) challenging the role of your management team and the outcome of the project.
Their hostility to project managers means they’re often found whispering malicious company gossip in the ears of innocent new recruits.

By their nature, Imploders are volatile and unpredictable. That’s why in the back of your mind you have the feeling one day they’ll bring a baseball bat into work and start ‘rearranging’ the office computers.

Comic Situation: 

Should you hire this developer?
NOPE!! The Imploder brings bad vibes and instability to your team and development. Unfortunately we had imploders in @Altar.io. Not to repeat!


 

The Safe Player wants to keep his ass safe – he lives and breaths self-protection. He spends more energy and time ensuring he can’t be blamed in the event of things going wrong, than actually thinking about the best way to do a job. By nature, he’ll deliberately make the wrong choice for a product if it means his job is more secure – and he won’t think twice of blaming someone else for his mistakes.

Comic Situation: 

Should you hire this developer?
This person is an extreme version of the worst bureaucratic liar you’ll ever meet – never ever hire a Safe Player. He might be a good coder, but he also brings with him an awful mindset and a culture that can tear apart your team.
How to track safe players? I’d suggest asking about problems they’d encountered at previous jobs and ask for details about how and why it happened. Set them a trap and let them talk about how everyone else but them was to blame.


 

The Bad Ass is like the Average Coder with an extra dimension – he’s eternally grumpy and rude. The effect is you’ll think twice before asking him to do something – and then probably decide it’s not worth the hassle and do it yourself.

Comic Situation: 

Do you need this engineer?
Clearly NO! While the Average Coder is bearable, this person is dangerous to your business as they create tension among other workers. Remember it is very hard to distinguish an Average Coder from a Bad Ass when recruiting. I have to admit that we previously hired an ‘under the radar’ Bad Ass and saw for ourselves how their positive attitude to work when interviewed changed immediately once they started working for us.
Again, the best form of detection is to encourage them to talk about the pitfalls of previous projects and the people they worked with – and listen to their stories.


 

Don’t confuse the Puritan with the Idealist, the Puritan is a theory professor, obsessed with rigour and standards that comes with best intentions to the battles he starts. But 85% of the time they’re simply jeopardising a project’s progress with lectures in standards and process. They’ll needlessly stall meetings by discussing obscure aspects that aren’t – in their eyes –  100% by the book. In short, they have great difficulty distinguishing between a university theory class and a startup.

Comic Situation: 

Should you hire this developer?
Like the Narcissus and Idealist, it’s best to have one when there’s a large team. With the right structure he might become a vital player, working on key things that need a deep level of knowledge. At the moment we don’t have such a structure @Altar.io that justify the Puritan (a processualist).

Warning if you consider hiring one:
Remember Puritans aren’t feature coders – their interests are in PM processes, defining standards and complex architectural theorisation.


In summary, if you’re hiring or building a team, remember there is no such thing as the perfect developer. What you should be looking for is the most appropriate candidate for a specific role, while also keeping in mind the need for balance and cohesion within your team.

Glad to help if I can.


Your future app is here!
Simulate Pricing Start your Project