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.