There's nothing like a new millenium to get me thinking on topics such as aging and the passage of time. Lately I've been pondering the question of what makes a programmer more mature, not just older and crankier. I have been writing programs for 20 years, but that hardly makes me an expert programmer. I'm not so sure about the mature part, either, because even now I am learning better ways to do things. I am not talking about learning new languages, APIs, techniques, etc. — this is par for the course for any programmer. I mean that I am still working on my "personal software process," to use one popular phrase.
When I took programming courses in college, the lingua franca of the CS department was Pascal. Then some friends introduced me to a fun little language called "b." b was a systems programming language, a predecessor to C with much of the same syntax. I loved b for reasons both good and bad. A good reason was simply that b didn't get in the way. By comparison, programming in Pascal was like hacking through a jungle. A bad reason for my love of b, I am embarrassed to say, was its practically non-existent type checking. It would let you do anything, and I thought that was cool. But I was younger then, and had yet to discover my talent for writing self-astonishing code. It was only after hanging myself many times (and languages like b provided rope in ample quantities) that I came to appreciate strongly typed languages. Perhaps my story suggests an indication that we're getting more mature as programmers: we feel grateful for the dumb things a language won't let us do.
One thing that hasn't changed for me over 20 years is the need to test my own code. It might seem that as a programmer becomes more experienced, he worries about testing less and less. I think almost the opposite is true. Not that programmers get worse with age; rather, we can never test to 100% confidence, and as we mature this painful truth bothers us all the more.
One big obstacle to testing thwarts experienced and new programmers alike: the sheer tedium of writing test code. Fortunately there are ways to reduce the tedium that don't involve psychoactive substances or palming the job off on someone else. There are testing tools, for instance, that let you specify test cases (input values and expected outputs) in scripts instead of hard-coding them in a program. Not having to recompile when you add a test case can increase your productivity tenfold.
Of course, you have to invest effort up front to get such tools set up and working. As compensation you face less drudgery on the back end. So maybe another sign of maturity is an active opposition to tedium. If testing is a drag, the mature programmer will not whine about it, but will either find or build the tools to make it less so. And those tools are not luxuries — tedium is dangerous! It makes us want to skimp on testing.
Finally, one last sign that you're flirting with maturity, a faux-paradox for the new millenium: you know you have almost arrived when you realize that you never will. If you think you can't get any better, then get thee to a mortuary, because basically, dude, you are dead. For my part, in 1,000 more years I hope to figure out how to use pointers safely, and how to read those gnarly template error messages. Then maybe I'll say I have arrived. In the meantime, I guess I will just keep on learning.
Marc Briand
Editor-in-Chief