The Middling Guitarist Arrives

When last we left our intrepid wanderer (i.e. me), he had abandoned his dream of playing guitar due to the crushing anxiety of meta-expectations that no one explicitly states, but are somehow woven into the mythos that pervades the modern guitar canon.

I'd like to tell you that upon returning to the instrument, I only stepped away briefly, realized what I wanted from my reintroduction to the instrument, and came back full of enthusiasm to pursue my artistic aims.

In truth, I stepped away for a long time.  It's one of the few things I can say I truly regret.  And, though, I had a better idea of what I wanted to do, conventional wisdom still screwed with my head and kept me chained to stereotypes even though I had two supportive guitar teachers and was a fully formed adult who now had a decades-long history of learning to say "no" to ideas simply because they were established norms.

Observation 4

Time always provides perspective. Granted, it isn't always a healthy perspective if you simply ruminate on the same past events with no new perspective, but as The Cowboy Junkies say "distance always loses the knife," so you'll get some value even if you're locked in the past crying over you high school glory days. 

In the case of my career, simply being present over the years added understanding even if the change seemed to be so small I couldn't measure it until well after the fact. I don't know how many rounds of "I'm the best programmer here" to "I know nothing compared to everyone around me" went through my head over the course of a decade before finally reaching a point where I was comfortable with my strengths and weaknesses.

But, over that same manic span, I learned about how important operational concerns were in addition to writing "good" code and then about the difficulty and beauty of scalability and distributed systems. I did this all simply by moving forward, even when I had no planned destination. Learning about these particular concepts taught me that there is no perfect solution - even in a mathematically based field like computer science. You should strive for the best possible solution right now, rather than scratch away at the perfect one that may never arrive.

When I picked up the guitar for the second time, I made the conscious decision to give myself a break on practice time parameters.  I was an adult with a full-time career and was no longer weighed down with the burdens of daydreaming about making a living as a guitarist (unless someone out there is a record executive and wants to offer me a no-strings-attached contract).

With that, I set a goal of practicing 15 minutes a day.  If I could do more, great.  If not, I could reach the reasonable goal I set for myself (if you're wondering how long it would take me to be an expert at this rate based on the 10,000-hour rule, it's between 109 and 110 years, so I knew I wasn't going to be expert material).  

It turns out, in my case, that even 15 minutes wasn't always reasonable.  Unlike other goals I set for myself - 15 minutes of language learning or 15 minutes of reading - guitar practice isn't as flexible.  I use Duolingo for languages, so my lessons are already mapped out for me and reading is linear - you just pick up where you left off and go.  Since I use my phone to perform both tasks, they're portable.

Guitar requires me to have an instrument available and a sketched-out lesson plan.  I could just practice scale positions or basic chord progressions to fulfill my practice requirements without a plan, but that'd quickly grow tedious and I'd be back to making up excuses for not practicing, even measured against a short and sweet 15 minutes.

I've since settled on setting a 5-minute practice target with an aim to reach 15 minutes or more.  On days that I don't practice, I give myself permission to leave the guilt trip aside.  I'm not a pro.  No one is depending on me.  With regularity, I practice about 13 out of every 14 days and accumulate 4-5 hours worth of practice across that span.  The 5-minute window allows me to practice rote exercises without getting bored on the days when I can't compose something more substantive to work on.

Observation 5

In recent years, there's been a lot of discussion  - especially in the software world - about achieving a flow state in a work setting.  Flow is essentially a state of consciousness where you become effortlessly productive and time appears to melt away.  I think it's something we've all experienced, but it's very difficult to enter on demand for the average person (say someone like...me).

I agree with the advice that, especially for individual contributors, managers should carve out uninterrupted time to give their employees room to reach for that state, but the reality of the situation is that it's hard to achieve.  Phones buzz, dogs bark, command hooks fail, pictures drop to the floor, and voilà, your flow state is instantly ruined through no fault of anyones except 3M's engineering department.  

Everyone has different methods to combat distraction, but the least useful is to concentrate all of your efforts to enter a flow state.  I'd prefer to have four 5-minute sessions and 40 minutes of distractions per hour rather than 1 pure flow state of 2 hours.  Over the course of a nominal 8-hour day, that's nearly 3 hours of output vs. the 2 hours the flow state produced.  I'm also not burdened by the anxiety that I couldn't successfully sustain a flow state, so my mental health will be better for it.  It's possible that the flow state output is more robust, but there's no guarantee that's true.  Your entire state may have directed you down the wrong channel.

It wasn't until I revisited the most basic question involving guitar, though, that any anxiety about being an archetypically good guitarist finally faded away. And that question was - What is the main purpose of a guitar? For me, the answer was simply "to make music."

It was a question that I'd never considered in depth because the answer was obvious. But, because the answer was obvious, it was left unexplored and all the layers of abstraction on top of it took on more meaning than they should have.  They pointed near an answer but never directly at it, and each layer slightly skewed the response from the previous layer.

Again, for me, to make music is to write my own songs and translate, to the best of my ability, what's in my head to the physical world. For others, it may be to play their favorite songs at parties for friends, or to find new methods of experimentation on demand. But they're all facets of that same simple answer - "to make music."

Understanding this made practicing more constructive. Now, when I practice, I spend time on things I'm writing - making adjustments and doing research to better a composition already underway.

When I spend 20 minutes practicing the same riff over and over again, it's to teach my hands to match what's in my head. And, if ultimately, I can't reach that goal but can find a reasonable workaround, I don't stress that "it doesn't sound like the real thing" because the real thing is what I determine it is.  Once I become a better guitarist, I can always go back to the more difficult concept and add it elsewhere.

Landing on this epiphany also helped my guitar lessons. I now spend time discussing sections of songs I wrote to improve them and my general musicianship. And, because, I'm now focusing on whole compositions, I have to learn the basics of other instrumental parts. As a result, I've exponentially increased my knowledge of vocal, bass, and drum parts. 

And all of this happened simply because I shed the cumulative layers of expectation to go back to the initial question - what is the main purpose of the guitar?

Observation 6

Though businesses pride themselves on efficiency, they're subject to the same goal drift. I'd argue even more so, since every time you add a new person to a project or team, you're adding a new set of expectations and viewpoints.  At thousands of people that can be downright chaotic.

On balance, new viewpoints are a benefit, but always require additional effort to ensure that everyone has a reasonably agreeable view of the current goal (because, no matter how hard we try, any two human's views will diverge, so there will never be a perfect consensus). 

So ask yourself before the chaos engulfs you - what is the original purpose of the project? Are we adding more layers than necessary? How much can we cut away and still satisfy the expected outcome? Do we need a new tool or a new framework to achieve the outcome?

For managers, ask yourself - how much control do I really need? What level of status will satisfy my reporting requirements, so my engineers can do their work without getting bogged down by meetings? Does it matter if the date slips a day or a week, or do I care about the date only to satisfy my own ego or impress someone with my delivery schedule? Are my employees engaged with their work? If not, what more can I do to increase interest in the project ( or, conversely, how can I ensure they're not on a tedious but necessary task for longer than is reasonable)?

The basics are always obvious, but sometimes the obvious isn't so obvious, so it's always worth voicing the simple questions.  You might be surprised how much it changes your original expectations.

Until next time my human and robot friends.