In the late 90s I was on the helpdesk at Toniq. We made dispensary and point of sale software for pharmacies. One day a pharmacist rang up about a “big red box on the screen.” He said he wasn’t sure what he should do next.

I asked the pharmacist to read out the text and it turned out that he had triggered a new feature we had added: when a patient was prescribed a combination of medicines that had an adverse interaction, we would alert the pharmacist so they could advise their patient on the correct course of action. I explained the feature and the pharmacist said it would be helpful. Then he asked me a question that I didn’t expect: “So, should I dispense it?”

For years I would tell this story and laugh about how dumb my customer was. But I was wrong and that wasn’t fair.

We tell our customers that the software we make will help work faster, will let them make better decisions, will steer them in the right direction. And people, naturally, imbue software with authority, likely more than we intend.

It’s up to us to make sure that we understand that authority and are careful with how we exercise it. We’ve all heard stories of people driving through the wilderness or getting stuck at the top of a mountain because their GPS software told them it was the shortest path. We all laugh at the drivers, but, really, those problems are software failures and developer failures.

So next time when you’re designing workflows, writing copy for messages, or implementing a feature, ask yourself: what could go wrong and am I relying on the customer’s common sense to prevent it? If you are, take steps to ensure your customer can’t do the wrong thing.

Every Monday I’ll try and post links to articles or videos I’ve found interesting and useful. Today’s links are tenuously held together by Rails.

The Optics of Pair Programming is an insightful post by Eric Bailey on pair programming and the aspects of context and culture that make it successful or a working hell.

I heard about Eric Bailey’s post on The Bike Shed podcast, a consistently good listen, and my main way of keeping up with the Rails ecosystem. This week’s episode touched on how enforcing opinions in linters can lead to less readable code, especially in tests. I was reminded of this classic comment from John Carmack, looking back on an email he’d written seven years before:

The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).

My first ever Rails project was Digital NZ. I was lucky work interact with folks from the National Library, including Courtney Johnston, who is now Tumu Whakara at Te Papa. Courtney recently revived her blog where she writes about art, culture, books, and all sorts of other things. It’s well worth adding Courtney’s blog to your feed reader.

‘Accessibility and the Web’ sounds like a thoroughly modern set of challenges, but it includes problems that people have been trying to solve for hundreds of years.

In mediæval times, a knight being able to recognise a friend or foe at a distance was a matter of life and death. Rules evolved around the coats of arms they bore to make identifying each other easier, giving birth to the science of heraldry. The most important one of those rules is around colour contrast.

My buddy Nick Piesco talks about why colour contrast is so important to accessibility, and he takes us on a whirlwind tour through the history of heraldry before showing how rules that originated on the tournament ground inform our best practices here in the 21st century.

This is a shorter version of Nick’s talk. The slides for the full talk are on Speaker Deck.

August marks the 40th anniversary of the publication of The Warlock of Firetop Mountain, the first volume of the Fighting Fantasy series which combined elements of table-top roleplaying games and Choose Your Own Adventure style books.

Firetop Mountain is notorious for its maze. I spent many hours as a child trying to map that maze and somehow fluked my way out of it. I’ve also “played” Firetop Mountain with both of my children. My son gave up in the maze. My daughter and I got through it and even killed the Warlock, but didn’t get any treasure. I think I put them off RPGs for life.

What has this got to do with programming or continuous improvement or engineering management? Good question! I’ll get to the point.

I follow Rands’s advice in Bored People Quit: “don’t forget what it’s like to build a thing.” So I’ll try to spend some time building little things with different tools, either learning something new or improving and building on what I already know.

I’ve been curious about the Twine, a tool for making interactive fiction. How complex a gamecan you make? How hard is it to do something more than just Choose Your Own Adventure style games? I decided to have a crack at implementing the combat found in Firetop Mountain.

Continue reading →

Every Monday I’ll try and post links to articles or videos I’ve found interesting and useful. Today’s post is mostly about explaining things.

Dave Farley reviews Team Topologies.

Team Topologies is important, and adds a significant piece to the jigsaw puzzle of how to build great software.

Simon Willison asks GTP-3 to explain code and finds it to be “shockingly effective”. Willison’s examples include Python, Javascript, creating tables and querying them with SQL, a config file, and mathematical equations. If you’ve ever looked at your own code and wondered “what was I thinking?”, AI might be able to tell you.

That said, Willison notes that GPT-3 doesn’t actually “know” anything, it’s just really good at looking like it does, and we should keep that in mind before asking GPT-3 something like “which is better?”

Once again, I’m reminded that tools like GPT-3 should be classified in the “bicycles for the mind” category. You still have to know how to pedal!

They’re fantastic tools for thinking, but to actually use their output effectively requires VERY deep knowledge—both of the subject matter in question, and of the way that the AI tools themselves work.

Also Simon Willison in the b3ta newsletter:

Using these AIs feels more like spellcasting than programming: no-one, not even the creators, fully understands how they work or what they can do and you get better at them by accumulating weird new incantations that might lead to better results. Or unleash demons if you type something wrong.

And speaking of explaining things, Julia Evans has some excellent advice on how to avoid confusing folks when you’re trying to explain technical things.

[…]knowing that I’m likely to accidentally do these things makes it easier for me to avoid them, and it makes me more receptive to critique when people point out issues with my writing (“Julia, this is assuming a lot of knowledge that I don’t have!“).

Being aware of these patterns also helps me when reading a confusing explanation: “oh, I’m not confused by this explanation because I’m stupid, I’m confused because it’s introduced 6 new-to-me concepts and it hasn’t explained what any of them is yet!“.