Net negative producing developer

This blog post is about an anti pattern – and on top contains another anti pattern in itself (in my opinion). So what is a net negative producing developer? Originally described by G. Gordon Schulmeyer in the early 90’s, it’s basically a member of a (software) team whose contributions to a project result in more harm than good. While this may seem counterintuitive in a field built on innovation and collaboration, there are several underlying causes and potential solutions to address this challenge.

One common cause of the net negative producing developer is a lack of alignment with the project’s goals and priorities. When developers are not clear about the project’s objectives or their role within the team, they may inadvertently introduce errors, create technical debt, or derail progress. Similarly, poor communication and collaboration can exacerbate the problem, leading to misunderstandings, conflicts, and inefficiencies.

Photo by Mimi Thian on Unsplash

Another contributing factor is a lack of skill or experience in a particular technology stack or domain. Developers who lack the necessary expertise may struggle to deliver high-quality code or contribute meaningfully to project discussions, resulting in delays and frustration for the team.

To address the issue of the net negative producing developer, organizations can take several proactive steps. Firstly, clear communication of project goals, expectations, and priorities is essential to ensure that all team members are aligned and working towards a common objective. Providing ongoing training and mentorship opportunities can also help developers improve their skills and stay up-to-date with emerging technologies.

Additionally, fostering a culture of collaboration and feedback allows team members to share knowledge, support one another, and address issues proactively. By promoting open communication and a growth mindset, organizations can empower developers to learn from mistakes, iterate on solutions, and ultimately contribute positively to the success of the project.

And what is the anti pattern of the anti pattern? I genuinly believe that the behaviour of one team meber is heavily influenced by the whole team (see Levins formula). So an “individual blaming” is cheap, but denies the underlying systemic cause of the problem.

Links:

https://wiki.c2.com/?NetNegativeProducingProgrammer

Original article: https://web.archive.org/web/20011023084845/http://pyxisinc.com/pyxis_artmain.html