HackerNoon.com
Published in

HackerNoon.com

8 Simple Steps to Make Other Developers Hate Working with You

1. Arrogance

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

2. Sloppiness in the Work Delivered

  • 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)

3. Disrespect of Other People’s Time

  • 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

5. Greediness

6. Disregard for The Team

  • “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

  • 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)

8. Lack of Accountability

What to do if you have one on the team

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

Before you go…

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
John Lafleur

Co-Founder of Airbyte, the new open-source standard for data integrations. Author at SDTimes, Linux.com, TheNewStack, Dzone… Happy husband and dad :)