Source: https://dzone.com/articles/how-to-make-other-developers-hate-to-work-with-you
Nobody wants to be that developer, or work with them. Take a look at how what you may be doing that your coworkers wish you didn't.
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.)
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 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 names that are 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 the first point.)
3. Disrespect of Other People’s Time
The two things 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 a mindset to develop and then slowly trace back to
where they left off. And every 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 stuf.
- 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. 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. Showing 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.
