CEO @polarnotion. CTO @newstorycharity. Coowner @tenrocket & @sharpp. Run fast. Stay strong. Go boldly forward. Godspeed :: morgan@polarnotion.com

One Key Metric

“How should I measure my improvement?”

 
It’s a common question I receive from Apprentice and Junior Engineers. For those focused on growth, they often search for a metric to track their improvement over time. 
 
How will I be graded? What should I optimize for order to improve? How do I know I’m improving fast enough?
 
In software, ‘number of code commits’ and ‘lines of code written’ seems obvious. for early stage developers. It’s trackable and big numbers give the impression of progress. Unfortunately, code quality is not measured in quantity and volume. In fact, there is often an inverse correlation.
 
The question originates from a positive attitude, but the answer is complex and past attempts at oversimplifying have proven disastrous. There are stories of incentivizing engineers by ‘bugs found’, but that sparks the temptation to neglect proper troubleshooting up front. Incentivize overly-concise code and you may lose clarity. Champion lines written and things become verbose and bulky.
 
Reluctant to ignore a challenge, I sought out to answer the question. If an aspiring engineer were to focus on one key metric to drive their growth, what would it be?
 

Quantity and Quality

 
There was once a college professor working with a group of photography students. He divided the class into two groups and ascribed unique grading to each. Group One would be graded on quantity of unique photos. Group Two would be graded on quality of their photos.
 
In the end, the group of student who focused on quantity actually had the highest quality as well. They tinkering with lighting, unique subjects, and diverse settings. This resulted in better work over time. The quality focused students toiled longer per shot. They overvalued each interaction with the camera.
 
The moral for software engineer is not to write more lines of code. Instead, the focus on quantity should be around consecutive days. How many consecutive days can you try to apply the skills and techniques I’ve learned? Continual, deliberate practice. 
 
As I look back over years and millions of lines written, consistency has been my greatest strength. Early on, I was writing software every single day. Even if for a few hours, I was putting in the time to polish and refine my craft.
 
The idea came from my cross country coach. He would remind us that every day you skip a run, you loose 10% of your training. You slow the momentum and miss the opportunity for the effort to compound. He may have been wrong, but the idea anchored in my mind. I could sense the ‘ramp up’ time on Monday was longer when I would neglect Saturday and Sunday practice.
 
I later learned this was the exact approach Jerry Seinfeld used when coming a comedian. He had a calendar where he put an ‘X’ each day he practiced. The only goal was to not miss an ‘X’. If you miss once, don’t make the mistake of missing twice in a row.
 

Let your mind rest

 
To be clear, I’m not advocating for endless hustle and grind. Your mind certainly needs time to rest. Every day doesn’t need 8+ hours of heads down time. That’s unrealistic and ill-advised. However for less experienced professionals, longer gaps require more time to get reoriented. 7 days spent working 4 hours is far more impactful than 5 days working 6 hours. Adding up the hours is misleading. The consistency is what leads to the greatest impact.
 
I would encourage you to use the grid on your Github profile to track your progress. Early on, my goal was ‘no white squares’. That means I would need to write at least one commit worth of code per day. That’s it. I found myself doing more, but there was no bonus for more commits. That starts incentivizing the wrong behavior.
 
If you want to get better, it will take time. There is not path to meaningful, overnight success. Buckle in and keep showing up.