I read a synopsis of this book a long time ago in a Mexican edition of the Readers’ Digest, which was probably published between 1983 and 1984. I remember taking the subject of digital electronics in the 3rd or 4th semester of high school, and some terms, like a NAND gate, were not unknown to me, so I’m pretty sure of the mentioned years. Who would have said I would get to know and work with some of the technologies mentioned in this book?

While searching for the book’s cover image for this post, I noticed that most search results referenced a book with 320 pages. Mine goes to 293 and only has a couple more at the beginning and end, with ads, blurbs, and praises. Is it just a difference in the typography and layout of the work? Or am I missing something else? Anyway, let me talk about my impressions of this work.

The prologue is a kind of apology for the protagonist and the first chapter of the company in which he worked. Unlike other companies continually and conspicuously cited in works devoted to studying computer architectures, I vaguely remember some mention of Data General (DG). It is more common to find mentions of DG’s competing works or products in this book (such as the DEC VAX), so it is interesting to question the success to which the book alludes.

I had the chance to work with a cluster (a computer arrangement that was uncommon in the 1980s) of DEC VAXes when I worked at the Mexicana maintenance base between 1992 and 1993. Despite my short experience in the field at the time, there was quality and finesse to VMS and DCL (as well as the documentation surrounding them) that would always be a benchmark for a good product. Data General no longer exists (neither does DEC). I can’t help but wonder what it would be like to work with a NOVA or an Eclipse.

The second chapter talks about the internal struggle to get the company to finance a new computer project. Actually, what is described is something familiar that those of us who find ourselves with projects face: from apathetic management to the outburst that often occurs on the part of bosses and other areas who seek to justify their existence (simply because they are the ones who must do so). In this way, reading the book brought back many memories, even some passages from the synopsis I thought I had forgotten.

The third chapter is about the strategy they followed to recruit more engineers and the motivation these engineers had to accept a job that would require a lot of their free time. IBM is often mentioned as a reference of what the reader can consider a good job or employer, and, in contrast, what DG was offering at that time. So, why would many young recruits accept a lower-paying job to construct a new computer? Because of an opportunity that was challenging to find even within IBM itself.

That was a long time ago, but similarly, when I started developing myself professionally, I had two approaches with IBM. One was when I was studying for my master’s degree, at a meeting sponsored by UPIICSA, for a career development recruiting session at IBM. The speaker referred to an «IBM university,» which, in many ways, «should be considered a master’s degree in itself.» Because of this, it was incompatible with other studies, implying that I should abandon my master’s degree in informatics. I rejected the offer, and I have never regretted it. The second encounter was when I had just joined Banamex. IBM approached me and offered me a job that paid slightly more than Banamex but with fewer benefits. I turned down the offer because I had only recently joined Banamex and had many plans for my new job. I don’t regret it either. Reading this chapter reminded me of the spirit of my youth, when I was much more interested in doing interesting things instead of making money— a spirit that, although it hasn’t been completely lost, has become somewhat conformist. This chapter also reminds me (as I mentioned earlier) of how many people give up their master’s studies because of the promise of a job or promotion, both when I was a student and as a teacher, and how I have met many people who regret it terribly.

The fourth chapter talks about «a golden moment,» and I was surprised to recall it from the book synopsis in Reader’s Digest. «A golden moment» is an instant of illumination in the search for an answer. Something I’ve also experienced in my professional life.

The fifth chapter discusses the nightlife that many developers enjoy. The sixth is an excellent description of how the computer works at the component and microcode level. This also brought back memories of learning about computer architecture from the eponymous work of M. Morris Mano. The sixth chapter closes with something I have also experienced and have become more sensitive to: that mental follow-up that one does in understanding something, and how any slight distraction leads you to resume an entire path that can take tens of minutes or hours.

The following seven chapters are dedicated to describing the tedious and hard work of debugging the hardware at the microcode level and to portraying some of the people who participated in the construction of this machine, as well as some moments and events that occurred. Finally, the last two chapters are dedicated to what the building teams experienced when the job was finished and what happened to them afterwards.

This should be an obligatory lecture for anyone in computer and software design, not as a technical lecture but as one about organisational culture and team building.