It takes two to tango

Diving deeper into the communication gap between management and development, in our part 2, we will focus on the other side of the equation, the development side, and most importantly, we are going to discuss some developer types that, more often than not, tend to hinder the quality and the flow of day to day communications within a team.

Although the burden of crisp, clear, timely and efficient communication, in an organization, usually falls on the management side and thus most misunderstandings and miscommunications stem from bad managers, every professional relationship requires every party involved to work together harmoniously, with a common goal in mind, in order to thrive.

And, let's face it, devs make mistakes in that department as well.

Not because of them lacking social skills due to the absence of human interaction, adequate sunlight or any other cliché that has been used to portray the profession but rather, because they are humans and humans are inherently bound to make mistakes.

well, maybe except this guy?

So, without further ado, below you will find some developer types that can seriously harm the social fabric within your company, delay your projects and increase the gap between them and management ever so slightly.

#The One-Above-All

A wild, majestic, untamed, beast.

That person is by far the best developer you have in your arsenal and they know it!

So, what's the problem?

The problem is that they make sure everyone in you team, including yourself, knows it. They are the best and have nothing to prove to anyone! They are arrogant and completely disregard social norms as they treat everyone in the team as if they are beneath them making interactions a mixture of condemn, sarcasm and passive aggressiveness. They prefer to work alone and secluded as no-one is worthy enough to code side by side with them.

They see themselves as the sole source of valuable information and knowledge in your development team and as such, they claim to have total grasp over the end- product and absolute knowledge over the end-user and the market and therefore have no issue to disrespect their product/project manager during your daily standups (if they bother to show up) and point fingers when things go south. Not to mention that, they really do not care about Ubiquitous Language rules and use technical jargon in an effort to showcase how above-the-pack they are.

Code reviews and tests are thrown out of the window as no-one has the technical ability to even comprehend the masterpiece that is their code.

You can only admire it, you heathens!

#Ye Olde Developer

Old developer yells at IDE

The man, the myth, the legend. They have been with your organization ever since its original inception and were either among the founding members or among the first that have been hired. They have offered so much to your company that they could be included in the Hall of Fame. They had a primary role in developing the source code and the infrastructure of your original product and they feel they have a say in every strategic decision your organization tries to decide on.

However, despite their vast knowledge, experience and wisdom, they seem to cling on to the old days a bit too much, they are still using outdated technologies to do their work and resist change. Therefore, you can pretty much wave goodbye to efficiency and Agile Practices as they will be wasting time in every meeting reminiscing and narrating stories about the early days of the company and how things were running smoother back then, without the libraries, frameworks and methodologies "you young people" use today.

Their own fear of being left in the sidelines and turn into a relic, makes them sabotage any effort for improvement and advancement.

#The Bare Minimum

Not mandatory? Not doing it.

The epitome of apathy and a true nihilist, this developer seems like a phantom. Comes on time and leaves on time, while carefully planning how to divide their tasks in such a way, that they only spend 7 hours on them (not a minute more) and enjoy their breaks to the fullest. Then you may think to yourself "Hey there's nothing wrong with that. It's kinda efficient". Yes, in a sense, you are right.

But what happens when your sprints have to be longer? What happens when your team has to give a bit more than just the minimum?

You can count on this person to not be there. They will offer no additional value than what the title above suggests, they will not offer their opinion and expertise on any issue, simply because they do not care. They exist to do just as much as they are told and usually after they have been briefed thoroughly and in every single detail on their tasks as they cannot think for themselves, wasting your time and energy and letting them loose will probably cause more harm than good.

To add to the above, they show a lack of need to improve and seem content with their mediocrity which probably shows in their code where everything is unreadable, insufficient and buggy, so much that, your test teams will spend hours upon hours and increase their WTFs/minute to create something that is on par with your quality standards.

At the end of the day, they have likely offered nothing new to the table and only caused chaos and stress among the rest of your teams.

#The Pasta Chef

Way too multi-thready, mom's spaghetti

These people are in abundance in software development and have been since the dawn of time. Commonly referred to as the Cup Noodles of software development (not really; I just made that up) they are probably the fastest coders and always the first when it comes to delivering tasks which makes them look like The One-Above-All, albeit they are much worse.

You see the only common attribute they share with the first category is their sense of superiority which is usually encouraged by the fact that they are faster than anyone else. Therefore, not only will they make your meetings look like nightmares with their constant nagging about how the others are not quite at their level and how they bring the project down but also, waste so much of your team's time and productivity as their end result (the one they delivered so much faster than anyone else) is chaotic.

Such complicated. Much wow

When your project manager and/or your testing team sit down to take a look at the code they will soon realize why they deliver so fast.

An entangled and complicated mess, full of if-then-else statements with no comments, variables that only make sense in their heads and not in the context of the business domain, await them.
Oh, and bugs, so many bugs. It feels like they just copied some code from Stack Overflow and went on with their lives.

So, good luck with unraveling their spaghetti code and try to make sense of it. They have produced something inefficient, that cannot be easily improved upon, that cannot be maintained in the long run and they have no idea how bad it is.

Or they just won't admit it.