Introduction
Have you ever worked with a terrible developer? One who made your job more difficult and frustrating than it needed to be? Unfortunately, bad developers are out there, and it's important to be able to identify them. I've identified four critical factors that define a terrible developer, and this series will examine each of them:
- Lack of Collaboration
- Lack of Growth
- Lack of Big Picture focus
- Lack of Passion
And in this article, we will discuss the first factor - Lack of Collaboration.
Lack of Collaboration
I have divided the article into four parts based on the following traits:
- Stubbornness
- Arrogance
- Stupidity
- Lack of Empathy
Let's discuss them one by one.
Stubbornness
- They always think that they know better than others ❌
- They have problems following simple agreements and style guides on your project ❌
- They don't want to follow processes inside the team ❌
Arrogance
- They think highly of themselves and low of others ❌
- They have a tendency to blame others for their own mistakes, they also tend to blame others for not understanding their code or solution. They don’t want to take responsibility for their code and their solution ❌
Stupidity
- They want to reinvent the wheel every time instead of using existing solutions ❌
- They Make shitty code and when you offer help / criticize it they act as if you were the problem ❌
- They don't want to spend time finding the simplest solution or providing better and meaningful names in their code. They will tell you that it's a waste of time and doesn't matter as far as they understand it ❌
Lack of empathy
- They always pick only the most interesting tasks and leave other teammates with something difficult and boring. They lack empathy and struggle to understand others' perspectives or feelings ❌
- They don't think about others and more junior team members. They would blame teammates for being stupid rather than reflecting on why their software can be bad ❌
- They don't want to share their knowledge with others or document it somewhere ❌
Conclusion
In conclusion, a lack of collaboration is a major red flag when it comes to identifying terrible developers. The traits of stubbornness, arrogance, and stupidity all contribute to a lack of collaboration, making it harder for teams to work together effectively. By being aware of these traits and addressing them head-on, we can help create a more collaborative and productive work environment.
Top comments (4)
It seems to me that you had some frustrating encounters with people you worked with. If yes, where you able to solve or at least improve these situations? How did you approach these conflicts?
I would say most of these problems stem from individuals who haven't worked in a large team or organization before, and they can be resolved relatively quickly by privately discussing and highlighting their importance. However, in general, I would suggest the following steps:
Identify the issue as early as possible. For instance, conduct not only technical interviews but also culture interviews to identify such behaviors.
Establish guidelines for the entire organization as a definitive reference to determine desirable behavior.
Speak to the person directly or address the issue during retrospectives or one-on-one meetings with your manager.
If no positive changes occur, consider parting ways with the individual.
How would you approach to speaking to them directly? What if they state believable reasons for some of the problematic behavior. For example lot of stress & troubles at home? Mental health problems? Lack of psychological safety in the company / team?
I wouldn't say that I have much experience discussing these kinds of matters, and I can't offer any unusual advice because I'm writing from a developer's point of view. But if we're only discussing the lack of collaboration, I don't think there could be any excuses for constantly breaking agreements and creating more problems for others rather than solving them. For example, merging code without QA approval, skipping test writing, merging when the CI is unstable, or deploying after working hours (if prohibited by company agreements) etc.