Tag Archives: computerscience

Opinion

Programming Pearls

Every year I try to complete the Advent of Code. Every year I fail to finish. I get about halfway through, and the exercises start taking longer to complete than I have time.

Every year I think about Jon Bentley’s Programming Pearls1, because the same kinds of challenges you find in Advent of Code can be found in the book. The main difference being the quality of the answers. At least in my case2. In the words of the preface: “Programming pearls whose origins lie beyond solid engineering, in the realm of insight and creativity.”

The format of the book involves presenting a programming problem and then iterating on the solution while discussing the trade-offs involved at each step. It’s quite an old book by computing standards – the second edition was published in 1999 – and you may be put off by the use of C to illustrate the solutions. I would urge you to continue anyway, even if you are not an expert in C. You may also find some of the solutions to be hard work. Honestly, that’s part of the fun. If you don’t like having your brain turned inside out, this isn’t the book for you!

As you work your way through the chapters, you realise that the key for most of them is not esoteric optimisations or low-level hacking made possible by the C programming language. Instead, it’s data structures. If you somehow manage to store your data in the “correct” way, the algorithm to process it becomes simpler, clearer and faster. It’s almost miraculous.

Of course, there’s a lively debate about “computer science” and whether it should be the subject of developer interviews. What I would say is that the kinds of people who like to attempt Advent of Code are very likely the kind of people who will also enjoy Programming Pearls.

  1. Not to be confused with Programming Perl. ↩︎
  2. In my defence, I usually use Advent of Code to learn (or brush up on) a new programming language rather than solve the puzzle in the best way. That’s my excuse, and I’m sticking to it. ↩︎
Blog

Facts and Fallacies of Software Engineering

I’ll be honest: I wanted to like “Facts and Fallacies of Software Engineering” by Robert L. Glass more than I did. I’m not sure if it’s dated badly — it’s from 2002 — or I was in the wrong frame of mind, or something else, but it just didn’t work for me.

The book is structured as a list of facts grouped around areas such as “Management” and “Requirements.” For each fact, there is a discussion, the controversy, and then the sources and references. The writing aims to be friendly, but I found it a bit grating1.

Going back through the fifty-five facts and fallacies, I find that I agree with the majority of them2. Twenty years on from the original version, I suspect that some are less controversial than when it was originally published. There is some degree of (justified) scepticism about the newfangled “agile” process, which is now largely standard across the industry. Yet it’s also reassuring how little other things have changed. There is still little transfer between academia and industry. Quality continues to be a hot-button topic. And software maintenance rarely gets the love it deserves.

I’ve seen this book described as a classic, so maybe I’m missing something. There are many books I would suggest you read first. In the end, I didn’t like the writing, and I think that there are too few original insights in too many words.

  1. This is such a subjective thing. I think the objective in was modesty or self-deprecation, but it came across as boasting. ↩︎
  2. I’m resisting the temptation to argue against those that I don’t agree with. ↩︎
Blog

The Art of Leadership

Before you ask, yes, it is weird that I’m reading a bunch of “management” books.

You can watch Michael Lopp’s career by following his various books. Start with “Being Geek,” the software developer’s career handbook. The move into management resulted in “Managing Humans.” And his promotion from manager to director and executive gets you “The Art of Leadership,” which is the book I recently finished.

My career has not followed the same trajectory. I continue to be an “individual contributor,” so why would I read this book?

Two basic reasons. First, Lopp is a great writer. He wraps the lessons around relatable stories, even if they don’t exactly mirror my experience. Secondly, to use a cliché, leadership comes from everywhere. I may not manage people, but I do have to lead. As a consultant, my whole job involves influence, persuasion and strategy.

In short, I don’t think you have to be a manager to get something out of this book, but if you like to sit in the corner and code all day, it’s unlikely to be your thing.

The book is structured into three sections, manager, director and then executive. Within each section, there are a bunch of small things that, done well, will result in great results (hence the sub-title). There are so many great parts that it would be easy to quote the whole book. I’ll refrain, but here are a few highlights and observations.

There are parallels with other books I’ve read recently. Chapter 15 “Saying the hard thing,” covers a lot of the same ground as “Radical Candor,” with many of the same positives.

The “faux zone” is very relatable. There are certainly times when I feel incredibly busy, but at the end of the day, I don’t feel like I got anything done. There are insights here that make me feel better about it.

A “Precious Hour” reminds us that being busy is not the same as being productive.

And, finally, this is so me: “I love to start new things, but I often lose interest when I can mentally see how the thing is going to finish, which might be weeks or months before the thing is actually done. Sorry. I’m getting better at this.” I remember I did one of those “type indicator” tests a long time ago, and one of the categories was “completer-finisher.” I immediately knew that I was the opposite of that.

As with all books like this, some of the suggestions I already do while others are not relevant; however, taken as a whole, there’s plenty of good advice.

Blog

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.

Blog

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. ↩︎
Links

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