May Reading


Fiction (Series):

Fiction (Non-Series):

  • They Eat Puppies, Don’t They? by Christopher Buckley ★★★
  • Requiem by Ken McClure ★★★
  • Thus Was Adonis Murdered (Hilary Tamar, #1) by Sarah Caudwell ★★
  • Cast, in Order of Disappearance (Charles Paris, #1) by Simon Brett ★
  • Total: ~7061 pages


    April Reading


    Fiction (Series):

    Fiction (Non-Series):

  • The Final Reckoning by Sam Bourne ★★★★
  • Who Could That Be At This Hour? (All the Wrong Questions, #1) by Lemony Snicket ★★★
  • Miina ja Manu Suomi-Englanti Kuvasanakirja by Tuomas Mäkelä ★★★
  • Shopgirl by Steve Martin ★★★
  • Shadows Gray by Melyssa Williams ★★
  • Where’d You Go, Bernadette by Maria Semple ★
  • 03: A Novel by Jean-Christophe Valtat ★
  • Total: ~5040 pages


    March Reading


    Fiction (Series):

    Fiction (Non-Series):

  • Supreme Courtship by Christopher Buckley ★★★★
  • Love Virtually by Daniel Glattauer ★★★★
  • The Speed of Dark by Elizabeth Moon ★★★★
  • One Day by David Nicholls ★★★★
  • Little Green Men by Christopher Buckley ★★★
  • Starter For Ten by David Nicholls ★★★
  • The Fermata by Nicholson Baker ★★
  • Little Brother (Little Brother, #1) by Cory Doctorow ★★ (my review)
  • The Great Automatic Grammatizator And Other Stories by Roald Dahl ★★
  • Lionel Asbo by Martin Amis ★
  • Total: ~7022 pages


    February Reading


    Fiction (Series):

    Fiction (Non-Series):

  • The Solitude of Prime Numbers by Paolo Giordano ★★★★
  • A Small Price to Pay For Birdsong by K.J. Parker ★★★★
  • No Way to Treat a First Lady by Christopher Buckley ★★★★
  • Bad Monkeys by Matt Ruff ★★★
  • Boomsday by Christopher Buckley ★★★
  • Squirrel Seeks Chipmunk: A Modest Bestiary by David Sedaris ★
  • Manna by Marshall Brain ★
  • Total: ~5233 pages


    January Reading


    Somewhat of a history theme this month. I spent several weeks at the end of December and the start of January driving around Pays Cathare, and with my interest suitably piqued, I sought out some reading for a more detailed background. The first, part of the Osprey Fortress series, was an interesting introduction, and would probably have been better to read before my trips, but The Perfect Heresy was much more engaging. (Update: The Pope Who Quit turned out to be an eerily prescient read!)

    Fiction (Series):

    The Steve Winslow series was a quick fun read. The books are heavily modelled after Perry Mason, so after trying another series by the same author (and not really liking it so much), I decided to read my way through the original Mason books instead. After loving Lawrence Block’s Bernie Rhodenbarr and Evan Tanner series, I’ve moved on to the Matthew Scudder books. These are much darker, and I’ll probably keep going with the series, but I’m not in as much of a hurry as I was with the two lighter series. The Sigma Force books are a slightly-more-intelligent-and-better-written-than-Dan-Brown scientists-with-guns conspiracy-theory-ahoy rompfest. They’re a little over-long at the start, but the pacing gets better as the series progresses.

    Fiction (Non-Series):

    Jammy Dodger is a fun tale of ’80s Belfast that likely wouldn’t be quite so appealing to those who didn’t live through it. It’s slightly difficult to know whether Essays In Love should be in the Fiction or Non-Fiction category. Like most of de Botton’s books it’s full of interesting insights and quotable phrases, but is rather patchy. Not the End of the World is a fascinating re-telling of the Noah’s Ark myth that asks a lot of usually-ignored questions of the story. I suspect The Brothers Lionheart would have received five stars had I read it when I was much younger. The Man Who Wouldn’t Stand Up starts off well, but then completely loses it.

    Abandoned unfinished:

    Not yet finished:

    Total: ~9,589 pages


    How can we study programming?

    When you don’t know very much about a subject, you don’t know in advance what to measure. So your early experiments are not what they might seem to be—they are not to measure things, but to determine what can be measured and what can be worth measuring. The difference here is well exemplified by the difference between the methodologists of anthropology and sociology. The sociologist is working in his own culture, about which he assumes that he is sufficiently knowledgeable to construct, say, a questionnaire as a measuring instrument. But the anthropologist cannot use a questionnaire because he does not know what questions will be meaningful in another culture. Roughly, then, we might say that the sociologist is looking for answers, and the anthropologist is looking for questions.

    The social science that provides us with the most useful overall model for computer programming is anthropology. With a little artistic license and stretching of the imagination, we could imagine computer programmers as having a culture—a shared set of beliefs and activities which shape their day-to-day activities. In our study of programming, we shall first examine the “social structure” of that culture— the way programmers relate to one another and to other people who are not programmers. We shall find some surprising possibilities for improvement in this area over present practices, more even than in the second area of study—programming as an individual activity.

    — Gerald Weinberg, The Psychology of Computer Programming, Chapter 3


    What makes a good program?

    No doubt there are programs that are used once and then thrown away. No doubt there are even more programs that should be thrown away before ever being used. Nonetheless, the great majority of programs that are written, especially by professional programmers, remain in existence for a definite life span. And during that span, most of them become modified.

    Few programmers of any experience would contradict the assertion that most programs are modified in their lifetime. Why, then, when we are forced to modify programs do we find it such a Herculean task that we often decide to throw them away and start over? Reading programs gives us some insight, for we rarely find a program that contains any evidence of having been written with an eye to subsequent modification. But this is only a symptom, not a disease. Why, we should ask, do programmers, who know full well that programs will inevitably be modified, write programs with no thought to such modifications? Why, indeed, do their programs sometimes look as if they had been devilishly contrived to resist modification—protected like the Pharaoh’s tomb against all intruders?

    — — Gerald Weinberg, The Psychology of Computer Programming, Chapter 2

    Answers on a postcard, please!


    Reading Programs

    A young novelist of our time was recently asked who were this favorite authors. He responded simply that he never read novels, as his ideas were so new and superior to anyone else’s that reading would only be a waste of his time. As you might expect, his work did not support his thesis. Perhaps the same could be said for some of our radical young programmers. Perhaps there is something to be gained from reading other people’s programs—if only the amusement engendered by their bad examples. Perhaps if we want to understand how programmers program—to lift the veil of the programming mystique—we could fruitfully begin by seeing what is to be learned from the reading of programs.

    — Gerald Weinberg, The Psychology of Computer Programming, Chapter 1

    The meme that programming is a write-only skill is one that recurs from time to time. With relatively little software these days needing to be highly optimised, and developer time orders of magnitude more expensive than hardware, the dictum that software should be written primarily for humans to understand, and only secondarily for machines, is truer than ever. The context, and examples, in this book are rather quaint and almost humorous now (like noting that now that programmers actually work at a terminal they can just see what code does rather than having to read it offline).

    But there is a great psychological point raised here too that I’ve never heard anyone talk about before and still holds as true today. Often in a software project, things are implemented in a clumsy, awkward, or otherwise non-standard manner. A lot of time this is because the programmer was unaware of the better way to do things, or needed to get on to working on other things as soon as the code “worked”, without having time to tidy it up. But sometimes there was as a good reason for the approach at the time it was written that is no longer true now (to work a limitation in a library being used that has long since been fixed, for example). If it’s in a relatively stable area of the codebase, it can languish there in that form for many years, until one day, needing to make a change nearby, a junior programmer will come in, see what to them is a needlessly complex part of code and congratulate themselves for knowing more than the programmer who originally wrote this nonsense. It’s not unusual, however, for that other programmer to now be their boss, and subtly contribute to building an unhealthy relationship there.


    Computer Programming as a Human Activity

    This book has only one major purpose—to trigger the beginning of a new field of study: computer programming as a human activity, or in short, the psychology of computer programming. There are, by various estimates, hundreds of thousands of programmers working today. Each of them could be functioning more efficiently, with greater satisfaction, if he and his manager would only learn to look upon the programmer as a human being, rather than another one of the machines.

    At the moment, programming—sophisticated as it may be from an engineering or mathematic point of view—is so crude psychologically that even the tiniest insights should help immeasurably.

    — Gerald Weinberg, The Psychology of Computer Programming, Preface

    This book was originally published in 1971. A decade ago there was a “Silver Anniversary Edition” published with additional commentary by the author from a perspective of 25 years on, but I don’t have that version; here I’m working from the original text.

    There are very few computing-related books that are still relevant almost 40 years on. Hardware and software have changed beyond recognition multiple times, with the steady drive of Moore’s Law leading to computers that are a hundred million times more powerful. Many of today’s young programmers can barely conceive of a time before Google was the first port of call when something went wrong, never mind when computer time itself was so expensive that you had to do all your programming on paper, and, when you were ready, give it to an operator who would load it in for you and let you know the result! At the time this book was written, the debate was still raging over whether the new fangled approach of letting programmers actually work directly at the computer led them to grow lazy and adopt careless and inefficient work habits.

    However, although the technical references in this book are often so dated they’re almost unintelligible, the observations on the human side of programming are still scarily accurate. Update the code snippets from FORTRAN to Ruby and the casual reader wouldn’t even realise for large chunks of the book that it wasn’t written last year. The reviews of the Silver Anniversary Edition seem almost to think this is a good thing, as it means the book is still relevant. To me it’s a hugely scary thing. How can we have learned so little in forty years? We should be looking back in horror at how programming was managed then, and the stories should sound as archaic as the technology.

    In many ways, then, this book was a failure. The psychological aspects of programming are still poorly understood. Weinberg himself has developed many of the ideas much further in later works (such as the excellent Quality Software Management series), but these are even less widely read. But that doesn’t mean it should be abandoned. It’s every bit as important now as it was then, and the underlying promise quoted above still holds true: “even the tiniest insights should help immeasurably”.


    Nothing Happens Until a Sale is Made

    Thomas Watson Sr. was one of the extraordinary people in business history. The company he created – IBM – is testimony to his exceptional capabilities as an entrepreneur, visionary, and manager.

    Interestingly, when people think of the creation of IBM, and the global behemoth it became, their thoughts turn first to the company’s technological prowess. Although technology is certainly important to the IBM story, it was not really the most critical driver of the company’s growth under Watson’s tenure. The great man himself recognized that when he made the remarkable (for its insight and simplicity) observation – stated in a number of ways to IBMers – that nothing happens until someone sells something

    — Mark Stevens, Your Marketing Sucks, Chapter 2