8 Simple Steps to Make Other Developers Hate Working with You

We’ve all read those 10x developer articles (I wrote some — guilty as charged!). So if you want to know what you need to work on to improve…well, you have plenty of resources. But I have very seldom come across articles on what NOT to do or how NOT to behave as a developer. And actually, this may be the most important part of the equation!

So, long overdue, here is what I think is the top list of behaviors you should really work on fast, if you do any of them ;). Why? Well, you might not know it, but your co-workers might hate you for them, as you most likely negatively impact the whole productivity of the team — at the very least!

If you have one of these developers on your team, it might be worthwhile to share this article in your Slack team channel — just out of general interest, you know 😉!

I will try to prioritize the list from most to least impactful. The goal for me is to start the discussion on the list and prioritize it, too. So please comment.

1. Arrogance

That’s the first one, in my mind. You cannot work with a self-absorbed developer. I’ll even go so far as to say:

As long as you are willing to take responsibility for and learn from your mistakes, you’re not a bad developer.

Arrogance makes you think that your code is perfect. You may even blame customers for being stupid and for crashing their program rather than reflect on why your software crashed. And that’s how you get:

But also messy, unreadable code for your teammates.

The problem with arrogance is that it is a behavior that will prevent you from improving. Stop being arrogant, or you’re just a lost cause.

Some of you may already know the Dunning-Kruger effect. We will mention this effect a few times in the list. Here is a graph explaining it:

The issue with arrogance is that 1) the developers don’t understand they are on top of the Peak of “Mt. Stupid,” and 2) they will stay there.

2. Sloppiness in the Work Delivered

There are many ways developers can show sloppiness in the code they deliver. We all know at least one developer who:

• gives cryptic names for variables, or at best not self-explanatory
• puts typos in function names
• leaves old, outdated comments in the code
• shows a poor selection of data types and data structures
• doesn’t bother to run the code formatter, despite being told many times to do it
• ignores the IDE warnings
• copies and pastes StackOverflow code without understanding it or tweaking the solutions to fit their own code
• doesn’t take the time to document code (nobody wants to read the whole function or file to understand what it does)
• doesn’t handle errors properly
• uses excessive dependencies, and updates them without thinking
• doesn’t bother to understand the libraries or tools added to the code, potentially leaving glaring issues
• will always insist on following “best practices” without understanding why those practices are considered “best” (there is no such thing as best practices that adapt to every team)

Don’t be such a developer. They annoy the hell out of their colleagues. They slow the whole team’s development process down, requiring their teammates to spend unnecessary time on their code reviews. Their team will dread those code reviews, will grow impatient (we’re still humans), and bugs will get through the net.

The best way to solve this is for these developers to start to take pride in their work (not to be confused with the arrogance mentioned in point 1.

3. Disrespect of Other People’s Time

The two thing developers hate most are interruptions and unnecessary meetings. That shouldn’t come as a surprise, as meetings are just scheduled interruptions. Developers can’t easily go back to where they were right before an interruption. They need to get into the mindset for development and then slowly trace back to where they left off. And every fellow developer knows that.

So, here are a few ways you can show disrespect to your colleague’s time and productivity:

• interrupting another developer who is clearly in the zone, for non-important stuff;
• constantly arriving late to meetings, which is a definite choice — whatever anyone says. Either the participants must wait for everyone to be there to start the meeting, or they start without the late developer. In the latter case, he or she will need to be brought up to speed at some point, hence some time lost, and arriving late will disrupt the flow of the meeting in any case;
• rambling on and on during meetings. Or, if there are non-coders in the audience, being unwilling to adapt to the audience and wasting time for the entire audience, as any point made will need to be explained again.

4. Constant Negativity

Most developers are enthusiastic people, but sometimes you may have the chance (or misfortune) to work with a negative one. Negativity is infectious. If someone complains, it focuses the attention on the negative side of things.

They will criticize every choice made: the language, for instance, although, most of the time, those developers are clearly at the top of Mount Stupid (in the Dunning-Kruger Effect).

Don’t misunderstand me; there should be some criticism in the form of constructive opinions. For example, a Scala developer could talk to a Java developer about promises, saying, “Okay, your language is not as good as mine :P. But you could try CompletableFuture to have a taste of what a monad is. I will show you what you can do with that.” But unfortunately, that kind of friendly attitude is very rare these days.

5. Greediness

I’m sure you have all seen a developer once in a while steal credit for the work produced by a team. This can be done through an email to management, a 1-on-1 talk or another sneaky non-straightforward way.

Developers value competence above all. Taking credit for someone else is taking the other’s competence for yourself and removing it from him or her. This is pretty high up on my list, as I feel it creates a lot of tension and distrust.

For greedy developers, such strategies might produce short-term visibility. But in the long run, they will be alienated. Other team members will evolve their communication to highlight their contributions better. After all, there are many ways to give credit.

6. Disregard for The Team

Software engineering is done collaboratively with designers, product managers, and other developers. Respecting other people’s input and work is necessary if you don’t want them to go into Hulk mode and flip their desk. For instance:

• “How” documentation: many programmers comment on every single line of code without describing why it’s doing what it’s doing. If there were a bug in the program and you stumbled across this code, you wouldn’t know where to begin.
• Implementing an ugly or not-to-the-specs UI “because they’re not a designer”
• Not mentioning a UX problem to the product manager, because it’s not part of their job. Ignoring the big picture will make the software hard to use, expensive to maintain, and inconsistent with the other components.
• Not trying to understand how design or product decisions are made. And then continuing to ask the same irrelevant questions — and not improving.
• Not considering other team members’ priority dependencies and leaving them stuck in the mud.
• Using a new tool/library without warning any teammates. This can cause unforeseen issues down the line.

7. Lack of Focus

Engineering teams solve problems. They use their technical abilities to build features/fix bugs to solve those problems. And some developers just forget about this and will:

• philosophize about technical topics instead of focusing on the problems
• argue obstinately about technical topics without considering the initial problem (although you do, of course, need to argue when building the solution to the problem)
• have lengthy discussions about those technical topics yet rely on their own opinions (instead of facts — facts solve problems, not opinions)

With code, sure, you can have several solutions to the same problem, but either it works or it doesn’t; there is no in-between. With focus, you can easily alleviate all uncertainties by trying out code in a sandbox, for instance. But lack of focus wastes the time and productivity of everyone involved.

8. Lack of Accountability

As mentioned above, either the code works or it doesn’t…but it needs to work in combination with all the code being added to the codebase by your teammates. Software engineering is probably the most collaborative work in today’s world. Any code you write will interact with that of other developers.

So, for your team to work well, you need accountability. Sure, code reviews don’t let you get away with anything. But accountability is an attitude.

Unaccountable developers will, for instance, offer excuses instead of solutions. Those excuses may include time constraints or complexity of the tasks. Nobody wants to hear excuses; they want to understand the steps to be taken toward the solution. Excuses don’t invite others to help or provide a good picture of the task’s progress.

This is my list. Feel free to add more if you think of any, or to suggest a different order of importance.

What to do if you have one on the team

The first thing you should know is that this means your manager is not doing their job. The issue should have been identified and the problematic developer(s) coached — if they were deemed coachable. The manager should have given warnings and made the hard decision if the bad developers were still impacting the team.

A team with a bad developer is way better off short one developer than it is with a bad element.

A manager who doesn’t understand this is a manager who doesn’t understand software engineering. You have the case for a bad manager, but that’s for another article ;).

So what do you do? I would say this is a question to raise in your one-on-one with your manager, so they can address the issue. If your manager does nothing, you have several options: see if the developer can be coached, and take it upon yourself (and with the cooperation of other teammates), or change teams/companies. Hopefully, this article can help convince the said developer to be a better co-worker.

Before You Go…

Learned something? Don’t hesitate to share it to help others find it!

If you are interested in articles about engineering and product leadership, productivity and how to scale a team, subscribe to our newsletter!

Or join our Engineering Leadership Community.

Engineering Leadership Community | Anaxi_High-quality trending articles curated by the community on engineering leadership, productivity, how to scale teams and…_community.anaxi.com

You can also follow me on Twitter to stay connected. Thank you!

Originally published at anaxi.com on February 20, 2019.