I recently read “The leprechauns of software engineering” by Laurent Bossavit ¹. The book goes through a few myths about software engineering and then traces how those myths entered the public consciousness. It was well worth reading for anyone interested in research based software engineering practices. It was primarily useful on how to verify about claims rather than the claims themselves. While I’ve heard of most of the myths - I also heard about them as myths rather than as true claims. It reminded me a lot of “Making Software” ². Core Insights:

People pay attention to high value communication channels. These give them information about the job, hobby, etc. Since people pay attention to these channels, they get used more. Eventually they get used for something more borderline or inappropriate for the communication channel. When this happens people stop paying attention to the formerly high value channel and shift to new locations. Eventually the original channel is useless. Rinse and repeat for the new communication channel.

I recently watched a video on mistakes investigators make in accident investigating. It was worth watching but because its video it is difficult to skim or remember. This blog post is to make it to write down what I learned in a textual format to make it easier to find and remember later

This is the video:

The three mistakes were

When a piece of code is first written it easy to maintain quality. However, several things contribute to loss of quality.

New and unexpected requirements may happen. This may violate the initial layering rules. New people may join. Newer people know less and then make more local changes. This results in global invariants becoming local invariants.

Chesterton’s fence is a curse here and one of the reasons that documentation is so important.

Some bugs are interesting. Others are annoying. Some are fun. Some are just impossible. Many bugs are confusing. Others are annoying. Some are just impossible. This is a list of those bugs:

1. MRI disabled every 1iOS device in facility

2. We can’t send mail more than 500 miles

3. OpenOffice.org can’t print on Tuesday 1see comment 28) 4. I can’t log in when I stand up (and 1another similar story)

4. A story about “magic”

One habit I’ve started at work is called “slack to wiki”. Whenever I learn something new, or explain something to someone else, I try to document it on our internal wiki quickly and in a low effort way. If I come back to the topic again in the future I’ll modify the content and make it actually good.

This forms of a knowledge base which can grow, and also lets me reference past topics in future conversations more easily.