One of the things I've been committing to doing every day is to either take a walk or to go on a bike ride. The goal is to generally get out of the house and to escape the challenge of working from home and to never put on pants.

I love riding my bike, it's a pretty mindless exercise. I get to pedal like hell, wheel down 30-40 km and get some good exercise. But overall, it's still an exercise that requires my attention to avoid hitting pedestrians, cars and other objects. I rarely get a free mind to let my thoughts flow and to think about things that come to mind.

This is where walking comes in.

Working at a standing desk already gives me the feeling of having more freedom to step away from the computer, to think about a problem as it comes up.

But walking is different. When I leave the house, the first couple of minutes feel like a lot of noise in my head.

After that, things are starting to slow down. Rather than be there all at once, some thoughts just flow naturally from one to the next, giving me time and peace of mind to actively think about them.

Getting to that stage requires a longer walk for me, I can't just walk to a shop and back.

The same is true for talking to someone. The peace of mind helps to talk things over, to get away from distractions. I found that it's nicer to walk and talk than to just sit.

This is even backed by studies now. A recent Standford study found that walking helps foster creative thinking.

If not for exercise, as a creative worker, that alone should give you enough incentive to step away from your computer, to step out of your car, and to just walk. To get the most out of it, leave your phone at home. Fewer distractions make for more time for your mind to wander.

You should try it, you don't even need a Fitbit, just start walking. It may just make you a happier person too.

I've been reading "Thinking, Fast and Slow", which is an interesting exploration of how the mind works. The book introduces two systems that make up how we think.

One is fast and intuitive, it's effortless to use. It monitors our surroundings, processes data, finds possible correlations, letting us draw quick conclusions.

The other is slow and requires effort to work with. It's the one that empathy requires us to use, for instance. When we need to really think about a problem, contemplate something another person tells us, this system is being used.

Two quotes in the book struck out at me:

A reliable way to make people believe in falsehoods is frequent repetition, because familiarity is not easily distinguished from truth.

This one as well:

When uncertain, System 1 bets on an answer, and the bets are guided by experience. The rules of the betting are intelligent: recent events and the current context have the most weight in determining an interpretation. When no recent event comes to mind, more distant memories govern.

Here's the last one:

The confirmatory bias of System 1 favors uncritical acceptance of suggestions and exaggeration of the likelihood of extreme and improbable events.

I've been contemplating how this explains our behaviour in stressful situations in particular, during a production outage, for instance.

The three quotes play quite well together, and they do make sense if you're familiar with handling an outage situation.

When something is broken, we tend to look at metrics and logs first to find something that strikes out at us, unusual patterns. We look for patterns that match previous experiences, and if we see any of those patterns, we tend to be quick to draw conclusions based on the patterns and the previous experiences.

Confirmation bias is the name for this phenomenon, presenting an interesting challenge for more than handling production outages. Given that System 1 is the one that drives our initial impressions of any situation, it seems impossible to overcome.

Another quote from the book:

System 1 is highly adept in one form of thinking — it automatically and effortlessly identifies causal connections between events, sometimes even when the connection is spurious.

Sometimes we come across scenarios that we find an explanation for, but it may not even be the correct one. When we run into this scenario again, drawing the same conclusion requires less and less effort, as our system 1 is quick to recognize the pattern and give us a solution, even if it's the wrong one.

Repetition of events and our own conclusions, as false as they may be, only ends up to us believing the falsehood even more.

Your beliefs, and even your emotional attitude, may change (at least a little) when you learn that the risk of an activity you disliked is smaller than you thought.

When you put these things together, they can form a provoking thought. I've been writing about practical drift recently. According to Scott Snook in "Friendly Fire", practical drift is the slow steady uncoupling of practice from written procedure.

Suppose you run into an incident you haven't seen before. It's been an unknown risk until then, and in turn, you didn't know what the potential consequences were, or you misjudged the risk of this particular scenario.

It did happen, the incident had a certain impact, and you learned some of the contributing factors and signals that helped you identify the problem. They're now your freshest memory of a recent incident.

The next incident with similar signals is sure to guide you into a similar direction, as that's the influence of the System 1.

As these issues continue to come up, possibly untreated, unfixed, you and your organization get used to the signals and the incident itself. There's now an unwritten procedure on how to handle this particular situation. In the worst case, someone gets an alert, ignores it, thinking "It'll clear."

This is where you slowly and collectively drift away from your initial assumption that this kind of incident is risky. System 1 continues to help you to identify the patterns and come up with the solution. It worked the last time, right?

It's fascinating that, when you look at practical drift from this perspective, it seems inevitable.

Tags: ops, humanfactors

We're now more than two years into building, maintaining and growing the code base for Travis CI. A lot has happened in the code base, especially in the first year of our existing as a company. Lots of code was moved around, refactored, changed, improved, or written from scratch.

While Travis CI is overall simple, some part of the code relies on complex logic, in particular handling everything in and around the state of a build.

The more the code's been touched, with new states being added, the harder it's been to follow along why it was changed.

Most classes have some coverage with comments, but code comments have one distinct flaw. While code changes frequently, its comments rarely do.

My first reflex when looking at a piece of code, wondering why it is the way it is, is to look at the git history. While git blame has an unfortunately negative connotation, it does provide the basic clues as to where to look for the answers.

Thankfully, in Vim, :Gblame (courtesy of fugitive) provides a good way to start digging.

This is where I changed the way I write and commit code in the past couple of month. I think about future me, future anyone who looks at my code, thinking what the hell is going on here and why?

When they look at a commit message no longer than some 50 characters and a code patch, will they be able to figure out what's going on, why I made this change?

Knowing present and past me, I know they don't. Things are easily forgotten, and a year later no one will remember why something was changed.

For these future mes and someone else, commit messages are the one true history of why a piece of code has changed and how, by way of the diff.

Nowadays, I add detailed commit messages to even the smallest changes. As soon as they touch something that affects the bigger picture or has some reasoning outside of what's visible in the code, the commit message should reflect that.

It turns into a diary of what you've been up to, and it's going to help yourself and everyone else looking at your code.

Write good, clear and detailed commit messages. Future you will thank present you for it.

Mislav has a lot more detail on the commit history as the ultimate truth for a code base's timeline, it's good stuff.

Tags: git, development