194

After a while away from it, I returned to development and programming this week. That inevitably lead to trying to figure out what the hell it was I was doing. I find that going back to old code is like trying to read the mind of a completely different person, and that person is an idiot.
Even with good comments and careful organization it usually takes a while to get back into my previous headspace. This time, like so many others, I went through the code and when I finally figured out how it all worked, I wondered what would ever have made me think that it was the best way to do things. This leads to a disassembly of the old procedures and routines, and a replacement with a much simpler, much more stable versions that accomplish the same thing. Of course the old version worked too, just not as well and less elegantly.
So there is the problem. I have heard time and time again never refactor code until it is feature complete. I can see the value in that. Why fix what isn’t broken. I’m not really a programmer, and I haven’t learned, or been taught, why a lot of best practices became best practices. There are probably some very good reasons why the notion of never refactoring is so pervasive.
I am a sculptor though, and I have found that if the skeleton of your work is weak, no amount of polish will ever correct those problems on the surface. If the structural forms of a model or drawing aren’t solid, it will never turn out as well as you would like.
I think that either programmers and artists just approach problems differently, or the idea of holding off on refactoring has been grossly overstated. As a sculptor or fabricator, I will likely to continue to work on creating a strong base, since it seems to be serving me well in the artistic field.
This is one of those posts where I sort of ramble about what I am thinking, and nothing of note ever gets resolved or accomplished. Due to that, I have removed some of the more rambly bits to keep this one a bit shorter. Have a good day.

​