Every year or so, it seems to me, academic publications in our industry indulge in a bit of mental torpor by running an article on the question of whether computer science is a real science. Not to be outdone, the practitioners of software engineering enter into their own learned debate of whether their practice constitutes real engineering. In both cases, the end result is generally no consensus save for agreement that if there were legitimate credentialing of professionals as there are with real (there's the word!) scientists and engineers we'd all be better off. Fortunately, the debates never make it far out of the journals in which they inevitably burble up.
Fortunately, like most Dr. Dobb's readers, I work in a field in which the rigor of an individual's work becomes clear enough fairly quickly. There is no need for definitions of the field of endeavor so as to enforce standards or impose criteria. The available certifications connote little more than minimal classroom knowledge. More accurately, there is a slight prejudice against candidates with many certifications. The more you have, the more suspect you become. They are like reverse merit badges.
This aspect is one of the things I most like about programming. The only way to assess individuals' skills is to see their code and to talk about programming in the abstract. Very quickly, you can detect the ease and the exactitude with which they navigate topics. Doing this is something I do through a narrow keyhole in my work as editor.
In so doing, a feeling of humility is often evoked in me. Programming, as Knuth wisely pronounced, is an art. And reading through elegant code evokes the same sense of wonder and admiration that I feel when I experience other more traditional forms of art. It has a sense of beauty, but here commingled with an inherent practicality that gives it a unique and highly agreeable aspect.
Because of this admiration for what others can do, I find myself often bridling at the easy dismissal of programming. Mind you, it's never dismissed outright, but the term is loosely used. Two decades ago, people who used spreadsheets described writing macros as programming. The similarity is deceiving only to the non-programmer. Ten years ago, it was HTML programming that converted designers into developers. (Shockingly the phrase "HTML programming" returns 1.2 million hits on Google.) While it's certainly true that HTML5 might in fact jump the canyon, the basic rule suggests that presenting data is not the same as computing it accurately and calls on different skills.
Today, the shift now appears to have moved to BI tools that appear to make programmers out of business analysts who design reports and specify rules. This is in some ways a step back to Excel macros, as many rules engines do indeed use spreadsheet front ends.
All the while, publishers continue turning out titles such as Teach Yourself C++ in 24 Hours (a real book). The profusion of such volumes might convince the unknowing shopper that programming is not a hard field. Fortunately, the fact that the same shoppers cannot solve basic computer problems creates an intuitive sense that there must be more to it than what the book titles suggest.
This depreciation of our trade has roots in our trade, alas. COBOL was designed specifically to enable managers to run their own reports. The quixotic belief that non-programmers could do this is what still nourishes the BI field's abuse of the term. This self-deception persists despite the now considerable body of evidence to the contrary. Everything is simple for the neophyte "programmer" until something unexpected happens. Then everything stops suddenly. Frequently, a professional programmer is summoned. If none is available, the project or report simply dies in its tracks. So ends the matter.
Our trade requires problem-solving skills, imagination, curiosity, discipline, hard work, and especially experience. Add talent to these and you have Knuth's art. Note that these facets do not bar the way to anyone unlike engineering or real science, which won't acknowledge skills no matter how demonstrable until they have been certified in academia.
But the first requirement for entry is good learning materials. As part of an attempt to help in this regard, this week we announce the winners of the Jolt Award for books. These volumes, rather than the profusion of guides that offer mastery in 24 hours, or two weeks, or 30 days, show what real programming is and the heights that it can reach. Enjoy!