Skip to main content

Books: Digital At Work: Snapshots From The First Thirty-Five Years

I just finished reading Digital At Work: Snapshots From The First Thirty-Five Years.
"Digital At Work" tells the story of the first thirty-five years of Digital Equipment Corporation [DEC] and illuminates the origins of its unique culture. First person accounts from past and present members of the Digital community, industry associates, board members, and friends - plus a wealth of photos from Digital's archives - trace the company's evolution from the 1950s to present.
In short, I really enjoyed it. By reading this book, I was able to vicariously experience the growth and history of one of the most significant companies in the history of computing, and it definitely left an emotional impact.

I think one of the most interesting things about Digital was its culture. Some people might call it chaos. Other people might call it a meritocracy. It was definitely in the MIT tradition. It wasn't uncommon to get into shouting matches over which approach to take. Good ideas were always more important than what little company hierarchy existed.

Here are a few random, interesting quotes I jotted down while reading the book. I left out the page numbers because you can just search for them in the PDF:
Fortune magazine’s report in the late 1950s that no money was to be made in computers suggested the word itself be avoided in Digital’s first business plan.

If you had to design a modern computer with the tools we had, you couldn’t do it. But to build the first computer was an eminently doable thing, partly because we could design something that we could build.

Many of Sketchpad’s capabilities were sophisticated even by the workstation standards of the 1980s. “If I had known how hard it was to do,” Sutherland said later, “I probably wouldn’t have done it.”

Six MIT students, including Alan Kotok and Peter Samson, bet Jack Dennis, who ran the PDP-1, that they could come up with their own assembler in a single weekend. They wrote and debugged it in 250 man-hours, and it was loaded onto the machine when Dennis came to work on Monday. This was the sort of job that might have taken the industry months to complete.

Success depended on extraordinary personal commitments, often creating high levels of personal stress. “The atmosphere has always been that of small groups of engineers with extremely high energy, working hard and aggressively for long, long hours-always on the edge of burnout,” says Jesse Lipcon. “That can be both positive and negative.”

“We didn’t have much experience,” says Cady, “but we were energetic, enthusiastic, and too dumb to know what we were doing couldn’t be done. So we did it anyway."

And, of course, we disagreed with much of what the original committee had done. So in the best Digital tradition, while creating the impression that the specs were frozen and we were just fixing some bugs, we surreptitiously went around changing many things, simplifying the protocols as much as we could get away with.

Primarily, architecture is the ability to take complex problems and structure them down into smaller problems in a simple, tasteful, and elegant way.

“It worked out that there were about a million lines of code in each new version of VMS,” says Heffner. “The first version was about a million lines of code, and by the time we got to Version 5, there were 5 million lines of code. We’re talking about a really heavy-duty operating system here, with more functionality than the world at that time had ever known.

We’d assign new kids to a senior person who would look after them, like an apprentice. Managing a good software engineer is like raising a kid-you want them to get into a little bit of trouble, but you don’t let them burn down the house.

[In Galway, Ireland] we were the only nonunion shop around, we paid well, and we did a lot of employee training so people could move up to higher-paying jobs very quickly. The hierarchy between workers and management was invisible.

This book is wonderful...As for people just entering the computer field, they will get a sense of how wonderfully uncomplicated things were, how exciting and liberating the challenges were, and how much actually got done.


Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p