Skip to content

Write Programs for Programmers

June 8, 2009

By far the most influential book I’ve ever read (in my professional life) is “C++ In Action: Industrial-Strength Programming Techniques” by Bartosz Milewski. I first read it at a time when I’d learned just enough about programming to realise how little I knew about programming, and I was in dire need of being pointed in the right direction before I just gave up completely. Fortunately, Rob was on hand to beat me round the head with his copy of C++ In Action and I finally took my first steps on my ongoing journey to becoming a proper programmer.

What’s particularly special about C++ In Action is that it’s not a book about C++; it’s a book about programming. It’s full of all the life-lessons that programmers need to learn in order to do their jobs effectively; lessons that I’m still learning and implementing and refining today.

For me, the biggest lesson from the whole book is this: don’t write programs for computers; write programs for programmers. As Bartosz himself says in the preface…

…in this book I emphasise the human factor in programming. My credo is “programs are written for programmers, not computers”. Programmers want to write better programs not in order to make them more understandable to computers, but to make them more readable to humans. Program maintenance is impossible without program understanding. This might seem like an obvious thing to say, but many programmers overlook this self-evident truth.

I can’t even begin to describe how this ethos has shaped my thinking. It’s the greatest of contradictions; what might seem to an outsider like an individual, anti-social world inhabited by up-all-night pizza-chomping mountain-dew-guzzling long-haired Hawaiian-shirted hackers ultimately stands or falls on the ability of software developers to interact, both in person and through their code, with all the other people that, in one way or another, will touch their software. We are not alone. But that’s a whole other post.

Every time I try to write a blog post, or give a talk, I try to set out just one thing that, if nothing else is listened to or read or remembered or taken away, then that one thing is enough; that one thing is the one thing to take to heart.

Write progams for programmers isn’t just the one thing for this entire post; it’s the one thing for this entire blog. If you write software, and in any way care about what you do, then this has to be the foundation of everything you do. Sure, there are plenty of other lessons to learn that build on top of this (and there’s plenty more of them in C++ In Action), but if you write programs for programmers then you’re off to a flying start.

3 Comments leave one →
  1. June 8, 2009 9:41 pm

    Hi Dan,

    In Bjarne’s book he says:

    Design and programming are human activities; forget that and all is lost.

    I really liked that in the midst of all the technicality.

    I’ve recently been reading Clean Code by Uncle Bob Martin. It has lots of great suggestions for making code more readable. I also heartily recommend Working Effectively With Legacy Code by Michael Feathers as a way of understanding how to make difficult code easier to maintain. Studying that can make it easier to avoid the mistakes in the first place.

    There’s a great quote in Clean Code from Ward Cunningham. Bob Martin asked a few people what they thought clean code was. Ward said:

    You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.

    Pretty amazing challenge. Write code that does what you expect and doesn’t look like it’s fighting the language.

    Recently I’ve been fullfilling Greenspun’s 10th law on every project.



  2. June 9, 2009 11:06 am

    Hi Pete,

    Both Clean Code and Working Effectively With Legacy Code come with Rob Allen (and now Pete Wood) stamps-of-approval, and I’m planning on reading them both. Clean Code is sitting on my desk, waiting to be read. If I could just clear my head enough to sit down and make a start…

    I had to look up Greenspun’s 10th law; (it’s not exactly what he’s saying, but) “Favour using third-party code over writing your own” needs to be added to the list. One of the most liberating thing about working on a Java project has been the availability of third-party tools and libraries to grab hold of and glue together. But I’m wandering off-topic… again…


  1. Favour Constructors Over Setters -

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: