Code That Fits in Your Head: Foreword
Uncle Bob discusses how programming is hard, it's fun to disagree with Mark Seemann, and how the gems Mark has compiled in his book provide deep insight that will make software development easier.
From the book
From the book
My grandson is learning to code.
Yes, you read that right. My 18-year-old grandson is learning to program computers. Who's teaching him? His aunt, my youngest daughter, who was born in 1986, and who 16 months ago decided to change careers from chemical engineering to programming. And who do they both work for? My eldest son, who along with my youngest son, is in the process of starting up his second software consultancy.
Yeah, software runs in the family. And, yeah, I've been programming for a long, long time.
Anyway, my daughter asked me to spend an hour with my grandson teaching him about the basics and the beginnings of computer programming. So we started up a Tuple session and I lectured him on what computers were, and how they got started, and what early computers looked like, and...well, you know.
By the end of the lecture I was coding up the algorithm for multiplying two binary integers, in PDP-8 assembly language. For those of you who aren't aware, the PDP-8 had no multiply instruction; you had to write an algorithm to multiply numbers. Indeed, the PDP-8 didn't even have a subtract instruction; you had to use two's complement and add a pseudo-negative number (let the reader understand).
As I finished up the coding example, it occurred to me that I was scaring my grandson to death. I mean, when I was 18 this kind of geeky detail thrilled me; but maybe it wasn't so attractive to an 18-year-old whose aunt is trying to teach him how to write simple Clojure programs. Anyway, it made me think of just how hard programming actually is. And it is hard. It's really hard. It may be the hardest thing that humans have ever attempted.
Oh, I don't mean it's hard to write the code to calculate a bunch of prime numbers, or a Fibonacci sequence, or a simple bubble sort. That's not too hard. But an Air Traffic Control system? A luggage management system? A bill of materials system? Angry Birds? Now that's hard. That's really, really hard.
I've known Mark Seemann for quite a few years now. I don't remember ever actually meeting him. It may be that we have never actually been together in the same room. But he and I have interacted quite a bit in professional newsgroups and social networks. He's one of my favourite people to disagree with.
He and I disagree on all kinds of things. We disagree on static versus dynamic typing. We disagree on operating systems and languages. We disagree on, well, lots of intellectually challenging things. But disagreeing with Mark is something you have to do very carefully because the logic of his arguments is impeccable.
So when I saw this book, I thought about how much fun it was going to be to read through and disagree with. And that's exactly what happened. I read through it. I disagreed with some things. And I had fun trying to find a way to make my logic supersede his. I think I may have even succeeded in one or two cases—in my head—maybe.
But that's not the point. The point is that software is hard; and much of the last seven decades have been spent trying to find ways to make it a little bit easier. What Mark has done in this book is to gather all the best ideas from those seven decades and compile them in one place.
More than that, he has organized them into a set of heuristics and techniques, and placed them in the order that you would execute them. Those heuristics and techniques build on each other, helping you move from stage to stage while developing a software project.
In fact, Mark develops a software project throughout the pages of this book, while explaining each stage and the heuristics and techniques that benefit that stage.
Mark uses C# (one of the things I disagree with ;-), but that's not relevant. The code is simple, and the heuristics and techniques are applicable to any other language you might be using.
He covers things such as Checklists, TDD, Command Query Separation, Git, Cyclomatic Complexity, Referential Transparency, Vertical Slicing, Legacy Strangulation, and Outside-In Development, just to mention a few.
Moreover, there are gems scattered literally everywhere throughout these pages. I mean, you'll be reading along, and all of a sudden he'll say something like, "Rotate your test function 90 degrees and see if you can balance it on the Act of the Arrange/Act/Assert triplet" or "The goal is not to write code fast. The goal is sustainable software" or "Commit database schema to git".
Some of these gems are profound, some are just idle mentions, others are speculations, but all of them are examples of the deep insight that Mark has acquired over the years.
So read this book. Read it carefully. Think through Mark's impeccable logic. Internalise these heuristics and techniques. Stop and consider the insightful gems as they pop out at you. And just maybe, when it comes time for you to lecture your grandchildren, you won't scare the devil out of them.