# The mistakes along the way

Discuss making mistakes, how to best make mistakes, and the best ways to learn from those mistakes

## Whoops!

It's bound to happen. Something that you thought was good didn't work the way you planned and now you're realizing that you've made a terrible error. Sometimes it's something that could have been avoided (committing in code that was meant for debugging for instance). The ones that really frighten me though are the ones that I did not expect at all. It's the side-effect from using a module in a way that you later learn wasn't intended to be used that way. It's the realization that this small module will be part of a larger module and your code isn't designed to make a smooth transition.

Programmers make mistakes. The nature of our jobs requires us to be aware at all times of what is going on in multiple sections of code and no matter what safeguards we put into place we lose track of the state of our program and committed code. We rush and rely on muscle memory to pick up the slack. We deny ourselves areas where we can adequately test code because we feel we need to get things done sooner.

We panic and when we panic we make mistakes.

## Avoiding mistakes

Let's be clear: there's no way to eliminate mistakes. Software is too complex to be completely bug free. But what we can do is create places where we can tease out as many bugs as possible from the code before we put it out in front of others. When we have the ability to debug and test our code we get to better places of understanding what the code is doing and how it behaves under certain circumstances. Creating a model environment of the target system allows us to test our code against what we think the target system will do and how it will behave.

We put a lot of emphasis on avoiding mistakes, both in programming and in programming culture. There are horror stories told of how a small bug in a program caused enormous pain for those involved. The morals of the story tend to illuminate that a simple mistake can be a costly mistake and we need to be more diligent about avoiding mistakes. All these tales do is make programmers more paranoid about making any mistakes. And when we operate in a fear-based mode we begin to panic. Telling programmers to make no mistakes is akin to telling someone not to be afraid - they then become afraid of being afraid.

The only way we learn is by making mistakes. When we deprive ourselves of making mistakes we deprive ourselves of the opportunity to make mistakes. That doesn't mean we have to make every mistake that other developers have made before us (that would be a lot of mistakes). But we need to make our own mistakes in order to keep learning and to figure out where our gaps in understanding are. 

## Making a model

What we need instead are areas where programmers can set up environments where they can safely learn from their mistakes. We need areas where developers can feel OK about trying new things. But we also need an area where developers can test those changes and ensure that they don't have other rippling effects on other code.

We also need environments that model the target system. They need to be as close as is practical to those target systems. That doesn't mean you need to make exact copies of expensive production environments, but you do need to make models of production environments that test enough of the pieces your code will come in contact. That also means keeping this model updated as systems change.

Again it doesn't have to be perfect - it's only a model. But it does need to be close enough where your code will behave in a similar fashion between the model and the target environment.

## Learning from failure