Alight from an underground train in London’s Bank station and you’ll hear a deeply concerned recording advising you to “mind the gap.” That simple recording must have saved thousands of hapless commuters from flinging themselves mindlessly into the 6-inch space between the train and the platform.

Perhaps the recording would be better employed in our software development bullpens, because there’s a gap there that is wider and has caused far more stumbles. It’s the gap between skills and experience.

Developers and managers in the field are desperately trying to keep their skills current. They’re lapping up the low-level trade books-how to write programs in language XYZ, how to configure a Web server, how to install Linux, whatever. At the other end of the spectrum, they’re working in environments where they have to learn their organization’s methodologies, whether Rational Unified Process, Capability Maturity Model, Extreme Programming or something home-grown.

But the industry is still frustrated. With all these skills, project teams continue to make the same old mistakes-mistakes in design, mistakes in implementation and mistakes in deployment.

WHY?

The teams are gaining experience, and they’re gaining it the only way they can-by making mistakes. There’s a wide gulf between skills and experience. Would you want to be flown by a pilot who has read all the books he can find on flying but hasn’t actually sat in a plane until today?

Developers can know all the ins and outs of the language they’re using. They can have walls papered with Microsoft or Sun certificates. They can fill in the forms and follow the practices of their methodology. But that’s not programming. And programming is what developers spend most of their day doing.

Programming is normally regarded as a personal skill, something that’s honed on the grindstone of practice. Sit in your cubicle and hit those keys, and you’ll gradually get better and better.

Is there any alternative? Is there a way to fill the gap between technical proficiency and professionalism? Yes. You and your team can accelerate the learning process. Here are proven factors that help teams cross the experience gap more quickly and with fewer stumbles.

Know what you don’t know. You can gather experience by picking up bits and pieces as it drifts by, or you can actively seek it out and grab it with both hands. This is particularly important when starting new projects. We’ve seen clients throw dozens of inexperienced staff at some new technology hoping they’ll catch on. It just doesn’t work.

Diversify. If you treat your knowledge and skills as an asset, then diversification is just good sense. By all means have particular areas of focus, but without a broad base, there’s less framework on which to hang new experiences.

Become your user. The majority of real experience is not in the technical details; it’s the interactions between things that hold the information. So find ways of getting close to your users, really close. If possible, work alongside them every now and then. If not, invite them into your world. Learning from each other during a development is better than screaming at each other afterward.

Stir the mix. A typical team has a broad spectrum of skills and experiences, yet developers typically work shut away in their cubicles most of the day. Break down the barriers to communication.

Encourage prototyping. Prototyping is learning. Developing a prototype, throwing it away, then developing the real thing normally take less effort than developing the final application, throwing it away and developing it again properly. Look for tools and techniques that facilitate the process. (A message to project sponsors and managers out there: If you take a prototype away from a team and try to deploy it, they’ll never prototype again. That’ll end up costing you a lot.)

Don’t blame; don’t make excuses. Have an official no-blame policy, so mistakes can be shared and learned from. Learn from professional aviation. In the early ‘70s, pilots were reluctant to report problems for fear of enforcement actions-their livelihood was at stake. Following a sequence of accidents, NASA agreed to start accepting reports of problems, and the Federal Aviation Administration agreed not to use them to assess blame. The program now receives over 30,000 reports every year, making flying safer for everyone.

Act on feedback. Feedback is how we learn. Find out how to give feedback and learn how to take it. Feedback doesn’t come just from your colleagues and your users. Listen to your software and processes as well. That piece of code that steadfastly refuses to work? Maybe it’s trying to tell you it wants to be refactored. That change request form that no one bothers to fill in? Maybe it’s just not a good form.

Buy time. You don’t learn from doing unnecessary things, no matter how well you do them. Practice techniques of salvaging time. For example, automate everything you can. Not only do you buy time, your work becomes repeatable. Do you really need acres of class diagrams before you start to code? And fix things now. It will take longer later.

Judge yourself. The old saw is “Experience is not what you’ve done, but what you’ve learned from what you’ve done.” Constantly review your performance against your objectives, and adjust accordingly.

And don’t forget to make all this effort worthwhile. Capitalize on your experience and learn to trust your judgment. Actively plan the acquisition of experience, and you’ll find your projects go faster with fewer mistakes. You’ll probably enjoy them more, too.


Dave Thomas and Andy Hunt are the authors of The Pragmatic Programmer, Addison Wesley. They can be reached at dave@pragprog.com and andy@pragprog.com.