For people who aren't familiar with software development, it can be easy to assume that all developers work in the same way. After all, estimations of a task's difficulty (whether you're using days, points, or some other metric) leave little room for distinction between developers. There are junior, senior, and lead engineers, but what about good and bad engineers, and the differences of productivity and quality between them?
Former software developer Piet Hadermann takes on this topic in his blog post "Your Developers Aren't Bricklayers, They're Writers." A good developer, he explains, is not difficult to define: it's someone who writes well, logically, and with very few bugs. According to Robert Glass, author of "Facts and Fallacies of Software Engineering," these good developers can be up to 28 times better than bad developers. How is that even possible? It's simple: better code leads to less pressure on managers and other developers, fewer unexpected bugs, a more reliable product, and a stronger, more productive team.
In contrast, bad developers, can make the coding process way more complex. Not only do they write bad code, Piet says, they spend too much time on illogical code that's difficult to maintain and is riddled with bugs. A single QA cycle with bad code can take weeks and result in an abundance of new bugs. Two or three QA cycles later, the release is late, other departments are unhappy, and the team's productivity has already suffered greatly. When you take this bigger picture into account, it's not hard to see how the quality of a developer can have such a profound effect on an entire team.
Making a distinction between good and bad developers isn't about pointing fingers or shaming certain people. It's about making sure that good developers are celebrated, rewarded, and fairly compensated for the quality of their work. It's also about helping non-engineers understand that every developer is different, every team is different, and trying to force standardization between them can often do more harm than good.
People who don't understand software development often think of it like factory work — as long as you churn out "X" lines of code each day, you're worth "Y" salary. But this simplistic view ignores the differences between how individuals work, and the quality of work they complete. In order to foster a cohesive, productive work environment, it's imperative that non-engineers begin to better understand this concept.
To read more about Piet's experiences with measuring developer productivity, check out his original blog post here.
