The unifying principle of this book is:
Everything costs something. Everything worth talking about has benefits. Nothing is free; nothing has infinite value.
This sounds very simple and unobjectionable, but experience shows people have a hard time putting it into practice and realizing how pervasive the principle is.
I wanted to file this away in my blog where I can find it easily in the future: The Problem with Threads, a rather sedate name for an article that end up calling them insane.... and pretty much meaning it wholeheartedly.
I think in coming years this will come to be considered one of the seminal papers in software engineering, if it isn't already. The topic has been covered before, elsewhere, but I don't know of any other single work that demolishes threads as thoroughly and undeniably as this.
The programmer certification debate seems never ending and I usually never like the arguments in favor of it... but I could totally get behind this certification, a certification largely based on testing and quality control, with some other related concepts. Like the author, I probably couldn't immediately pass either, but I've gotten far enough to know how important it is.
(OK, as a bone to my non-programming readers, consider the natural evolution of pet pictures on the web. It actually seems to have a consistent, emergent grammar. It doesn't meet the technical requirements of a Pidgin language, but it bears a certain resemblance; call it a faked pidgin. Gaim (open source IM client) recently renamed itself to Pidgin, and despite using a pigeon as a logo, pidgin is where the name came from. IM servers are what I will be working on in my new job starting Wednesday. That stream of conciousness ought to keep you busy clickin' some links even if you don't care about me being in your loop and incrementing your variables.)
I want to be clear about my purpose here. My point is not to claim that the uniqueness of programming is itself unique. Every interesting field is unique in its own special way. For each field, it is helpful to understand why it is unique if you wish to truly excel, or you may bring inappropriate concepts from other domains in, or export inappropriate programming concepts to other domains. I say that programming has several unique aspects and that these aspects are worth thinking about, but this does not mean that programming is privileged somehow.
In fact, that would be a very bad attitude to have since the very purpose of a professional programmer is to serve somebody else, and service workers don't succeed with a holier-than-thou attitude.
This chapter is intended both to combat the perception I have seen that programming is somehow equivalent to some other task, prompting bad suggestions and in the worst cases bad decisions, and to explicitly call out the things that are special about programming to encourage people to think clearly about them. None of this takes away from the specialness or uniqueness of anything else.
There is a delicate balance to be had here. There are powerful underlying similarities shared by many disciplines, but everything is also unique. Ideal skill development can only be had both truths are correctly balanced, when you learn how to correctly leverage your past experiences while at the same time seeing how the new task is different.
(This work is of course about programming because a programmer is what I am. I am not qualified to write Baseball Wisdom or Accounting Wisdom, presuming I'm even qualified to write Programming Wisdom. In a way, nobody ever really is, but it's better that somebody try.)
|<- Future Posts||Past Posts ->|