While at lunch with colleagues recently I overheard four very able Java developers swapping horror stories of the kit they'd cut their teeth on as junior programmers. One had used a Sinclair ZX-81 with 1K of RAM and a black and white TV and a tape recorder in lieu of a hard drive. Things were so bad with the memory that the screen buffer was used to store program data. That story was trumped by tales of a Commodore 64 where after it was discovered that the built-in hard drive had its own processor, it was used to offload program work to create true symmetric multiprocessing on a box that was never designed for this.

Both stories came from wizened old developers convinced they'd won the mantle of "hardship programming in my youth." Ironically the college kid in the group played the five-ace hand with tales of taking a games console and stripping it down to a Unix box and then running it as his home server. Apart from feeling I was observing a 21st century version of Monty Python's "Four Yorkshiremen" sketch (www.phespirit.info/montypython/four_yorkshiremen.htm), I felt slightly worried by the allegories being drawn and implied by the dialog.

Without necessarily intending it, two messages were being conveyed. One was that you had to have struggled with basic tools and underpowered hardware to get a job done as a necessary rite of passage on the path to becoming a true programmer, and the second was the syllogism that if you continue to use sticks and stones to program you are somehow a superior programmer than someone who doesn't.

I encounter quite a lot of the latter attitude in my day job where I develop tools whose purpose is to help people write Java GUIs. When talking to users, some of them enjoy the obvious benefits of being able to preview their screen as they write it and handle components by selecting and manipulating them in WYSIWYG touchy-feely viewers. Others will rightly point out that the complexity of their GUI is beyond what the builder can cope with and that's a good reason not use it. Others seem almost threatened by what is basically a fairly entrenched idea of a tool creating code for you and they'll come up with every excuse possible why they shouldn't use it. Arguments vary from the code not conforming to their particular style, which, apart from often degenerating into an academic argument about how fields should be named or methods structured, also shows a certain intransigence against being able to adapt to a new style. It exhibits a belligerent and generally frowned upon trait in programmers to be inflexible when dealing with code authored by others without feeling the compunction to rewrite it.

The favored vestige of the non-IDE folks is often to drop down to a text editor such as vi or Emacs and gain some kind of Luddite satisfaction from editing raw files and firing off build scripts. I used to admire people who enjoyed coding with such tools similar to the way you might enjoy listening to classical music played on period instruments. After a while, however, it just starts to sound flat and hollow and in denial of all that has been learned since. The problem is being able to recognize the genuine aficionado of someone who is using his favorite antique editing experience because it genuinely makes him productive and able to focus on his job without helpful wizards and code assist, versus the one who is trying to copy the master and thereby fake credibility that masquerades his inability to focus on his job.

At a recent presentation I was giving on an IDE feature that makes it easier to write code, I had to deal with a heckler who told me how superior vi was and how we couldn't deal with his particular key bindings. The irony was that he wasn't from the wizened penguin bumper-sticker brigade who are the stereotypes of such attitudes - he was a fresh-faced, recent college grad and had brought his bellicose attitude almost as a badge of honor to parade.

Let's take cars, for example - my attitude is that when they break I take them to the mechanic; what's fun isn't so much tinkering with the engine myself and gaining some kind of machismo pride in doing so, it's the journeys I take in it and what I do when I arrive. Likewise with writing software - the purpose is to create a good user experience for someone else who wants to solve a particular problem in a more efficient way. I once had to explain to a customer why we were late shipping a particular software release and he replied that we were just polishing the inside of a tin can and he didn't care. He was right - we were upgrading operating system releases and migrating to a new language version mid-release cycle. However, there was no business value to it and we'd just taken our eye off the target and onto our navels.

Is the problem with software and tooling one of a master craftsman with his favorite chisel and simply that people are reluctant to change something that makes them most productive, or is it just that people have a built-in desire to belong to a herd and gain social acceptance from their tribal peers from where they can collectively mock progress and other languages and technology changes as being for the folks on the other team? Is the super-league of programmers occupied by folks who take apart game boxes and have wireless networks in their kitchen, or is it by those who would rather play some fun games on the box it was designed for and then enjoy a nice meal in the kitchen afterward?