Strategies

Thoughts on how to overcome some of the obstacles

Positive reinforcement

We are all prey to negative thoughts: “I suck, and I’m just not getting any better.”

Progress can be so slow sometimes that you aren’t even aware you’re improving.

Attitude is incredibly important. You really shouldn’t let those thoughts creep in. One thing that helps is to celebrate your successes, no matter how trivial.

Habit tracking

This sounds like the silliest “kumbaya,” self-help crapola imaginable (exactly the kind of thing engineers despise) but it really is a useful “brain hack” to celebrate mere attendance.

Post a multi-month calendar somewhere near your practice area, and every single day you practice at all, even for just a few minutes, put a big red X through that day.

Believe it or not, it really works. Your brain gets the tiniest little hit of dopamine every time you cross out another day. You get surprisingly competitive with yourself, too, not wanting to break a continuous streak. It will start to bother you if you see more than a day or two without a big red X.

Seriously, this one stupid human trick increased the regularity of my practice more than anything else I’ve done.

These days, I’ve started tracking my streaks with the strides app on my phone instead of using a wall calendar. I just say, “Hey, Siri, log guitar practice” out loud whenever I start a practice session. There are similar apps for Android like loop.

Recording yourself

One other positive reinforcement is to record yourself performing different songs or exercises periodically.

Trust me: The first time you listen to a recording you just made, every instinct in your body will scream out to delete it as quickly as possible! Try to ignore the instinct and hang onto it as long as possible.

Every now and then play back an older recording, the older the better.

It’s incredibly easy to lose sight of your progress. Improvements arrive slowly via small, incremental gains. But recordings just don’t lie.

Shortly after writing this, I pulled out my phone and played some of my old recordings. Most of them were pretty laughable — I’ve improved considerably.

Some of the actual songs I’d recorded, though, surprised me the other way. I’ve since forgotten how to play those songs, and my playing sounded far better to me now than I remembered it sounding when I recorded it. Sometimes you need a little distance to evaluate things. That’s also a motivation win!

Defining proficiency

Most drills and exercises in books, videos, or online courses only explain how to perform a particular drill. If they mention when to stop practicing at all, it’s usually some sort of totally subjective guidance.

The problem is that while they are prescriptive (“Do this, then do that”) they are usually open-ended: “Keep going until you think you’ve got it down.”

I’m just a novice, how can I judge whether I’ve mastered something sufficiently?

I now try to create tests rather than completely open-ended exercises as often as possible. I wanted objective pass criteria, not fuzzy, subjective self-evaluation.

Applying test driven development

I decided to borrow a technique from software developers called “test driven development” or TDD.

Software developers using TDD write tests first, and only then begin coding the actual implementation.

The TDD process follows a cycle.

  1. First write a test and a “stub” implementation (that compiles but doesn’t actually do anything).

  2. Red Light. Initially, the tests fail (with a “red” message). They know the code doesn’t work yet, so they expect the test to fail.

  3. Green Light. The developer codes the simplest possible implementation that makes the test pass (“green” light). The code is usually pretty ugly and slow at this point.

  4. Refactor. The developer then makes changes to the code (“refactoring”) to make it more readable, maintainable, efficient, and fast. They re-run the tests as they make changes to ensure the code still works. They can be confident their changes haven’t broken the code if the light remains green.

While the field of software development is obviously quite different from playing guitar, there are some ideas from TDD we can apply to practicing guitar.

The most important idea is to explicitly define what makes the light turn green before you start practicing. In other words, document precisely what it takes to know when you’ve practiced enough.

TDG: Proficiency tests

As often as possible, I try to add proficiency tests to my exercise library rather than mere exercises. In other words, I try to pre-define “mastery” for the exercise (knowing full well that the first several attempts with an exercise will cause a “red light”).

A proficiency test expressly defines what constitutes a “green light” for a particular exercise or drill.

How to make the pass criteria objective rather than subjective? Mostly with Mr. Metronome.

Most people think a metronome only has two purposes:

  • It provides a steady pulse during practice to improve your internal sense of timing.
  • It lets you build speed by practicing at higher and higher BPM.

Both are true, but a metronome also excels as an objective, and cruel, task master.

Imagine teaching a child to recite the alphabet. At some point, the kid can probably make it all the way from A to Z successfully, but with lots of “umms” and “errs” dispersed throughout. The kid smiles in relief and thinks she’s done.

With an evil grin, her teacher then say, “Congrats, Kid. You’ve memorized your ABCs, now comes the hard part.”

Teacher then sets a metronome to, say, 80 BPM and says, “Every time this clicks I want you to say the next letter of the alphabet, but you can’t miss a click!”

Suddenly reciting the alphabet got a whole lot harder.

That is how you use the metronome to objectively measure proficiency.

I won’t pretend that every guitar exercise “green light” can be defined with a metronome setting, but it does suffice for a surprising number of exercises.

Last modified May 25, 2020: restructure practice stuff (d2a6324)