Day 21

One issue I am consistently having is what I will refer to as coding A.D.D. It is drastically slowing my speed, and typically doesn't lead to anything valuable. Coding A.D.D. is where you are working on a project, either writing new production code or trying to change existing code to fit an unanticipated change, and you aren't exactly sure where to go or what to do. Instead of taking one idea through to the end and trying to at least getting something to work in a linear fashion, you work spastically and jump from idea to idea without actually following through with any of them.

To look at it from another angle, linear thinking would be throwing points onto a graph one after another all going in the same direction, and at the end you connect all the points to form an functional straight line. Coding A.D.D. is more like plotting points like throwing darts at a dart board. They are scattered and sparse, have no real pattern, and when you try to connect them all you get is a big mess.

This is what I frequently end up doing, but rather than trying to connect all the dots, I just erase all the extra code I wrote and start over again. My brain doesn't work in a linear manner, instead I tend to pop out idea after idea, each seeming better than before but really not getting me anywhere. It certainly gives me a greater understanding of the problem, when I try every solution I can think of, but I usually end up using my first strategy to get the job done anyway. It is extremely time consuming and frustrating, and worst of all, it leads to far less progress.

I find that I typically don't find the better solution to a problem until I come back to it a few hours or a few days later. When I look at it again later, the better solution pours into my mind in its entirety, and I know almost exactly how I want to improve my code. This is much more effective and efficient.

I suppose the problem is discipline. Micah said, and it seems rather obvious now, that is almost always better just to get it working first. Get some good tests, get the functionality out of the way - even if you are certain there is a better way to do it - just go with what works. Then when you come back to it, you know the worst you can do is leave it working. I also believe it is easier to refactor and redesign when you acquire extra understanding from seeing the code work as it should. This will make it easier to see a clear solution.