At times in the past, I’ve been struck by how different my pull requests (PRs) look than my colleagues, especially the ones who are earlier in their careers, or just newer to working on software teams.
Often, my PRs are smaller in terms of lines of code (not because I’m code golfing my way to the smallest code footprint), but larger in terms of my communication about the code. Though I like to think the code I write is mostly self-documenting, I’ll still write up a detailed description, or add quite a few clarifying PR/code comments. Often I’ll have more words in English than lines of code! I tend to put a good deal of thought up front and along the way, and so I try to communicate as much context as seems reasonable.
This is in very clear contrast to some colleagues who just seem to produce lots of code, but are constantly introducing bugs, or leading us to situations where we have to go back and rethink the things they did. Or even if it’s great work, they still don’t show much effort in documenting or communicating their approach to others.
Of course, much has been written about these themes, and people will have various styles and opinions, and that’s all well and good. Maybe I just have a high degree of conscientiousness.
But a shorthand way that I’ve come to think about this general theme is: the thought-to-code ratio.
For myself and other more experienced engineers I’ve worked with, that number seems to be generally much higher than that of our less experienced colleagues.
I’m not saying I’m an amazing programmer (I’m far far from it), but I do think it’s an interesting concept to reflect on.
How many of the so-called “10x engineers” have a high ratio? How many have a low one? When should you aim personally for a low ratio? When would a higher one make more sense? What ratio do certain organizations, cultures, or environments encourage? And what is the impact of that?
These are fun questions to consider!