Why You Shouldn’t Judge A Developer By How Many Lines Of Code She Pushes
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.
How Hopin’s CCO Knew a Startup Environment Was Right For Her—and Two Questions to See If It’s Right for You
If there's a thread that connects all the different facets of Rosie Roca's life, it's the power of bringing people together.
From how she was raised, to how she got her first job, to the decision to leave enterprise software to take on her current role as the Chief Customer Officer at fast-growing events technology platform Hopin, a focus on community has helped to guide Rosie's decisions.
After a brief hiatus, we're picking our series of diversity, equity, and inclusion (DEI) terms back up!
This month we're looking at different ways of addressing people with disabilities.
In honor of Black History Month, we've been reading some of the great books written by four of the talented Black speakers that joined us at our recent Diversity Reboot Summit—because Black History Month isn't just about looking to the past, it's about elevating the Black voices that are helping to build a better present and future.
Have you read any of the books below? Let us know what you think!