when relevant content is
added and updated.
In my senior year of high school, after class, I would walk about a mile to Hood College. At night was taking math and computer science courses like assembler and pascal. Until the evening I hung out in the computer lab, telnet-ing into Multi-User Dungeons and otherwise avoiding actual schoolwork. The professors generally had print-outs or cartoons on their office doors, and I read them. All of them. Those print-outs, later combined with email forwards, became the basis of what I call an alternative computer science education.
For example, learned that in C you could shoot yourself in the foot, but no one could figure out how you did it. Or that in C++ first you had to define a pistol object with a shoot method. That in Perl you’d stab yourself in the foot with a large Swiss Army Knife.
Mind you, I had no idea what C, C++, or Perl were, other than programming languages. I had simply read a printout on some professor’s door. I would go on to learn and work professionally in those languages, and that background gave me some insight. For that matter, learning Assembler at Hood made C++ and most other languages incredibly easy to learn.
Those snippets generally came from shared emails on the ARPANet, which became newsgroups. In 1990, two programmers, DeGrace and Stahl, collected a few of them in their book Wicked Problems, Righteous Solutions. I was fortunate enough to find a copy of that book, wedged behind a file cabinet, in the early days of the 21st century. Today, the book is $45 on Amazon — if you can find it. In that book you will find the first references to Scrum. You will also find the first references to mature iterative methods which we call Agile today.
Sadly, none of these texts appear in any guide to curriculum. But they should, as they summarize key points the curriculum guides miss. They are, in a way, an alternative route to truth.
Your CS Alternative Education
A few of the best parts of that “Computer Science alternative” education still survive in corners of the internet. I woud like to share them with you.
For me to select them, the articles needed to be free, funny, insightful, and reasonably short. I could make another list of books, like Peopleware or the Mythical Man Month. This list is free things to read during a coffee break.
If you want insights into the human condition as it intersects with software, well, this is my pearl of great price, given to you.
A few of my favorite things
Worse Is Better – Design philosophy distilled that holds up today.
Big Ball of Mud – How your amazing software became terrible, and maybe what to do about it.
The Big Rewrite – The only article from this century on the list, the Big Rewrite was actually created as a series of blog articles. Yes, it is important enough to include here. Also see Joel Spolsky’s classic article never do this, part one.
The Story of Mel – The story of a “real” programmer who took advantage of a hardware defect with the drum to build a near-magical feature into a computer. If it hooks you, the internet has done a fair bit of analysis on it.
Real Programmers Don’t Use Pascal – Makes me wonder how the original author would feel about Java, Ruby, Kotlin, and Swift.
In the Beginning Was The Command Line – How can you not like an article where Microsoft and Apple are car dealerships and that new, competing platform is the Batmobile?
Shooting Yourself in the Foot – Explaining the beating heart of every operating system and programming language.
Understanding CS History
Except for the big rewrite, these were stories I read at the end of my childhood. They were created in a different age, before the GUI. They show up as straight courier font text where all the characters were the same size. To learn these stories is to understand how I see the world today, and to learn a little of how I think.
One story, that I believe is reprinted in Wicked Problems, seems to have fallen off the internet. It does not seem to appear in The Jargon File, or any printed collection of programing stories. That is the story of two programmers, working across the street from each other, developing identical systems. It is the most powerful story on productivity I have ever read.
I may have to recreate it.
In the mean time, what did I miss?