Skip to content

Book Review: The Cuckoo’s Egg

I recently finished “The Cuckoo’s Egg”, by Clifford Stoll. It was a fascinating non-fiction book exploring the foundations of computer security in a personable format.

The setting is the mid 1980s. The author discovers something weird on his academic computer system. There’s an unexplained charge of 75 cents. He digs deeper, discovers that someone who’s left the university is logging in.

After further investigation, he discovers that the user who is logging in is an intruder. After discussing the situation with his boss, he gets three weeks to find out who they are. He figures that’s plenty of time.

The investigation ends up taking a year.

It also extends far beyond his academic systems, both in scope and effort. Stoll talks to numerous government agencies and private organizations, letting them know they’ve been attacked and getting their assistance tracing the hacker. He sleeps under his desk. He rigs up a pager so that he can know which accounts the hacker is using. Stoll sets up printers so that every word the hacker types is recorded, unbeknownst to him.

It’s quite the tale. As someone who has worked with software for years, I really appreciated the historical nature of it. When I became aware of the internet, in my youth, some of the groups and communities he mentions were still around; I remember reading and posting to usenet. But many of the systems were before my time. I’ve never touched a computer running VMS, for instance.

But, for all the history, the people problems were the same: users not changing passwords, system managers not locking their software down, bureaucrats happy to take information but not willing to share. Let’s just say, mistakes were made.

I also enjoyed the author’s interspersal of lived experiences. We don’t simply follow one computer nerd tracking another. We also learn about milkshakes, parties in San Francisco, curry nights and his first experience with the microwave. While some phrases and analogies are repeated (“should we thank someone who goes to a little town and robs people to illustrate they should lock their doors” pops up at least twice), in general the book is pretty readable. Stoll’s personal stories and musings help that readability immensely.

All in all, a great book if you are interested in the history of computing or modern security practices. If you’re interested in learning more, you can check out a paper he wrote based on the same experience for ACM.

What I wish I had known when I was starting out as a developer

As I get older, I wish I could reach back and give myself advice. Some of it is life advice (take that leap, kiss that girl, take that trip) but a lot of it is career advice.

There’s so much about being a software developer that you learn along the way. This includes technical knowledge like how to tune a database query and how to use a text editor. It also includes non technical knowledge, what some people term “soft skills”. I tend to think they are actually pretty hard, to be honest. Things like:

  • How to help your manager help you
  • Why writing code isn’t always the best solution
  • Mistakes and how to handle them
  • How to view other parts of the business

These skills took me a long time to learn (and I am still learning them to this day) but have had a material impact on my happiness as a developer.

I am so passionate about this topic that I’ve written over 150 blog posts. Where are these? They’re over at another site I’ve been updating for a few years.

And then I went and wrote a book. I learned a bunch of lessons during that process, including the fact that it’s an intense effort. I wrote it with three audiences in mind:

  • The new developer, with less than five years of experience. This book will help them level up.
  • The person considering software development. This book will give them a glimpse of what being a software developer is like.
  • The mentor. This book will serve as a discussion guide for many interesting aspects of development with a mentee.

The book arrives in August. I hope you’ll check it out.

Full details, including ordering information, over at the Letters To A New Developer website.

Not delivering end user value

When you’ve worked in software for as long as I have, you have made mistakes. I’m going to catalog some here intermittently so I can analyze them and hopefully avoid them in the future. I may change identifying details or use vague descriptions.

When you interact with a client, especially if they are knowledgeable about their domain, it can be hard to come in and seize the reins. You want to be respectful of what they know and what you don’t. But at the same time, they hired you for what you know, and sometimes you have to stop hurrying forward and take a look around, especially if the project is not running smoothly. This is a story about a time when I didn’t seize the reins, and the problems that followed.

I was working on a long running project for a client. It was a bear of a project, with a ton of domain knowledge and some complicated partially done software. The team working for the client churned, including employees and consultants. When I was brought on, I didn’t have a full picture of the problem space and it felt like we didn’t have time to gather it. No one had this global view. Meetings with the client would often go down rabbit holes and into the weeds. The project was a rewrite and the system we were targeting to replace kept evolving. This original software system powered the business and yet didn’t operate with normal software development practices like version control. When looking at the code, it was unclear what code was being used and what was not.

But most importantly, other than diagrams and meetings, we didn’t deliver anything of value regularly to the client. We would spin in circles trying to understand previous work and take a long time to make small changes. We did write a testable new system and follow other SDLC best practices including version control, CI/CD and deployment environments.

This project finally started to turn around when we shifted from trying to replace the entire running system to replacing the smallest part that could possibly work end to end. This gave the team a clear vision, and showed the client a path to business value. We accomplished more in a couple weeks with this perspective than we had in the previous couple of months. This also let us commit to a real project plan and timeline. Unfortunately, the client wasn’t happy about the projected and past expense, and shut down the project weeks after the development team was starting to show traction.

Lesson: I wish we would have had taken the “smallest bit that would possibly work” approach from the very beginning. I wish I’d had the insight to call a halt and not continue down a path that was clearly not working a few weeks after observing it, not a few months.