Programmers Need Deliberate Practice

TL;DR;

• Consistent, effective practice is a key part of a healthy, enjoyable career.
• Most people practice without purpose.
• This means they either quit and/or learn less than they could.
• Read this for inspiration on how to take a more considered approach to your practice.

Note: I'm English, but opted for the US English spelling of 'Practice' throughout (as opposed to 'practise/practice') to avoid confusion with the difference in spelling within the term 'Deliberate Practice'.

Practice?

I think we can all agree on a couple of things:

1. People who are experts practice often.
2. Experts are extremely disciplined with their practice.

This will generally come as no surprise when mentioned, and people will rarely argue those points. They make sense.
Thanks to the growing number of interviews and podcasts - experts are getting more limelight, and we're getting more sneak-peeks into that practice routines, habits and rituals (podcasts like Tim Ferriss' are awesome for this).

However - the one thing that does surprise me when I ask my peers what their practice schedule/routine is - I'm met with blank faces/realisations of "oh, I don't have one".

If they do - it will likely be something that will be pretty loose/unregimented. So if then prodded on the effectiveness of that practice - we're back to blank faces. I don't want that - I want to meet up with people and have them bursting with excitement on how they're growing.

The idea of effective practice has been has been solidified with the concept of deliberate practice. That we shouldn't just "go through the motions" - but need to take a considered, thoughtful approach to our practice - that ensures we get outside our comfort zone and grow.

This is important - because I feel this is something that is sorely missing from the tech community generally. Many of us tend to hack around on things, work on side projects, contribute to open source etc. - which are all AWESOME. But how many of us take a disciplined, thoughtful approach to learning, growing and honing our skillset?

To be clear - I've been hit-and-miss over the years as well - which is why I'm spending real time on it now, and want to help you while I'm at it!

This is important and something I deeply care about - we're all time-poor, and what you spend you aren't getting back. Make it count!

Common Problems with People's Practice

1. They don't have one! Pretty self-explanatory.
2. Lack of direction. They do things 'just because' - and work through the motions rather than aim for growth.
3. Lack of relevancy. The practice doesn't seem relevant/useful to their day-to-day, so they either don't engage well with it - or bin it.
4. Scope too large. They never get to an "ah-ha" moment - normally ending the session with frustration and lack of desire to come back. This often occurs when we either don't have enough direction/leading questions and/or we've not identified the 20% we need to practice to give 80% of understanding (see 'Pareto Principle').
5. Additional noise unrelated to the desired growth area. Perhaps you want to practice with a certain design pattern, but spent over an hour battling framework incompatibility issues instead.

But What About Katas?

I know some of you are thinking "Rob! I know, this is why we do Katas!". I hear you, but I've been doing and leading these for years and I have to say - the results vary wildly - sadly leaning on the side of 'poor'.

For the uninitiated - a 'Kata' (the term taken from the usage in martial arts) is essentially repetition of a problem to see how we solve it. Better people than me have done a lot of write-up on this - so check out the links if you want more info. Essentially a kata will play out like:

1. Bunch of coders get in a room.
2. They solve a pre-defined problem.
3. They discuss their code/thought-processes/lessons learned etc.

Now, these are great - and if you've not done one. Do! They're great fun, and you will learn something. I'll link to a few at the end of this post for you.

I think part of the problem is that perhaps 'Kata' isn't an adequate analogy. Katas are about increasing muscle memory or certain movements (getting progressively harder as you gain skills). I think Katas like this have a place, and I will continue to do them (The Gilded Rose is awesome, for example). But I think there's a missing piece - and once found (and done well) you can do away with 'repetitive' Katas all-together.

The goal of this series of blog posts is to help do just that! 🥋 😁

If Not Katas, Then What?

I'm not suggesting you do away Katas. I don't care for reinventing things that are (mostly) working well. Let's just change up how you prep for them. I always think "3 P's":
1. Purpose - Why are you doing this? Is it meaningful to your life right now?
2. Plan - How are you going to effectively meet the purpose of the Kata? (Read: "remove the noise, stay focused, get outside comfort zone, learn").
3. Progress - Reflect. What did you learn? What didn't you learn? (You may discover way after doing the Kata! Go back and update it!) How will you take this forward into current/future projects?

Now each Kata should standardise points 1 and 2 (Purpose and Plan). Most katas lack focus (sound familiar? 'Stories' anyone? Cough 😂) and/or don't get you reaching outside your comfort zone enough. Many people will solve the problem with what they know, and quickly move on. If you take just one thing from this post - take 5-10 mins to think before you practice about WHY you're practicing.

Point 3 (Progress) is often done well (I always enjoy the group chats) - but I rarely (if ever) see Katas refined.

So, let's walk through some quick examples! .⚠️ This series of posts will go into more detailed examples - this is just a primer to get you going/thinking!

Ideas to Get Started/Improve

Gilded Rose

This is one of my favourite Katas - and it will always have a special place in my heart. So let's start with that one.

1. If you've not done it before - just do it as per the README. 🚧
2. Now consider the purpose - we're talking about refactoring here - so what common problems come in to play? The goal of refactoring is to make the code easier to understand and (perhaps) easier to extend in the future. Here's some ideas:
   • Pair up with someone else! Does the refactoring make sense to you both as you go?
   • "Person down the hall test" - fly solo and then have a peer review your code from cold at the end. For an added twist - submit the code anonymously, and only let them view it as a pull request. How quickly can the understand the code and the reason for your changes?
   • Define one or more additional requirement - but keep it secret until the end of the Kata and ask participants "What if?" The purpose is then the conversation, not the code.
   • Consider the test runner output - if there's a failure when adding new behaviours - do those failure messages make it clear what the expectation is?

Frameworks, Patterns and Paradigms

Last, but not least to plant the seeds of some of what's to come in this series. What about frameworks, [design] patterns and [modelling] paradigms?

Now these are everywhere - likely cross multiple layers (which each has their own purpose. But here's some points to consider for some common ones:

• UI - How do we bind to the UI to data? How do we maintain isolation across elements? How do we isolate elements to begin with? How do we cache content? How is that parameterised? How do we bind elements to data? What trade-offs does that design bring? How do we augment content based on device capability?
• Data modelling (and implementation) -
• Database access (and ORMs) - How do we do basic CRUD operations? How do we do single property/column updates? How do we examine the execution plan and/or examine query performance? How/when do indexes/pages lock? How do we effectively partition data?
• Messaging - What options do we have for sending messages across boundaries? What about receiving and processing them? What trade-offs do each entail? What patterns exists for common systems (e.g. eCommerce, Chat, Streaming, Gaming)

Others

Other (but equally important) areas to note:

• Algorithms - What algorithms can be used given the problem? What are the pros/cons/trade-offs?
• Data Structures - Similar to the above - how can the data structures used by the code be changed/effect the outcome?
• Performance - Under what circumstances does your code perform well? When doesn't it? Are those OK? Practice identifying the usage patterns and explaining them to mere mortals ☺️

In Summary

I hope I've given you pause or thought about your practice. Practice is good - great practice is better. Take time to think about the problems you need to solve and create a method to solve them in a way that gets you growing.

I look forward to sharing more about how I do this - code and all - in this series.

Until then - happy hacking! 🤩💻

Links

Some are Amazon links - for which I am an affiliate. I wouldn't recommend books that I've not read and enjoyed. 😉

• 'Deliberate Practice' on James Clear's site (Author of 'Atomic Habits') - contains some great links to other good articles, too.
• The Tim Ferriss Podcast - Very high-quality interviews of high-performers from all walks of life.
• The Gilded Rose Kata on Emily Bache's GitHub (Author of 'The Coding Dojo handbook')
• CodinGame - Great source of problems to solve, with a web-based IDE. I use this almost daily!
• codewars - Another great source of problems to solve.
• CodeKata - One of the original sites - although I don't think it's actively maintained/contributed to any more. There's some classic problems on here worth checking out though.
• Kata-Log - Nice little library of Katas, including the Bowling Game Kata.