Proficiency

I always like to challenge myself. Lately I’ve been challenging myself by running ultramarathons.  As you might imagine this requires a bit of training. These training runs give me plenty of time for reflection. The other day as I was on a training run in the mountains, I kept thinking about a post on Linkedin from Mark Ridgely.  His post was about proficiency.  Mark’s post is great and he makes some very good points. I had a lot of time to think about it, so I thought I would write this up to try to add to the discussion Mark started.

What does proficiency look like in action?

In reading Marks post, I thought “Well that is a great textbook definition, but what does proficiency look like in action?”  I happened to be running at the time, so of course, my thoughts revolved around running. I kept asking myself “What does it mean to be proficient at ultrarunning?  What does that look like?  Does that carry over into Software Engineering”  The phrase that kept popping into my head is one that I learned a long time ago.  I first heard this phrase with respect to mountaineering, but it seems applicable to a lot of different areas.

Strive to thrive, not just survive.

Being proficient equates to thriving. It means you are in your element. It means you are calm, cool, and collected. You are making good decisions. Your movements are calculated. You anticipate potential problems and react appropriately. You are in that “flow” state. Surviving means doing whatever it takes to get by. It means wasting large amounts of energy on inefficient and frantic movements. A small speed bump sends you careening off in a different direction. An easily foreseeable problem stops you dead in your tracks.

In a 100 mile race the best way to see the difference between those who are thriving and those who are merely surviving is to observe the runners as they enter an aid station around mile 80 or so. Everyone looks a little worn, but if you carefully observe the runners’ enthusiasm you will notice they fall into 2 distinct groups.  Those who are thriving are cracking jokes and smiling and have a little spring in their step. Those who are surviving look dejected. You can easily see it on their faces. Their energy levels are much lower.

In the quote above it is easy to simply focus on the 2 words thrive and survive, but there is another important word in that sentence: strive. That’s because we all exist on a spectrum between thriving and surviving.  Sometimes we feel like we are thriving and in our element and sometimes we don’t. The key is that we keep working to increase our comfort level and our proficiency.  If you feel you are in that thrive mode all the time, you are probably not living up to your full potential.

How does this apply to software development?

Proficiency in software development and that feeling of thriving are correlated.  If thriving is being excited about where you are and what you are doing and being in the zone, it is almost impossible to thrive doing something you are not good at.  If you are bad at writing LabVIEW code, you will probably know it.  Things won’t work.  You will run into a ton of bugs.  Finding the cause of and then fixing those bugs will be a pain.  Writing LabVIEW code simply won’t be that much fun if you are not proficient at it.  If you lead a LabVIEW team I think you’ll find that there is a correlation between someone’s proficiency and their attitude (ie. whether they seem like they actually enjoy writing LabVIEW code).  Maybe I’m unique but I just happen to find that it is always more fun to do things “the right way”.

Striving is also very important in being proficient at LabVIEW. Per the definition in Mark’s post, proficiency is “measured against established or popular standards.”  Over time those standards only go up. If you consider yourself proficient today but don’t strive to improve you will not be able to keep up. In perhaps as little as 2 or 3 years you will no longer be proficient.  As an example, when I started doing LabVIEW, few people used source code control.  Within a couple years it became ubiquitous. Today it would be hard to argue you are proficient in LabVIEW if you are not well-versed in SCC.

What can we take away from all this?  First, LabVIEW programming should be fun.  If it’s not you are probably doing something wrong.  Second, staying proficient requires work. We’ve got to constantly keep educating ourselves just in order to keep up.