I know exactly what you're talking about I think. My problems are solved by code such that code will have something to do with the approach. With that in mind I

I know exactly what you're talking about I think. My problems are solved by code such that code will have something to do with the approach. With that in mind I tend to write lots of little one off programs to test a particular idea or see if a particular phenomenon exists in a set for example. In building these I'll version them in the filename ( XXX_Test_V1.sh ) such that I can compare runs and later maybe chain some runs together. The point here is just to get moving in some direction, get familiar with your data and start testing some assumptions. I learned a lot about my problem from doing this and eventually came up with some testable theory. Forget architecture, "elegant code", time complexity, "does it scale" etc - just write things that give you answers or allow you to gain some insight and do so with the minimum of effort spent on design. If you ever find yourself onto something you can refactor then. For me the main thing is to get the learning process started.