Measure Once, Cut Twice

So I was thinking about how I go about solving problems. In many cases the consequences of a solution are non-terminal. That is, a software problem can often be solved without doing any real damage. I'm not talking about production hot fixes here, or doing things in a mission critical environment, but rather on your workstation or in a development environment. 

As it turns out, you can try anything you want and do little or no harm. So rather than be exacting, you should just try it. You can always roll back the change. You can always make a backup before doing something risky. You can use a REPL to test out ideas. So rather than spending a bunch of time picking through the details of risk, just go for it. Worst case you restore the database or file or hit Ctrl-C. Best case, you've found a solution. 

If you do find a solution, learn from that solution and decide if the solution is good enough. That is, it might be super hacky. Or it might consume huge quantities of RAM and therefore isn't viable on your target platform. But you can learn from what you did; even if what you learned was that it isn't a good idea.

If your solution doesn't solve the problem, you can probably still learn from it. You can learn more than 'this didn't work' you can also learn that it was inefficient, it uses lots of RAM, its slow, it talks on the network too much etc. 

The faster you execute these experiments the more you can learn and the sooner you can get a problem solved. But I'm not suggesting you do this blindly. You should spend a few minutes at least thinking about a proposed solution. I suggest that if you have an idea and no idea how to implement it, move on to the next idea. But if you kinda know how to solve the problem then try it. No real damage can be done. 

Of course the cautionary part of this is to not let yourself obsess over a possible solution. You need to know when to quit and try again. Once upon a time I had what I thought was a good idea for bootstrapping a system, and I became obsessed with it. It was long and laborious and in the end it didn't work out. I spent way too much time trying to force a round peg into a square hole and I should have given up sooner. But I did learn something, actually a number of things; most important, don't try to force it, it should be smooth, easy, and understandable.