I remember providing some programming puzzles to students to solve as part of an assignment. One asked: "Can we assume the inputs will be valid?" My response was "What do you assume when crossing the street?"

That sounds tongue-in-cheek. Everyone knows to look both ways before crossing a street.

Right?

The next time you are in a densly populated area, take a few minutes to make some observations. Where are people looking? The pedestrian light? Other travelers? Do they look both ways before crossing a one way street? What about other potential hazards? Make sure you out for dangers yourself before attempting this exercise.

The blindspot I'm talking about isn't only for cars, pedestrians, and cyclists. Its a blindspot of methodology. It commonly goes like this:

1. Create a hypothesis (the road is safe to cross)

2. Set up the test (look at the light)

3. Make an observation (pedestrian light is on)

4. Observation does not conflict with the hypothesis

5. ! Confirm the hypothesis (safe to cross)

We can repeat steps 2,3, and 4 over and over again to be more sure. Look left, look right, look up for overhead workers, look down for potholes, check the pedestrian lights, check the traffic lights, listening for bicycle bells or sirens. This reduces the scope of doubt in favor of our hypothesis, but never confirms it.

Eventually, we'll need to cross the street.

Building is an exciting discipline, because we hypothesize, test, observe, and act in rapid succession as we build and utilize our tools. And just like crossing the street, we cycle through these phases quickly and unconsciously to navigate uncertainty in the world as best we can. And that means many ways to mess up.

Here are some equivalents that you, or your team, will inevitably run into:

• Assuming inputs will be valid
• Assuming your piece of code will execute when you think it will
• Assuming your functions work because they pass the test cases
• Assuming your functions don't work because they don't pass the test cases
• Assuming your tests are set up with the correct assertions
• Assuming your test cases have coverage of potential issues
• Assuming that others will read your documentation, and call your code as intended
• Assuming that others will use the results of your code as you intend for them to

Many coding fiascos I've encountered were the result of one or more of the above incorrect assumptions. As we've seen on the street, we can be lax about our processes even when our safety and wellbeing is at risk. So why should we expect anything else? What should we do?

Many will point the finger at the pedestrian, or the builder at their folley. Asking everyone to be perfectly rational is not perfectly rational. We know such blindspots exist, how can we adapt our process and design for it?

Here's an idea: Our pedestrian signals ask users to look away from traffic to gauge their safety. Here's a modification: include a reminder as a parabolic mirror to where the important information is, and have the walk signal point directly to it.

When I train new developers to build or upgrade their debugging skills as part of a workshop: pointing out these assumptions and processes is often one of the first steps. Developers that recognize the inevitability of mistakes make fewer of them, catch them quickly, and with less severe impact to their projects.

When the process of errors is better understood, then we can start to design around it.

• Acknowledge that mistakes are a part of the process
• Anticipate your test results
• When encountering an issue, try to backtrack with the following:
• Log your test results
• Log your assumptions
• Check your passed tests for false positives
• Check your failed tests for false negatives
• Make as few assumptions as possible when others are involved

This post was motivated by a chapter "To Err is Human" of one my favorite books, The Design of Everyday Things by Don Norman.

 Banner photo Chris Barbalis on Unsplash

 

This writing was last updated Oct 20, 2025. It is part of a larger series of reflections, and how they continue to shape my journey as a builder and educator. It is also an effort to bring humanity back into the online world. No AI was used in this piece.