stonks go up

As you’re aware, I am a software engineer, therefore I had to make a decision regarding which sport to pursue: bouldering, hiking, or running. I ultimately chose running.

I consider myself to be neither exceptional nor inadequate at running; I fall comfortably within the realm of being overwhelmingly average. I determine this through the measurement of my progress. The journey I’ve taken to track my progress and enhance my running abilities closely parallels my experiences in software development within agile software engineering teams.

Just start

forest gump i just felt like running

One day, I simply laced up a pair of old Nike shoes and embarked on a run. I may have only covered a kilometer before feeling completely spent, but the satisfaction of enhancing my health motivated me to persevere. The idea of meticulously tracking my progress never crossed my mind; I merely headed out and ran. Initially, it was a kilometer, and after a few weeks, I extended it to 2 kilometers. Before long, I accomplished my first 5k run. The need for intricate progress tracking did not arise. Progress was a natural outcome of my consistent running routine.

This same principle holds true for app development. When starting out, there’s no necessity for elaborate methods to evaluate your performance. Engage in regular app development, and progress will inevitably follow.

Setting goals

After running the same 5k route along the river near my residence for several months, I noticed a consistent pattern in my departure and return times. Progress had come to a standstill. It was at this juncture that I resolved to undertake the challenge of completing a half marathon. Despite not yet investing in a Garmin watch or similar tracking device, I began documenting my running times in my journal and generating performance graphs over time. I engaged in research and introduced interval training to my runs to gauge its impact on my performance. This straightforward tactic catapulted me back into the realm of progress, propelling me toward my objective.

In my pursuit of creating an app to locate stolen bikes, the only critical metric I truly need to measure is the number of successfully located bikes. Complex A/B testing strategies or an overwhelming array of metrics are not necessary, at least not in the initial stages.

Supporting Metrics

buzz lightyear - metrics. metrics everywhere.

By meticulously recording my running times and adhering to a consistent running schedule, I accomplished my first half marathon this year, clocking in at under two hours. However, to break the one-hour barrier and cover greater distances, I realized that tracking extended beyond mere running time. Elements like nutrition and sleep significantly influenced my running performance, prompting me to include them in my tracking regimen. However, the impracticality of logging all these metrics in my journal led me to invest in a watch to streamline the tracking process.

Should my bike locator app experience a daily discovery of thousands of bikes, delving into what I term “supporting metrics” might become more important to improve customer satisfaction. This could involve assessing the dropout rate within the search process or gauging how many users overlook the notification indicating their bike has been located.


There’s usually only one real metric of success. Bikes located for my app, orders made in an e-commerce application, or customers transported for an airline. Focus on these first before you dip into the sea of all these supporting metrics.

so long

comments powered by Disqus