Is The Code Good?
By Spicer Matthews
How do you know if a developer has written good code (even if that developer is you)? I’ve been asking myself this a lot lately. I really want to define the answer as thoroughly as I can, because if I have some strong criteria to follow, I can hold myself to highest standards and never fall short. Also, I can be a better manager if I have some strong guiding principles.
Steve Jobs was famous for asking employees if their work was their very best. If they did not clearly state “yes,” he sent them back to the drawing board. I am not willing to be that type of manager, however, I do want to be able to recognize when my team is not doing their best work.
To be clear: I am not talking about knowledge or CS fundamentals. I am really talking about things like, how clean the code is to read? Did the developer go about things in a simple way or an overly complex way? Is this code designed to support the future or is it just thinking about today’s requirements? And so on.
Judging Code By Bugs
All code has bugs, and I think watching a developer (or yourself) manage bugs as they are reported is a great measure of how good the code is. Over the years, I’ve observed that if a developer gets a bug report and fixes it right away, that is a sign of great code. Here’s my logic: If your code is overly complex, it’s going to take a while to debug and fix.
When I’ve written great code, I can fix bugs right away. The process of tracking down the bug is almost instant. I can do that because it’s code I’m proud of, and I wrote it from a place of passion. There is something about code you are proud of that lets you almost instantly zoom in on the problem and solve it right away. It is your baby after all, and you want it taken care of.
On the other hand, bugs from less-than-great code tend to linger. When a bug goes unresolved day in and day out, often the developer is avoiding it. That may not be on purpose, but with weak code, a developer just always seems to have a bigger priority. I say this is the subconscious convincing the developer to stay clear of the poor code.
Ashamed To Commit
When working on code, the frequency of a developer’s commit history is often a clue to how strong the code is. I call this the “ashamed to commit” problem. I think developers do this subconsciously; I’ve noticed that when someone is having a really great day, they tend to commit smaller chunks of code more often. It’s a backup. The code you have written is so perfect, you do not want to take a chance of losing it. But when someone is having an off day, I tend to see bigger chunks of code committed in larger gaps of time – almost as if they are ashamed to share their work.
Is The Code Good?
As I mentioned at the start of this post, I really don’t know what a good mix of metrics are to figure out if a developer (or myself) is writing great code, or if the cylinders are not all firing. This is something I am going to continue to study with the hopes of someday using my findings to make me a better manager and programmer. I’ll continue to share my findings along the way.
Do you have any red flags you watch for? If so, please share!