"We make mistakes often, we plan for it and we adjust to it. If you don't make mistakes you never do anything new."
- Pete Doctor (director of Up and Inside Out, writer on Toy Story and Wall-e)
This quote resonated with me because I make a lot of mistakes. Or maybe I should say I like taking chances. Finding a new and better way of doing something, innovating, and exploring are all exciting and creative.
This article is about refactoring by the way. If you're not a developer then ignore this and skip to the next paragraph. I'm hoping the ideas here are applicable to programming but general enough to be interesting to non-geeks as well. Refactoring didn't used to be a word...we used to rewrite or rework a program. But refactoring is a good word to have in our vocabulary, with its implication of improving, rethinking and intention.
There are certain tasks that do not lend themselves well to taking chances and making mistakes. Surgery is an example, building a bridge is another. We can rarely make big mistakes in those tasks and try again. (Though even there, the best new discoveries have often been through happy mistakes or lessons learned from unhappy mistakes.) Programming, however is another story. We don't build a program once...we build it over and over. As often as possible in fact.
There are concepts and tools that help you make mistakes and recover from them. Unit testing is probably the most important. Test driven development lets you safely try out possibilities and immediately know if you've succeeded or failed.
Continuous build is another. It tells you how well your changes are interacting with other people's changes. It helps keep you from making really big mistakes.
I'm a lazy programmer. I recognize this...in fact I may be a good programmer because I'm lazy. I will spend hours looking for a way to make things a little easier. Watch out for programmers who like working. They will make work for themselves at the cost of consistency.
Also watch out for programmers who do too much work up front. They will write code that covers every possible event...which is great if you are sending your code to Mars with no way to update it. Otherwise you end up with code that is overly-complicated, prone to bugs and worst of all, difficult to refactor. Make the code do the minimum, then figure out where things could go seriously wrong and test those cases.
Once you've created your code and gotten it working, set aside time outside of the scope of your sprint/waterful to look at your code, make sure it's doing everything you expect and look at refactoring it to make it:
1. Clearer
2. More reusable
3. More robust
4. Faster
I'm a lazy programmer. I recognize this...in fact I may be a good programmer because I'm lazy. I will spend hours looking for a way to make things a little easier. Watch out for programmers who like working. They will make work for themselves at the cost of consistency.
Also watch out for programmers who do too much work up front. They will write code that covers every possible event...which is great if you are sending your code to Mars with no way to update it. Otherwise you end up with code that is overly-complicated, prone to bugs and worst of all, difficult to refactor. Make the code do the minimum, then figure out where things could go seriously wrong and test those cases.
Once you've created your code and gotten it working, set aside time outside of the scope of your sprint/waterful to look at your code, make sure it's doing everything you expect and look at refactoring it to make it:
1. Clearer
2. More reusable
3. More robust
4. Faster
