I'll try to make this post as short as I can, so forgive me if it seems abrupt. I'm going to take the opportunity to explore the possibility that you have no talent for programming. You should still take the advice to check out sleeping patterns, fitness, health, etc.
First, take a look at this website: http://the-programmers-stone.com/the-original-talks/day-1-th...
It's the first one I came across years ago on the subject of "What is the difference in the way of thinking between talented programmers and non-talented programmers). I don't think it is exactly right, but it's on the right track.
Lately, I've been experimenting with the idea that programming is a linguistic skill -- just like speaking. I spent 5 years teaching English as a foreign language and studying language acquisition. What I discovered was that students of English have the same kind of distribution of skill sets that programmers do: Some have a knack for fluency and can speak freely even if they have little vocabulary or grammar. At the other end, are people who literally can't order a drink from MacDonald's in English, but can tell you anything you would ever like to know about English. In programming, we often call these people "language lawyers" (it's a derogatory term, so I would avoid using it ;-) )
In foreign language teaching, there are 2 forms of ability: fluency and proficiency. Fluency means being able to listen to or read a sentence and automatically (with no undue thinking) understand its meaning. Similarly, when faced with a task of speaking, appropriate sentences pop into your head without thinking about it.
Proficiency is the range of language that you know. So it's the amount of vocabulary and grammar. Often someone with good proficiency will be able to puzzle out the meaning of a sentence, but it will take them a lot of time. Similarly, they can construct grammatically correct sentences by recalling all the rules and painstakingly piecing it together.
The old way of teaching was that building proficiency is the most important thing and that by repetition you would naturally create fluency. My experience has been that this is false.
By now, I hope you see some parallels with programming and people who experience problems with programming fluency. On the one hand, you have someone with a lot of knowledge (perhaps they have literally memorized the specs for a language and know every detail about the standard libraries), but are painfully slow. On the other, there are people who seem to be able to simply write code and guess how the language is supposed to work. They might not know details, but they can spew out code like nobody's business.
At this point, I will offer to exchange the word "talent" with "fluency". So I think that you simply lack fluency. Part of the reason you lack fluency is because people recommend largely the same unsuccessful strategies for becoming good at programming as they do for learning foreign languages (i.e., learn details about the language, class libraries, new languages, etc, etc.) In other words they recommend that you increase proficiency in the hopes that it will magically lead to fluency.
When you get a chance to read the Packers vs Mappers description in my first link, you might start to realize that this will not be successful. Mappers already think differently. They reason from first principles. They do not memorize rules -- they generate rules from the available data. Packers memorize rules and then search for appropriate rules to apply. If you are a Mapper, then learning proficiency will create fluency because you are adding more data from which to generate rules. If you are a Packer, you are just making your list of things to search longer and making your life more difficult.
As I said, the Mappers vs Packers analogy is useful, but flawed. I don't think that's actually how the brain works. Instead, I recommend reading about language acquisition, and in particular the work of Stephen Krashen. (Unfortunately, a comment is not the right place to discuss a topic of this size, but let me preface this by saying that Krashen's work is impressive, but that he is rather more confident about it than he should be based on the studies that have been conducted. However, it is the closest thing I have seen to something that will help you get the "pill for slowness").
Take a look at: https://en.wikipedia.org/wiki/Input_hypothesis
It's not the best description in my opinion. Krashen makes his book on the subject available online: http://www.sdkrashen.com/content/books/principles_and_practi... (I believe that's the one I'm looking for, but he has other resources available ad sdkrashen.com, so if you have boat loads of time, you can spend it reading his research ;-) )
So that's my theory. Now for practical advice. I'm afraid I don't have space/time to justify all the advice properly, but I will try my best.
- First and foremost is to start a large personal project and spend a little time every day on it (ideally 1 hour a day). More frequent updates are vastly more important than more time spent! The idea here is that at work, if you are slow, you spend a large amount of your time swimming in other people's thoughts. Because I assume that you are already proficient, the most important thing is to give you "comprehensible input" on a regular basis. It's not ideal (because it is your own output that will form the input), but working in an area where you have completely control, you will have less things to puzzle out.
- Throw out any notes that you might have that tell you how to do something (unless it is of the form "this is how you fix the server when it is on fire"). You need to be able to generate these things yourself on the fly in real time. If you have such notes (and I bet you do, because everyone I have ever seen that has your problem is almost buried in such notes), they are robbing you of the opportunity to repeatedly form understanding for how they are generated. You must form those understandings again and again and again or else you will not reach fluency.
- Every time you read code, you must understand it to at least 95%. It is hard to judge whether or not you understand it to 95%, so the rule is really, "you must understand 100% of everything you read". Many studies have found that when free reading, if the reader can understand 95% of the input, they can infer the other 5%. Less than that and you might think you understand, but you will be mistaken most often. This is massively important. If you think "I pretty much get this", "I think I understand what's going on here", "I've got a pretty good grasp of this, but don't understand some details" -- I'm going to suggest that you don't understand it well enough.
- To form understanding, the easiest way is to form a hypothesis and then test the hypothesis. If you have nice TDD code to work with, then it is easy. Look at the code, make some guesses about the code and then verify them with the tests. If you do not have such facilities, then you should still be thinking, "OK, if this method is here, then that means that there is an object X that calls it and sends the output to another method". Go and check.
- Occasionally, when you think you understand some code (say 20-50 lines), open up an editor and rewrite it without looking at it. This is expose the times when you think you understand what it is doing, but are wrong. I'm going to guess that when you first start this will happen more often than not.
-Read everybody else's changes to the system at work. Read every single line. Understand every single line. If you do not understand something, then get someone to explain it. Pair reviewing is a good way to have someone at hand to explain things. Comprehensible input is the only way to acquire ability. Writing your own code (output) is a secondary method (you are getting your own output as input). Read code every day.
- Time management... Sigh... this post is already massive, but this is super important, so I will try to explain it in as small space as I can...
Very likely, you have picked up "Packer" habits because it is easier than "Mapper" habits. Concentrating every minute of every day is hard. It's much easier to have a note, or memorize some formula and just whack it in without thinking about it. Over a lifetime, if you get into this habit, you end up not being able to build fluency because you are avoiding the hard work of understanding.
When you try to change that behaviour, your body will not be accustomed to it. Programming is a marathon, not a sprint. Not only that, but it is really a marathon. You can't stop to rest every 5 minutes. You have to tap out a rhythm for hours (sometimes expending more effort and sometimes less, but always engaged).
Just like you can't just go out and run a marathon, you won't be successful in staying focussed all day -- the whole day right away.
Some tips:
- Pair programming can help immensely. If you start drifting, you must ask for the keyboard, though.
- No social websites, news sites, distractions, etc, etc. No exceptions.
- If you do pomodoro, resist the urge to browse websites, talk about politics, etc, etc, in your rests. Keep a low level focus, while still recovering.
- Start with a 1 hour commitment. Take a rest and do another hour. Keep working at it until you can flow for 3-4 hours at a time.
- At the end of the day you should be mentally exhausted. If you are not, then you have allowed yourself to get distracted. Keep practicing.
Well, that's enough to get you started. Hopefully it will be helpful and you can use it to start an effective training program.