It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. On a weekly basis, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. Today, we are going to take a look at one of his earliest works I could get my hands on Computer Programming Fundamentals, co-authored with Herbert D. Leeds. published by McGraw-Hill in 1961.

I recall this book going into much detail about computers. In these early days of the computer age, Leeds and Weinberg cover much of the foundation of most computers around even today. This book is not so much about leadership, or what any of the other Weinberg books cover that I read. Instead, you should feel comfortable reading about assembly language, and covering very low details in the computer field. I felt comfortable jumping into this book because I had read the great Write Great Code series beforehand, and having worked through Patterson and Hennessy years prior, I wanted to see what Jerry’s earlier writings were all about.

And I found myself surprised by some citations that I had to write immediately. No matter what year Jerry’s books were initially published, he has this writing style that is timeless. Sure, some of the assembly language details have not aged over the years, but still, I was able to find some timeless gems even in this decades-old book. Let’s go through the notes I kept while reading this book to remind me later about lessons from 1961. (Unfortunately, I did not note down the page number back then.)

All good rules should not be applied with unthinking faith.

The most prevalent thing I encounter regularly nowadays where I see a good rule applied with unthinking faith is probably the user story template. My favorite example where you can see the user story applied without thinking about it, probably is “As a line of code, I want another line of code, so that I’m not so lonely anymore.” I often point product owners and Scrum Masters to the fact that Ron Jeffries, the first XP coach who basically invented user stories talks about that template as training wheels. Turning on your brain, once you see something like that in your product backlog, you probably will also question whether that template is helpful in this circumstance at all.

Over the years, I have seen many such good rules applied with unthinking faith. Heck, I’m guilty as charged with doing that on my own. Reading a book from 1961 that I’m not the first to realize, gave me shivers, and some relief at the same time. Please keep your brain turned on while working. It will pay off in the longer run.

One of the more dangerous occupational hazards in computing is the habit of working out a set of diagrams, formulas, and figures until some impressive statement like “twice as efficient” emerges.

Oh, I wasn’t aware that the S_Fe framework was already around in 1961. I surely felt like it was an ancient dinosaur when I crossed paths with it for the first time.

Jokes aside, I stand in awe at the wisdom behind this. You surely have come across this phenomenon in your career as well. Seeing that this pattern started actually WAY earlier, is both a relief and some kind of a shock to me. A relief that this is not as new as I thought it was. A shock that we never managed to overcome this in all these decades.

If we have mastered a few of these fundamentals along with the habit of curious exploration, we can rediscover special techniques as we need them.

Here, in this quote, I see the twelfth principle of the Agile Manifesto reflected. We should continue to learn new things curiously. By keeping our curiosity up, we will find new ways to approach problems and find clever solutions to ever-emerging problems. There are too many organizations I have seen over the years, that basically gave up on this curiosity, and I often leave these companies with the feeling that over time they will have to realize their demise if they don’t change that.

If we produce a new vocabulary word (subroutine) we must not produce something sloppy or something that may be misunderstood or misinterpreted.

This quote immediately reminded me of the aspirations in Clean Code and the Software Craftsmanship movement that started from this. Of course, code is abstract and subject to interpretation. The less likely we manage to write our code, our unit tests, and our acceptance tests for misunderstanding and misinterpretation, the better off we will be. That was the case decades ago, and with more and more abstraction layers in higher-level programming added, this is a good reminder to avoid wasting time while trying to understand your code from yesterday.

Knowledge of only the instructions on computer will permit to code; but to be a programmer of any professional standing, computer operation must be understood.

In this quote, I am reminded of why I warn about the Year 10,000 problem already. In my mind, very few people will still understand how the underlying computer works and how dates are represented. Maybe two persons in the universe will understand that by then, and the computer age will long have forgotten the basics or fundamentals of the machine. If we stop to understand what the machines are doing, we will suffer the fate of being poor servants to the machines that should serve us. Maybe a story on my own is appropriate on this one.

A couple of years back, I had two TDD classes with a client on two different teams. Once was in the C++ programming language, the other for a team that used JavaScript. In the days before the training, I got familiar with the technology stack, especially since I never wrote much JavaScript code on my own. I programmed a kata or two in the evening to get myself ready to help with the most basic hurdles that the group in my training could face.

For JavaScript, whenever I ran into a problem stemming from my lack of understanding of the language, I looked on the internet for a solution to something. Oftentimes, I found a solution on StackOverflow, read through it, tried to understand it, then wrote my solution in my kata based on my new understanding of how the language works.

When visiting the JavaScript team, the youngest member on that team described himself as self-taught and programming JavaScript for six months. During the training, I joined him in the exercises and noticed how he searched on the internet for a solution to a particular problem, then directly copied & pasted the solution from StackOverflow without trying to understand it at all. Basically, six months in, he was still programming as I did the week prior. The only difference between him and me was, that I tried to understand what I was copying over. Leeds and Weinberg knew about this decades prior.

In a Twitter conversation years back, I recall Michael Bolton pointing out to me that these quotes are timeless since Computer Programming Fundamentals are, well, fundamental. I don’t recall more nuggets from this book, otherwise, I would have written them down. For me, I was delighted to see how Jerry over the years kept to his nature of writing timelessly, and that even started with this book from 1961. Generally, I wouldn’t recommend or urge you to read it, as some of the technical details might either shy you away or they have not stood the test of time that well. I read this book out of my own curiosity, and as you can hopefully see, I found some still pretty relevant quotes in there.