What happens when you press a key in your terminal? Noting that terminals act like 1970s hardware devices, Julia Evans digs into what is actually “sent” when you press things like Ctrl-C.

A list of Post-mortems! Dan Luu’s collection of links to post-mortem write-ups, categorised by the domain of the thing that broke.

Every Friday I post a video related to one of the themes of this site. This week it’s John Romero at GDC Europe talking about the the programming principles of early id Software.

n the 1990s, during a hyper-prolific period where they released 28 games in less than five years, id Software’s policy for bugs was to drop everything and fix them as soon as possible. The result was a track record of games that were technically innovative, genre defining, and of undeniably high quality.

In this 2016 talk John Romero discusses the 11 principles that contributed to that remarkable run:

1. No prototypes - the code is the game so polish now and maintain quality
2. Fallbacks on load failure - keep the game runnable and resilient to errors
3. Simplify - remove complexity wherever you can
4. Focus on tools - spend time making tools good as they help make a great game
5. Don’t rely on testers - as in test your stuff yourself and don’t waste people’s time on buggy code
6. Fix bugs immediately - fix bugs so they don’t cause more bugs
7. Target less powerful systems - your dev computer should able to make your game fly
8. Don’t write code for future projects - You’ll write better code when you need it
9. Write modular code - encapsulation aids good design
10. Code transparently - talk about how you’re going to solve your problem and ask for feedback
11. Embrace differences in programmers - the output matters more than minor differences in coding styles

Vicky Boykis looks back on two years and Automattic and Tumblr

Making something work and run for other people is one of the greatest joys you can experience as an engineer. The second greatest joy is having Jenkins turn green on the first deploy.

Sometimes you will have to explain the same thing to multiple people and sometimes to the same people in different ways, and sometimes, also, even to yourself in different ways. This is where writing and documentation helps a lot. It’s not just for others. It’s for you to clarify and explain your thoughts.

In order to continue to grow as an engineer, you need to ship either systems that impact more people (wide), or systems that are tightly scoped but more complex (deep). There is no other way to grow.

Software Lead Weekly is a useful newsletter that covers coding, people, culture, and management.

Every Friday I post a video related to one of the themes of this site. This week it’s a talk about how to make big games.

At the D.I.C.E Summit in 2002 Mark Cerny presented his Method for successful game development. Around the same time that the orignal signatories of the Agile Manifesto documented the principles that they had discovered while making software, Cerny described something very similar and more concrete. He deliberately splits the pre-production and production processes of game development, because 1) they have two different outputs - a game design and then a game and 2) require different ways of working - pre-production is learning and prototyping, production is putting that learning into action. As Cerny puts it, production is easy, but pre-production is hard. Along the way Cerny busts many myths about development - planning, technology, milestones etc.

Twenty years later there is still a lot to learn from this talk.

Slides for the talk are on Slideshare

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.