We are practicing to get better at what we do. We want to do deliberate practice to make sure we are maximizing our growth and learning from any time we spend practicing. So how do we know what is deliberate practice – as opposed to just … practice. We need to test ourselves.
Peter Drucker famously said, “What gets measured gets managed.” This is true whether the effect is helpful or not, so we have to be careful about what we measure and how we do it. I have to measure my progress somehow.
If I’m trying to lose weight, a scale can be helpful, sometimes, but a better measurement would likely be a body mass index. Building up muscle, which is denser than fat, is good for me, so it may not be a bad idea to put on weight. I just want to have it transformed from fat to muscle. If I just focus on getting lighter, I could be losing both fat and muscle which would be the opposite of what I want!
So let’s take a closer look at how we might test ourselves effectively to measure progress in our software development skills. For typing speed, it’s pretty simple. Is my speed improving? Can I maintain my speed while adding numbers and punctuation marks?
If I want to learn the keyboard shortcuts for my IDE, IntelliJ has a plugin called “Key Promoter X” that will keep a count of every time you use your mouse to select a menu item rather than use a keyboard shortcut. You can reset that number and keep track of it to mark your progress in a particular keystroke. Nice!
What about learning about design patterns or code smells or refactoring techniques? That takes some extra effort. Here’s what I suggest:
Design Patterns: Once a month, or every few weeks, sit down and go over the list the names of the patterns you know. Then pick a few and list the reasons you would use each, and the reasons you would avoid it. Perhaps drawing a quick diagram of the objects. Then you can compare your thoughts against your reference and see how you did. This helps you to quickly see where you need to review.
Similarly with code smells and refactoring techniques, look at a list of code smells, pick a few and record the refactorings that you might apply to each and why. For refactorings, you could look at your list of refactorings techniques, pick a few and describe the steps to perform it. Or the keyboard shortcut to execute it in your IDE. Or which related design patterns would be best to move towards, and why.
Of course, cheating doesn’t help. You want real results, so you want to shore up any weaknesses or misunderstandings. The goal is to have the tools you need instantly at hand without you having to live in Google all day (and probably end up distracting yourself!). These are simple ways to test yourself, but you can probably think of different and better ways to do this.
What is an effective way to test yourself in your practice sessions?