A few years ago I had a job where every new recruit would go through a long process of shock and gradual acclimatisation to the main software product.

What it did doesn’t matter as much as how it was built: it was an application developed on top of a proprietary programming language and user interface designer. The reaction was always the same. Why? Why?! Why would you reinvent Visual Basic on Unix? Why would you inflict a programming language even worse than Basic on developers?¹

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 grating¹.

The whole team got this email today. Okay, it wasn’t today and these are not the exact words, but it was something like this:

We have a serious regression in build 456. We have set the project back rather than taken it forward. We need the utmost focus and commitment on fixing it. We’ve broken it and we stay in the office until it’s fixed.

I’ve had a few of those messages over the years and while it’s intended to focus minds it often has the opposite effect. Let’s examine why.

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?

I made the mistake of suggesting that there was a blog to be made from this tweet. This is that post.

People still underestimate the value in (Developer|Operator) Experience when building platforms and honestly it’s kinda shocking to me.

If you want to win mindshare you need to make your tools actually usable. If you don’t want to lose it you need the same.

## “If you convert [your car] to run on copies of this book instead of gas, it will burn through 30,000 words per minute, several dozen times faster than the word consumption of a typical human.”

If you thought that “How to“, the follow-up to “What if…” would be more practical, then you’d be wrong.

Whether it’s chasing a tornado without getting up from your couch or moving your house with jet engines, Munroe takes another fun, inventive journey through science and maths. While it doesn’t quite hang together as well as “What if,” it still manages to amuse, educate¹ and entertain.

• The Myth of Japan’s Failure – “Japan has succeeded in delivering an increasingly affluent lifestyle to its people despite the financial crash. In the fullness of time, it is likely that this era will be viewed as an outstanding success story.”
• Man Embraces Useless Machines, and Absurdity Ensues – Technology: making life simpler.
• Merry – Sat here with my newborn son and wife, with all my family staying nearby, this post rang bells. It’s sometimes important to realise what you have.

• Fukushima is a triumph for nuke power: Build more reactors now! – Despite multiple failures there has been no significant release of radiation.
• Japan Earthquake: before and after – Amazing and shocking.
• Why I am not worried about Japan’s nuclear reactors – I did think that the coverage suggesting a nuclear disaster was unlikely. This explains why my intuition was (probably) right.

• Nov. 10, 1999: Metric Math Mistake Muffed Mars Meteorology Mission – Sometimes the simplest of mistakes have the most dramatic consequences.
• Linotype: The Film – The revolution in printing before DTP… soon in documentary form.

“Do you ever change this type of trade?”

I was sat on the trading floor discussing a new feature that I was implementing with the person who would be using it the most.

“No, never.”

This was one detail of the change that would have far-reaching consequences in the code. A “no” would mean a few days of development, a “yes” would indicate several weeks.

“Are you absolutely sure? You don’t change it even once a month?”