By Jess Males
As technologists, half the technology we need to know for our jobs is getting invented or reinvented on a daily basis. You already know this: look at the rapid onset of Docker; look to the continual improvement of languages like Java and Go; look to the features and services that public clouds introduce daily. Mastering new technology is a constant challenge for us; how do we meet it?
I recently had the pleasure of talking to a group of fellow consultants at a Taos Practice Dinner. There I mused on the stages of technical skill development: usage, construction, expert.
What do I mean by these? For ‘Usage,’ I mean the familiarity with the software to operate it at a basic level (i.e. how to start it, stop it, where it logs, being able to describe what it is meant to do, and some level of why). For ‘Construction,’ I indicate a level of comfort with the software that one can describe its essential components, how those components interact and a solid working knowledge of the features of the software. Finally, for ‘expert,’ I denote a level of skill where the user can describe deep and subtle behaviors of the software; they can operate the software under significant load, as they are very comfortable with its performance demands.
When we encounter a master at work, we gain a sense of their skill simply by watching them in action. Putting that into words is hard. Maybe you have disagreements with these levels and descriptions; that’s fine. With these descriptions, I’ve tried to focus on verifiable, repeatable or quantifiable characterizations. What I want, ultimately, from these characterizations is a measure for our own skill ratings.
The nice thing about presenting this theory in a public forum is that the idea was immediately turned around, and the audience shared their many techniques for building new skills. In no particular order, these were some of the ideas shared:
- Even while learning new software, focus on being able to automate it
- Research alternative implementations
- Survey blog posts/conference presentations for overviews and specific pointers
- Install the software into a test environment; play with it there.
- Engage the source: read the source code; review the release notes; review outstanding bugs
I appreciate all of these, and all are exercises for any level of skill. Doing so follows the adage of ‘practice makes perfect.’ However, Vince Lombardi took umbrage of this adage, insisting, “practice doesn’t make perfect; perfect practice makes perfect.” This implies there must be consistency and deliberateness to the practice for it to be effective. Simply, playing with software isn’t enough; experiencing it under real-world conditions is important. This is a challenge. If we’re hoping to improve our skills to the described level of ‘expert’, we’ll have to do so while working in a realistically simulated environment. And, creating a simulation environment for software that adequately mimics scale or load is a distinct challenge by itself. This is an area where our community could build much better tools.
Finally, why talk about any of this stuff? Because having a theory of development allows us to build skills more effectively. Knowing the range of exercises available allows for more targeted improvement. Here I’ve presented my working theory of skill development, hopefully, it echoes with your own experience, but maybe not. If that’s the case, please share. The discussion around skill-building is important to us all, and in the discussion, we can all learn better methods for learning.