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.
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. Click To Tweet
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.
There are many ways developers can show sloppiness in the code they deliver. We all know at least one developer who:
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.
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:
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.
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.
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:
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:
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.
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.
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. Click To Tweet
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.