Teach Your Programmers Well

By Allen Holub

January 15, 2005 —

Regardless of what people say about how they develop software, the best way to find real priorities is to look at the departmental budget. Things get particularly interesting when the perceived needs of the managers are not reflected in those budgets.

Enterprise Systems just published an interesting budget survey based on the voluntary replies of 250 subscribers, half of which are senior management. (You can see this survey at www.esj.com/surveys/itbudget2004.aspx.)

In that study, the disconnect between needs and spending struck me forcibly in two areas: training and staffing. The top four areas where the managers were planning to reduce spending were desktop software, desktop hardware, staff head count and training.

Cutting out unnecessary hardware and software purchases doesn’t seem like a bad idea, but cutting head count and training is a problem, especially when you compare these cuts with the top three items in the “What new IT initiatives are on your IT wish list?” category: staff salaries, staff training and staff head count. The No. 1 item in the “What one skill does your IT department need to develop most?” category is “technical proficiency.”

To quote astronaut James Lovell: “Houston, we have a problem.”

I strongly believe that you can’t produce even moderately acceptable software without excellent programmers. I also believe that it takes longer to develop mediocre programs than it does to produce good ones, and mediocrity is the best you’ll get out of an untrained staff.

Though excellence is important, it’s not innate. You achieve excellence by superb training and constant practice. By superb training, I mean classes taught in the flesh by experts in the field, not online courseware churned out by some education mill. The online stuff is no better than reading a book—it’s not useless, but you get what you pay for.

Unfortunately, our university system falls down on the superb-training front. A degree is, more and more, a job requirement, but most experienced programmers consider someone fresh out of school to be useless when it comes to doing real work. Programmers don’t become productive until they’ve worked on nontrivial projects for at least a few years, but even those years don’t guarantee an excellent programmer. Since our universities aren’t doing the job, you’d expect employers to make up the difference by training their workforce. Most companies don’t do that, so the programmers who work for those companies never get better—they just get older.

I blame this problem primarily on a too-strong emphasis on training for specific technologies—how to write an EJB, for example. This tunnel vision produces people who know a specific technique but not how to program in general. These people are ill-equipped to make technical decisions outside of their narrow practice area, but in most shops, they are called upon to do exactly that. An EJB specialist should simply not be allowed to make decisions about UI or database architecture, for example. It’s as if you relied on your dermatologist to do heart surgery.

Moreover, a too-narrow focus guarantees bad long-term decision-making. Technology changes. Whatever effort you’ve spent learning the technology of the week is money down the drain once that technology becomes obsolete. By focusing on specific technologies, you eliminate from your workforce all people who are good enough to see that a particular technology is inappropriate for a particular application. For that, you need a generalist.

So, it’s not just the lack of training that’s a problem; it’s also the narrow focus of what little training is provided. Knowing how to design, for example, is an essential programming skill, but design training seems to be one of the first things to go when the budget ax comes down.

Perhaps it’s the mistaken belief that a single brilliant architect can handle all the design issues and the drone programmers don’t need to know why certain decisions were made. Design is an ongoing activity that happens every time you write a line of code, however. If you don’t know design, you can’t write good code.

Many companies seem to believe that you can hire excellent programmers, but the hiring practices of those same companies, by focusing on specific technologies, almost guarantee the opposite result. In any event, staff head count was being axed, too.

Your best bet is to educate your existing staff, not replace them. Sure, good training is expensive, but the cost in lost productivity is more expensive. You can’t afford not to do it. z

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

Share this link: http://www.sdtimes.com/link/28367

Teach Your Children Well Is there anything less useful than a newly minted college graduate? Whether in programming, electrical engineering or journalism, book learning...

Will tutor programmers for food A startup is offering on-demand training for programmers at minimum-wage prices, all inspired by a Fall-Conroy sculpture

Not your daddy's database With cloud computing, new problems in database optimization have sprung up, and new technologies are coming to address them

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST