Let's take a look into the future—all the way to the year 2013! As a software tester or software quality engineer, are you planning to learn a new skill in the new year. If you are, make sure you approach it in a way that will make that skill stick.
A title like “New Skills for 2013” creates some expectations in my mind, and I am sad to say that they are not particularly good. In a publication like this one, one might expect a statement like “technical skills are increasingly important for software quality and software testing professionals,” followed by a list of buzzwords and, just maybe, some comment about soft skills at the end.
Given how many books I have in my office about "learning the technology of the day in twenty-four hours" and the amount of dust accumulating on those books, I am reluctant to write yet another article like that. Instead, I'd like to talk about the three things it takes to make a skill stick and to improve your chances of moving from "bought the book" to "actually competent" in a new skill, whether it is a technical or soft skill.
When I think of my ideal learning project, I look for the intersection of three things. First, my skill set should be near the problem, but not an exact fit. Second, I want meaningful work to do. And, third, I need someone to call for help when I get stuck.
A Skill Set Near The Problem
Over a decade ago, I was working on a large program written in C, mostly expressed in one file. We make jokes about bad code (and it was), but the program ran every month and created real revenue for our company.
One of my colleagues, Jeff Klein, was a wizard with the code. He could quickly find things that no one else could. Jeff didn’t have the program memorized. He had a power-editing tool. It made the screen fly by. One day, I asked Jeff what he was using and he said Vim, which comes standard on most versions of UNIX.
In college, I had to use Vim’s earlier incarnation, vi, on some systems. It was more than a little intimidating, but other programmers had learned it, so I sat down with the Vim Book for a few hours. After that, I used Vim over and over again for a few months. It took time, but I eventually became a Vim wizard, too.
Meaningful Work To Do
If my study of Vim was for research purposes, then I might have finished, stuck it in a drawer, and quickly forgot about it. But my need was more than that. I had a monster program to search through, with tens of thousands of lines of code in one source file. Editing with vim provided me with easy search, copy, and replace, which made me more effective. The meaningful work reinforced and accelerated my learning.
Without the meaningful work, I'm left with simple proofs of concept with no real skill— for example, my recent study of Apache Hadoop. Hadoop is a data-crunching framework. It allows programmers to take massive, unstructured data sets, split them over a thousand servers, and perform searches. You might use Hadoop to construct a query into, say, viewing what pages lead to sales at Amazon.com, giving all the of the log files as input.
I’ve been “looking into Hadoop” for about six months now with no progress. There are two reasons why. First, I need to spool up the servers and deploy the code, which I don’t have great expertise at. The problem is two steps away from my skill set, so I am unlikely to get to it. Second, I don’t have an interesting problem to solve with it. If I spent a few thousand dollars on a nice server and some network-attached storage, all I would get are some nice twinkling lights.
If you want a technical skill to stick, then give yourself some meaningful work. Don’t just study mind maps. Use them to plan or document your work.
One quick way to find meaningful work is to solve a problem, like parsing a log file, automating a task, or just understanding the code the programmers are writing.
A Friend to Learn With
In order to run Hadoop, I need a cluster of servers to run it on. Believe it or not, the folks at NASA and RackSpace have created a free, open-source, private, cloud-computing framework called OpenStack. You can run OpenStack on a single server or, for more demanding tasks, use the server as a controller and point it to dozens or hundreds of systems, automate the process by which systems are created, and, bang, you have the cloud in a box.
I’ve been “looking into OpenStack” for about six months, too.
I haven’t made much progress for a few reasons, but one key reason is that I get stuck and don’t really have anyone to ask for help. So, I put the system on the shelf for a week or a two and then come back to it when I have some energy (and a lot of disk space).
Learning with others doesn’t have to involve a community or even a mentor. It might be one person trying to figure this out with you—someone that you can bang your head against the wall with.
Your 2013
Notice that I had all three of these things when I learned Vim. Jeff was helpful, my typing skills were far enough along that I did not need to hunt and peck, and the code provided plenty of opportunities for practice.
Now, look around at the skills gap in your area. Search for the skills that people will pay money for and that anyone can learn, but that few people are actually going out and learning. One place to look for these is job listings—i.e., the skills that lots of people are hiring for, but nobody has. Also, consider what type of job you would get if you had to find one totally outside of software. What skills from those jobs might also be relevant to the job you have now?
Once you've identified the skills you want to learn, all you need is aptitude, an interesting problem, and a friend to call.
What skills would you like to develop in 2013, and how are you planning to get there? If you'd like to learn Hadoop or Jenkins on OpenStack, let me know. I need to find someone to collaborate with.
