Save the Hobbyist Programmer
by Kathleen Dollard
Posted February 24, 2004
Miners know they have a significant problem when the canary they keep with them stops singing. Hobbyist/part-time programmers are our industry's version of the canary, and they have stopped singing. People who program four to eight hours a week are being cut out of the picture because they can't increase their skills as fast as technology changes. That's a danger signal for the rest of us. We need to address the problems faced by these programmers before we lose their important domain expertise. But we also need to look at the increasing training demands, because it's becoming difficult for any of us to remain competent with technology.
Increasing complexity threatens the pattern of hobby or part-time programmers becoming full-time. .NET is harder than past hobbyist languages such as Pascal or Visual Basic. You need to manage a development environment that might include IIS and SQL Server, and you have to worry about diverse issues such as security and deployment. On top of that, you've got to figure out which long-term strategies, like Longhorn, matter.
Microsoft is attempting to address the complexity of Visual Basic in the Whidbey release, but that alone won't be enough to save the hobbyist programmer. Saving this programmer is important because he understands the domain, sees the application as a pragmatic solution, and asks, "Is this worth doing?" Of course, we need more than just hobbyists. A different set of skills comes from the programmer who grew up with computers and had keyboarding neatly sandwiched between handwriting legibility and library skills on her elementary report cards.
Both of these groups come into our industry with a lot still to learn. The idea of programming apprenticeships surfaces periodically, but it's the wrong model and won't work here. Programming isn't something you can learn at the feet of a master, and in this case, the master also needs training. New technologies such as Longhorn underscore that every single one of us needs an increasingly high level of ongoing training. Even gurus like Don Box and managers like Jim Allchin need a commitment to training as a focused, self-driven process that deserves time. With the current rate of technology change, it takes at least eight hours a week of focused training (in addition to "sampling" training such as reading magazines, newsgroups, or blogs) to keep up.
Providing that level of training is an astounding proposition. It might sound expensive, but think of how much more expensive it will be if Don Box, Jim Allchin, your boss, or the person in the next cubicle (or you) is muddling around making mistakes because of half-understood ideas. Today's training scenario is expensive and takes commitment, but what about tomorrow? The amount of time required for training has increased steadily in the 20 years I've been in this industry. If this pattern continues, you and I will soon be like today's hobbyistour training needs will surpass the time we can devote to them.
Increasing training demands is the single biggest problem facing our industry. Technology advances drive the demands, but it's both unwise and impossible to slow the rate of change. Saving the canary might save all of us. Addressing the needs of the hobbyist programmer in older versions of VB laid the groundwork for wrapping the complexity of Windows. Addressing the problems the hobbyist faces today might lay the groundwork for handling the phenomenal complexity the next decade will bring.
It's not a language issue for the VB team. We've milked the ideas behind VB, and it's time for radical new ideas. Solutions might lie in technical advances regarding language fundamentals, code generation, and IDE design. Or they might be pedagogical, based in math education research in understanding how humans learn abstract concepts. Microsoft needs a dedicated teamsome of their best people with broad skill sets, hooks into every existing technology, and free reign to follow the most promising strategies regardless of their fit with marketing. Without new techniques, the rate of technological change will stagnate because we simply can't keep up and still handle our day jobs. The time required for training will gradually strangle our ability to produce the programs our users want.
About the Author
Kathleen Dollard is the author of Code Generation in Microsoft .NET and numerous articles on a range of .NET technologies. She is a long-time Microsoft MVP, serves as president of the Northern Colorado .NET SIG, and is an active member of the Denver Visual Studio User Group. Reach her at email@example.com.
Back to top