Perfect Practice

In some discussion around becoming better developers a colleague at work mentioned something from his piano lesson days. They started out by teaching that “practice makes perfect”, but then later told you that wasn’t true exactly, because practicing can reinforce bad habits which are actually a significant set back, a more complete idea is that “perfect practice makes perfect”.

His question was, in the context of clean code, software development and estimation, how do we practice more perfectly? A good question I thought.

I didn’t have any good answer for that right away, and ultimately I suspect that has to do with it potentially being a category mistake where mental habits or behavior patterns aren’t of the same nature as physical or muscle memory type things.

Of course it makes good sense for playing piano or typing skills maybe. Building bad habits is to be avoided. It’s a principal that applies well to things in the realm of the body, but not so much for thinking work, - how to organize some code, make it readable, elegant - these are things in the realm of the mind. Maybe analogous with composing music versus performing a piece.

I don’t think there is really “perfect” practice when it comes things in the mental realm, in part because people minds work differently. Focus and distraction management practices come close maybe. Mindfulness certainly takes practice, but practicing in ways that are detrimental doesn’t seem like a problem that is real - ineffectual sure, but not like steps backwards, just not so much the forward progress you might hope for. Practicing empathy is also important here, but as for a right way to do it? … well, anyone claiming to know the perfect/right way to do that is going to be setting off all kinds of cult leader red flags in my mind. Still, empathetic thinking is pretty key if you want to make your code (or any language maybe) cleanly communicate all that you intend it to as well as having it not communicate stuff you don’t intend it to. A good mantra in this vein of thought. “code is for humans.”

There are some things that make you bad at empathetic thinking, but I wouldn’t categorize them as bad habits as much a broken feedback loops. A short off the cuff list:

  • Limiting the people that review your code
  • Limiting the scope of what they review (only lines changed is often insufficient - more context or background needed)
  • Limiting the time they have to think about it (I need this pull request reviewed in the next hour so it can move to QA… etc.)
  • Now that I think about it there are a lot of parallels here to social media echo chambers

Also the stories we tell ourselves matter: “this problem is to hard”, “everyone else is more competent than me”, “we’re not progressing fast enough”, “my feedback is irrelevant”, “so and so would have gotten this done better and faster than me” etc. Someone elses response to the original “perfect practice” question was how important retrospectives can be. I think part of that is because it tends to correct these sort of false narratives.

A couple other bad-habits in no particular order:

  • TODO in the code and forget about it. This is the laziest form of backlog - not always bad in itself, but almost always insufficient
  • Always thinking today’s distractions were a fluke. Tomorrow will be different.
  • Assume knowledge gain and skill building are automattic - e.g. not scheduling time to “sharpen the axe”

Again, I wouldn’t say these habits are as problematic as some detrimental muscle memory. There isn’t as much unlearning that has to happen here to correct course. This is a hopeful concept I hope, and why I decided to write it out. You are not damaged goods or an old dog that can’t learn new tricks. Keep moving forward.

Meet the Robinsons = keep moving forward