Tag Archives: computerscience

Code- The Hidden Language of Computer Hardware and Software

While I have more than enough books on my “to read” list, I am always up for suggestions. “Code” came up in a Twitter conversations about computer hardware. I noted that one of my favourite courses from my Computer Science degree (in hindsight if not at the time) was where we went from “What is electricity?” right up to a pretty much fully working CPU. “Code” was recommended as it covers the same ground.

If you’d like to refresh your memory or you never took such a course, this is great introduction to how computers work.

It’s a book of two halves.

The first half starts with the foundations and principles. It starts with the concepts, like Morse Code, before building up from relays, to logic gates, to half-adders, to a complete, working CPU.

That bit is great. Clear steps and descriptions. I was reminded of many things that I first picked up at university and learned some details that I’d either completely forgotten or had never internalised at all.

After you get a working CPU the book largely turns into a history lessen, albeit from the year 2000. It talks about the rest of the computer but, out of necessity, in significantly less detail.

I found this second part to be weaker, though this may be because I’m coming at it from 2021 rather than 2000. These last sections have dated much more than the earlier, CPU-bound section and I wonder if the book had been about building just the CPU rather than the whole computer it would have dated better?

Having said all that, while weaker than the first half, it’s still well written and easy to understand.

Even if you skim the later sections, what quickly becomes apparent is that a computer has layer upon layer of abstractions. You may not understand every layer in the same amount of detail but knowing that they exist is, I think, useful as a software developer.

I can’t help but recommend this book to anyone interested in the subject.

Unix: A History and a Memoir

This is probably the geekiest book I’ve read in a long time. It’s basically one step up from reading the source code for your favourite operating system. Or perhaps having a favourite operating system.

What I would say is that Unix has been pretty much the only constant throughout my career. I started with Solaris and HP-UX at university. I installed an early version of Linux on my personal machine to avoid the thirty-minute walk from home to the university labs. I’ve done consulting, I’ve developed both vertical and horizontal applications1, C and C++, Swift and Java, banking and telecoms. Pretty much the only thing they’ve all had in common was some sort of Unix underpinning.

And that’s bizarre. So much of computing changes in five years, yet Unix wasn’t even new when I started at university!

This book is the story, the memoir, of one of the people who built it. And it’s fascinating but probably only for a relatively small audience. I loved the first chapter, where he name-dropped some of the people who Kernighan worked with. Plaugher. Aho. Ullman. Honestly, if you’ve not heard of them, you’re probably not the target market for this book.

Also, if you’re Richard Stallman, you’re probably not the target for this book either: in the last chapter, he says that GNU software is “open source.”

On the other hand, if you’re not Stallman and you know about some or all of the people involved, then you are the target for this book. Read it. You’ll love it.


  1. Is that common terminology? A “vertical” application is one that’s applicable only to one industry, such as a trading application. A “horizontal” application is usable by many, like a database or operating system. ↩︎

My delicious.com bookmarks for October 23rd through October 27th

Communication

“Do you ever change this type of trade?”

I was sat on the trading floor discussing a new feature that I was implementing with the person who would be using it the most.

“No, never.”

This was one detail of the change that would have far-reaching consequences in the code. A “no” would mean a few days of development, a “yes” would indicate several weeks.

“Are you absolutely sure? You don’t change it even once a month?”

I knew they’d like the smaller estimate but, equally, I knew that I didn’t want to end up trying to implement several weeks worth of functionality in the smaller time frame. I’ve seen that kind of thing happen too often.

“John1, we don’t ever change these trades do we?”

John was the head trader. If anyone would know it would be him.

He rubs his head and leans back, thinking.

“Why would you want to? No, I can’t see us ever changing one.”

Of course, you can guess what happened thirty minutes into the first trading day with the new software.

So, what happened here? Why did we get the requirements so wrong? And why did we only find the mismatch after the system was moved into production?

Both the problem and the solution is the same thing: communication. Or more precisely, communicating using the right language.

Some developers are happy to only “speak” technical, proud that they are masters of their programming environment but ignorant of their users problems or how they really use the software.

Above I started out correctly, I was trying to understand the traders business and talking in terms of booking trades, positions, legal entities and a bunch of acronyms that would make even less sense out of context.

But I made one error: I used the word “change” without defining what I meant. I meant, well, any change. And so did they. Yet they didn’t consider moving a trade from one book to another to be a change and, unfortunately, I did.

You’d like to think that there were checks and balances in place to make sure that this kind of thing didn’t happen. And there were. In addition to informal and formal testing, there was over a week of “parallel running,” where the traders had to use the old and the new system together and check that the results were the same in both of them.

Were there any moved trades during this time? Of course. Why did the traders not notice? Well, it was about right; the differences, while present, were explicable and so not considered significant enough to mention even though I asked to hear about any problems at all.

So, again, communication. Or at least human nature. I wanted to hear about any differences but they tried to help me by only talking about differences that they couldn’t account for.

What’s the answer? Well, I’m not sure there’s an easy one. “Understanding your user” is a short, simple phrase but hides so much. If you spent the time to fully understood their job you probably wouldn’t have the time to do your own. But finding the balance is crucial.

  1. Names have been changed to protect the… well, they work for a bank so I hesitate to say “innocent” but you know what I mean. []

My delicious.com bookmarks for November 6th through November 10th

  • News Corp to Offer Plaid Stamps! – "Giving Murdoch the benefit of the doubt, then, I’m guessing he simply doesn’t mean what he said. Perhaps he just wanted to sow a little confusion, get some publicity and maybe a concession or two from Google."
  • The night the Berlin Wall fell – "For me it was that rare occasion when a story was unqualified good news. After years watching the way communism was practised, I felt no need to mourn its collapse. Whatever came next had to be better." Twenty years since the fall of the Berlin wall.
  • OMG Ponies!!! (Aka Humanity: Epic Fail) – "The real world has failed us. It has concentrated on local simplicity, leading to global complexity. It's easy to organise a meeting if everyone is in the same time zone – but once you get different continents involved, invariably people get confused. It's easy to get writing to work uniformly left to right or uniformly right to left – but if you've got a mixture, it becomes really hard to keep track of. The diversity which makes humanity such an interesting species is the curse of computing."

My delicious.com bookmarks for September 11th through September 15th