5 Different Software Developer Personalities That I’ve Met So Far

There are so many kinds of software developers on the work floor. Here are some fun descriptions for a few of them

After working for more than two decades in the IT industry, I’ve encountered many, many different colleagues. And in retrospect, I’m quite sure I’ve been several of the different types described below — throughout the years. Perhaps you’ll recognize yourself as well.

Let’s have a look!

Eager Junior

The fresh one. They have just finished their studies (or never started them in the first place) and are ready to rumble. They are full of energy and prepared to conquer the world in the upcoming weeks.

When they enter the room on their first day — you know something is going to happen. Their eyes are beaming and no matter where you are in the office, you hear their voices in the distance. They try really hard, and they smile all the time (which makes sense because they haven’t encountered bugs, deadlines, boring tasks, meetings, or feedback on their code just yet). Of course, they’re not familiar with jargon and terminology, so they’re stumbling over their own words when they try to explain all the awesome techniques and tricks they’ve brought with them.

And they code fast. Like, really fast. They’re eager to show off their skills, and they believe that they’ll earn credits when they write code as fast as they can. The fact that it’s often beneficial to make plans and think through all scenarios up-front hasn’t struck them yet.

They also don’t seem to care in the first weeks about the existing infrastructure. At any workplace, there are frameworks, design guides, habits, and protocols that should be followed and used. But the Eager Junior? They are not aware. They want to write code, and they want to write it fast. After they’ve blazed through their task, they’ll walk up to their superiors like small and cute puppies: Look what I wrote in just some hours!

They will always hit a wall, sooner or later. That wall will show them that it’s awesome that they’re eager — but that there’s more to this job than writing code.

It often leads to funny scenarios in the meeting room. During their first meetings, they try to contribute (read: talk) as much as possible. They talk out of line and don’t have a feeling for the flow of the meeting. And they very quickly realize that perhaps they don’t have as much knowledge as they thought they would have when they entered the doors of the office on the first day.

Their eagerness should be embraced and stimulated, but they need a lot of guidance. They’re like unguided missiles in their first weeks, and they can potentially do a lot of harm to existing codebases and teams. But with a good mentor and team lead they will quickly bring value to the team.

Someone just needs to pull their brakes a little bit.

The Turtle

The turtles are irreplaceable. They are mostly invisible, and you don’t hear and see them often. They just develop. They do what they’re instructed to, no questions asked. They’ve been there for some years already and have seen most of it.

When alarms bells ring and the ship is about to sink, they are the ones that respond calmly with: “Well, let’s have a look at it then.” And then, they slowly walk to the coffee machine, small talk with the person working at administration about the sports match from last night, and finally head back to their desk to fix the critical bug.

And they will manage. Because they’re damn good at their jobs. They just don’t like the fuss. More often than not you don’t hear them so much during meetings. Because why would they bother? As long as there is coffee in their Star Wars mug, their comfy slippers are keeping their feet warm, and their (custom built) Linux OS is performing well, they are content.

Wannabe Manager

You’ll recognize them when you hear them. These developers are the next Elon Musk or Steve Jobs. Not really though, but that's what they believe at least.

They are not the best developers at all, despite that being their role on paper. And to be honest, I tend to believe that this is the exact reason that they behave like a manager (without being one): because they realize they’re not the most brilliant developer, so they have to be on the lookout for other opportunities and career turns.

More often than not they are quite articulate. They talk fluently, quickly, and gather a lot of knowledge in short time frames. They’re up to date. Which makes sense, because you have to do something when you’re not writing code.

They laugh the hardest when the people higher up the ladder make silly jokes during a long meeting. And, on the positive side of things, they work hard and long.

But boy can they be annoying! Everyone realizes that they’re not doing their job; that they’re focussing on everything but writing code. They are a hurdle for the development flow within a team, and they often collide with the actual managers.

Most likely, one of two things happens: they either disappear silently and you’ll never hear from them again — or they are your next manager.

The Locomotive

The people that make the train go forward. The seniors, the sturdy ones. They think ahead, write unbelievably good code, see everything, and have a lot of knowledge. There are not many of them. But you know which ones belong to this category, without a doubt. You’ll hear them, see them, and their name appears in all the important places.

When you’re invited to an important meeting, you can be sure they occupy a seat around the table. And the next important meeting, and the one after that.

When there is an ongoing discussion in the communication channels, it’s almost guaranteed that they join after a while and write down a perfect solution with very few words. To the point. And then they’ll go on with their tasks.

The downside of locomotives is that it’s hard to argue with them. They can be stubborn and even a tad arrogant. They give you the feeling that you don’t know much, and that they know it all.

And whether you like it or not, that’s most likely — exactly — the case.

The Academic

Last but not least: a word about the scholars. The academics, the ones with the books. The walking dictionaries.

You come up with a solution? They can tell you exactly what the name of the relevant design pattern is, how this problem was studied in the past, and five better alternative solutions.

In theory, that is.

Having a conversation with The Academic developer often goes like this: They describe a scenario with many, difficult words. You hardly understand what they’re saying because you’ve never even heard of these terms and concepts. But after listening to them for ten minutes, you realize that they’re describing a submit button. So you plan your interruption and carefully ask:

“Do you mean… a submit button?”

A moment of silence falls. The Academic thinks a bit, then thinks a bit more, and finally replies, “I have to assume you could call it that as well, perhaps.”

They are great people. It’s very cumbersome to talk with them, but they mean well. They have a lot of knowledge, and they often want the same as you. They just use different words. A lot of them. Their ideas might sound very complex, but if you read between the lines they are just describing the same solutions as you want.

Final words

The five personalities described above are just a random selection that I find entertaining. They really do exist, and I encounter them on a daily basis. I could’ve easily selected five other types and wrote a similar article for them.

The IT world is filled with all kinds of personalities.

And you and me? We are one of them.

Thanks for your time!