If you find that you're spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you're spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice. - Donal Knuth
I have an addiction to infrastructure. While programing a solution, I eventually find that I am working on things that do not directly contribute to solving the problem. From a rational/detached/post-fact perspective, I know that this is a huge source of waste. Funny, I never seem to notice this at the time.
I do not have a problem with motivation. If anything, I do not value my time as much as I should. Let us leave that for another rant.
I do not have a problem with my programming skill set. It isn't lack of skill that impedes my ability to deliver. Not to say that I have nothing that needs improvement. My mathematics is weak, I never really got SQL, my Git skill are passable but nothing extroardinary, I am average at using the terminal, I type poorly, etc... There are a huge number of things I could learn and improve on, but non of those things stop me from being able to build solutions.
I do spend an embarassing amount of time trying to get things perfect.
I do spend far too much energy trying to deal with eventualities that never emerge.
I do spend mental focus on vanity features that I hope to someday reveal to the world, blinding it with my genius.
Meanwhile, the actual business problem sits untouched.
Speed is king. I am beginning to believe that this may be true of most things in life. I think the shortest way to get good at something is to become skilled enough to do it quickly. This seems to be true for artist and craftmen, so why shouldn't it be true for programmers?
It seems to me that there are at least 3 elements to speed.
Getting seperate works to come together harmoniously. This is one of the main differences between a good cook and a chef. A good cook often does one thing at a time in a linear fashion. A chef is often doing 3 or 4 things concurrently, connecting them so that they are all completed at the right moment.
Actual context switching in programming is almost certainly a detriment. However, the ability to know the order that things need to be acomplished to minimize downtime is a real skill. Huge numbers of books have been written on software estimation. I am not going to say anything about that. I am going to say that if you have done a task 10 times and it took an average of 15 minutes, then you can probably estimate that the 11th time will take around 15 minutes. This means that you can probably fit this task in a 20 minute lull in your schedule. This makes you faster.
People who have speed aren't always fast. Sometimes they are just more efficient. A good example of this is beginner vs advanced guitarist. Beginner guitarist almost always move significantly more than needed to pick a note. An advanced guitarist does a minimal move. Guess who is going to pick faster (as well as tire more slowly)?
A large part of context switching in programming is familiarizing yourself with the codebase. If you are reusing a codebase that you have previously used, you can dramatically reduce the context switch of familiarizing yourself. This makes you faster.
A measure of the number of task you can perform per unit time. This mostly has to do with repetition. You can perform a task more quickly if you have done a similar task in recent memory. Examples of this are evident.
Programmers may relate to this through the notion of Flow. When you don't have to stop and question how to do something, but can focus simply on what you are doing. This makes you faster as well as less succeptible to distraction.
Simple. Don't work on the big until you can quickly do the small. That is all I got.
Note: I am picturing a small project being ~10 hours. A medium project being ~50 hours. A large project being 200+ hours.
I think it is pretty natural to pick similar projects. Especially if you are trying to get "faster". This should allow you to focus on increasing speed (specifically through Actions Per Minute).
Step 3 & 4 are designed to allow you to address persistent difficulties in code by writting infrastructure. This is very different than my current method of writting infrastructure though as:
Being able to do something quickly and well increases confidence. Computers don't care about confidence, but humans do. If you are reading this, you are likely human. As a human you should look after your mental well being. Being confident in a skill could open a lot of doors...