Rewiring my code habit

Mar 19, 2026

Unknowingly breaking Goodhart's Law, and evaluating my coding habit

When a measure becomes a target, it ceases to be a good measure.

-Goodhart's Law

If something feels harder than you think it has to be, there is a strong chance you're right.

The habit

For the past 199 days I have kept up with a coding habit that goes roughly like this:

pick a problem (often from leetcode)
set a timer for 20mins
attempt to solve it before time runs out
review attempt once time expires, checking for correctness and/or optimization

Originally the purpose of this habit was to:

Keep my 'core' programming skills sharp (writing code to solve problems)
Be ready for tech interviews (leetcode style)

Lately an additional and insidious step has snuck in after the review step:

Become upset and distraught when I fail to meet this (as I now know) unrealistic expectation

It appears I unknowingly slipped into a pattern of making the measure (of being able to devise an optimal solution in the time limit) my daily target. This is neither realistic, fun, or healthy to target on a daily basis.

I suspect interviews are fluid situations where the questions you raise, and your approach may be just as important (if not more so) than providing The Answer. You even see this fluidity mentioned in the annals of the sacred tome:

There's no "right answer" here; you should discuss this trade-off with your interviewer.

Cracking the Coding Interview, pg 234

Chapter 3 Solutions — Follow Up: Implement popAt(int index)

That's just one example. Come flip through the book with me, I'm sure we can find more.

It dawned on me that:

Most questions may not be fully solvable in a 20 minute time frame
Often there is not even One Right Solution
There is a lot of overlap, and ambiguity in learning vs practice, preparing for interviews vs problem solving
This habit should NOT be a daily technical interview habit (that is insane)
This habit SHOULD be a daily coding puzzle/problem solving habit

Ideas:

maybe some days I can just do easy problems, but other days I can save time for working on harder problems
Only reflect on time and space constraints intentionally to learn it
I need to make this fun again
I could plan it like I do my running/exercise

every day I AT LEAST stretch (spend time on an easier problem)
Most days (when whether cooperates) I can easily do 1 mile (solve an easier problem, work towards harder
~2-3 days a week I can run 5k (new harder AOC type problem)

Comparing it to exercise

What if I planned my coding just like I did my exercise? I mention my exercise routine because for me it feels predominantly "solved" at this point. It is much more of an additive habit that brings me joy, and keeps me regulated, than it is a drain on me. In fact I would say not doing it has a negative effect on my mental and physical well being. It also feels mostly effortless to maintain and improve on.

At the end of the day systems are better than goals, when it comes to habit formation. Although sometimes you don't need a system just do the thing.

Rethinking the habit

I still love writing (writing as in me, yes I do mean me, clacking away on the keyboard) code to solve little problems. Which sometimes feels like an outlandish or sub optimal choice in this day and age, but what can I say I do enjoy it, and I think there is value in it so I'm gonna keep clacking.

Perhaps I need to mentally separate this practice from learning Data Structures and Algorithms and practicing for technical interviews. Interviewing is an intense situation (sometimes it could even last a whole hour and half), and not, in my mind, meant to be replicated on a daily basis.

Moving forward

Experiment with the Fitness analogy.

Deemphasize achieving the outcome of providing an optimal/correct solution in time.

Emphasize enjoying problem solving with programming, knowing it's ok to pick up with the same problem tomorrow. Heck treat it as a bonus, and golf it the next day if you want.

Use a timer strictly as a tool to keep myself focused, not as a metric of success/failure.

Experiment with 'easier' problem sets (rosalind).

Consider this habit a daily touch-point for problem solving with code.

Keep it fun, stay in the goldilocks zone.

Also a dope Tipper track: soundcloud-Goldilocks Zone

Anyways, this felt like an Aha moment to me so I thought I'd make it real by sharing.