Eric Burke’s recent weblog Simplicity and “Getting It” is so right in many ways. He makes great points about the training of programmers and refers to one of the books on my “must read more than once list”, Andy Hunt and Dave Thomas’ The Pragmatic Programmer. For related interviews by Andy and Dave, check out Bill Venners’ ten part series at artima.com. One of the most important points Eric makes is this.
What troubles me is the observation that we have legions of programmers who don’t seem to “get it” when it comes to writing maintainable code. They are happy to produce reams of code that seems to solve the immediate problem at hand, and are perfectly content to move on to the next problem, leaving all of this horrible code behind.
Compare that with Bob Cringely’s article Refactoring, refactoring.. Cringely doesn’t worry about maintainable code. He only cares about working code. He writes:
The key problem, as I wrote last week, is that refactoring means monkeying with working code. If the program isn?t working, you don?t refactor it. Refactoring is supposed to be IMPROVING code, not fixing it. By definition, you only refactor code that is already working, which where I come from is scary. Working code is a valuable asset since it is hard to get right (at least for me) and takes time. Touching working code is always a risk and so there should be a darned good reason for doing it. Adding features, worthwhile refactoring, or bug fixing are all possible good reasons. Tinkering with code or cleaning it up is not.
Ken Auer brought a group together a year ago to talk about software apprenticeship. If creating software is a craft, then we need to find better ways to get meaningful interaction between experienced practicioners (masters) and those entering the field (apprentices). If I could spend a year pairing with ((fill in the name of a software professional you really respect)) would you value that as much as an academic degree? What is a BS, MS, or PhD meant to convey?
Can we be certain that the people teaching at the college level are qualified to train new programmers? I argued at the summit that there was value in academic training. Others argued that too often those teaching programming had never developed or maintained code. They’d never written code for a client and weren’t experimenting with new languages. Check out chromatic’s article on Programming Annoyances. He continues to learn new languages so he can apply the best tool to the job at hand.
I’ve ended many of my talks to professionals these past couple of years with a challenge for audience members to adopt local colleges and universities. The professors can’t keep up — spend some time giving a talk or two on some new technique or technology you are using. Then this year a university position came open nearby. I encouraged a couple of friends to apply for the position. I even applied for the position. There are many reasons not to hire me — but the reason I and my friends were not considered was that we didn’t have a PhD in CS. The job listing explicitly said that that was ok. I think there are many with a PhD in CS who would be fabulous teachers but I think you unwisely limit so many talented people from the pool when you draw this line.
I read a posting like Eric’s and think, “boy, I could learn a lot from him.” I spend time with Uncle Bob Martin and think, “he is one of the best teachers I’ve ever had.” I go to lectures by James Duncan Davidson, Jason Hunter, and countless others and come away so much richer. This little school would only consider hiring them if they had a PhD in CS. Not being able to learn from this rich pool of talented people, in my opinion, is hurting the next generation of programmers.
Who should train programmers and how?