## Whoops!
-It's bound to happen. Something that you thought was a good idea 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 easily avoided (committing in code that was meant for debugging for instance). Sometimes it's a cascade of errors, each piling on the efforts on the previous error. There's the side-effects of using a module in a way that you later learn wasn't intended to be used that way. Or it's the realization that you've designed a small module and later realize that module will be part of a larger piece of software and your code isn't designed to make a smooth transition. Whoops!
+It's bound to happen: something you thought was a good idea didn't work the way you planned and now you realize you've made a terrible error. Sometimes it's something that could have been easily avoided (committing code that was meant for debugging, for instance). Sometimes it's a cascade of errors, each building on the efforts on the previous error. There's the mistake of neglecting the side-effects of a module when it's used in a way that wasn't intended. Or it's the realization that you've designed a small, tightly coupled module only to learn that your module will be part of a larger piece of software and your code isn't designed to make a smooth transition. Whoops!
-The ones that really frighten me though are the ones that I did not expect at all where the unintended consequences run rampant throughout the system. Those sorts of errors keep me up at night.
+The mistakes that really frighten me though are the ones that I did not expect; the ones where the unintended consequences run rampant throughout the system like a chain-reaction. Those mistakes keep me up at night.
-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.
+Programmers make mistakes. The nature of our jobs require us to be aware of what is going on in multiple sections of code. We lose track of the state of our program and committed code. We try to pepper our code with comments and reminders of what's going on in a section of code but comments become stale and add to our distraction. 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 in a safe environment we can better understanding what the code is doing and how it will behave under certain circumstances. Creating a model environment of the target system allows us to test our code against a miniaturized version of the target system's reality and see how it behaves under those conditions.
+Let's be clear: there's no way to avoid or 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 from the code as possible before we set it in front of others. We can better understand our code and what it's doing when we have the ability to debug and test our code in a safe environment. We can see how it will behave under certain circumstances. Creating a model of the target system allows us to test our code against miniaturized versions of the target system's reality and see how it behaves under those conditions.
-We put a lot of emphasis on avoiding mistakes, both in programming and in programming culture. There are horror stories of how small bugs in a program caused enormous pain for those involved. The morals of those stories illuminate that a simple mistake can be costly and we need to be doubly careful about avoiding mistakes. All these tales do is make programmers paranoid about making any mistakes at all, and when we operate in a fear-based mode we begin to panic. Telling programmers to make no mistakes is similar to telling someone not to be afraid: they become more afraid of being afraid.
+We put a lot of emphasis on avoiding mistakes, both in programming and in programming culture. There are horror stories of how small bugs in a program caused enormous pain for those involved. The moral of these stories illuminate that simple mistakes can be costly and we need to be doubly careful about avoiding mistakes. These anecdotes are told in the hopes that they'll somehow scare developers into being more cautious, but they can have the opposite effect. They can make programmers paranoid about making any mistakes at all, and when we operate in a fear-based mode we begin to panic. Telling programmers to make no mistakes is similar to telling someone not to be afraid: they become more afraid of being afraid.
-The only way we learn is by making mistakes. When we deprive ourselves of the freedom to make mistakes we deprive ourselves of the learning opportunities in making those 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). Nor does it mean that we need to introduce chaos into our development process in order to learn better. What it means is that we need to make our own mistakes in our own way in order to keep learning and figure out where the gaps in our understanding exist.
+The best (and perhaps only) way we learn is by making mistakes. Learning by making mistakes is an effective way to allow us to be curious and see what caused the program to fail. When we deprive ourselves of the freedom to make mistakes we deprive ourselves of the learning opportunities in making those 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). Nor does it mean that we need to introduce chaos into our development process in order to learn better. What it means is that we need to make our own mistakes in our own way in order to keep learning and figure out where the gaps in our understanding exist.
## Making a model
-We need an environment where programmers can safely learn from their mistakes. We need areas where programmers can feel good about trying new things. We need to have places where developers can try out their ideas and not have those changes ripple to other unrelated systems. This is the best way that developers can learn and be brave in their learning process.
+We need environments where programmers can safely learn from their mistakes. We need spaces where programmers can feel good and confident about trying new things. We need places where developers can try out their ideas and not have those changes ripple out to other unrelated systems. This is the best way that developers can learn and be brave in their learning process.
+
+#### FIXME
These environments must model the target systems, and they must 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 have models of production environments that test enough of the pieces your code will come in contact. Having models that mirror production systems means you'll be less likely to introduce changes that have unintended consequences. You'll give yourself some comfort in knowing that the changes you enact in these models will be the same changes that will appear on the target system.
projects / themediocreprogrammer.git / blobdiff