What kind of developer are you, and what is your quality reputation? If we tracked programmers like baseball players, what would we see on your “programmer baseball card”? Let’s compare two developers side-by-side that way.
Joe is a young developer who is valued because JavaScript is his first programming language—unlike some of the older members of the team. Joe is very popular with management because he has a reputation for being fast: he is never late with his sprint assignments, and he’s written more lines of code than anyone on the team. However, are these the right things to be valuing? It’s revealing to take a deeper look at Joe’s stats. He has a very high count of bugs found by QA. Although he fixes bugs rapidly, the number of bug fixes rejected is very high. This tells us that Joe is “fast” because he is not really finishing his work completely. His bug fixes are often incomplete and are likely introducing additional bugs as well. Clearly, Joe has some good points but has a lot to learn about quality: his net quality contribution to the team appears to be negative.
In contrast, we have Sam who at first glance does not seem to do as well as Joe in some areas. He’s written far less code, he’s missed more meetings, and he often doesn’t finish his sprint tasks on time. Sam does need to improve his estimating and his attendance, but we can see from his other stats that these delays come from Sam’s commitment to finishing his work and testing it well. He has far fewer bugs than Joe, fixes nearly all of them, and his bug fix rejection rate is practically zero. Moreover, Sam’s statistics improve each year. This is why he has a reputation for quality. In light of this, we can see the reason Sam writes fewer lines of code: it does not indicate low productivity; rather, he takes the time to get his code clean, right, and nicely factored.
Determine the quality reputation you want to have and let that drive your behavior.
The Programmer's Guide to Quality Assurance 