Stop trying so hard. Writing algorithms is a lot like writing poetry, you just have to let it come to you. Whenever I come across a problem that the answer doesn't immediately jump out at me, I stop what I'm doing and do something else. A few hours later, maybe a few days later, the solution will jump out at me.
If someone tell me "April 3, 2007", I immediately know that was about 4 or 5 years ago by quickly subtracting in my head 2007 from 2012.
If someone told me "What were you doing 5 Years, 3 months ago", I'd have to pause, add up the months, then eventually come up with "What were you doing on June 23, 2007". In June of 2007 I had just graduated from college, was living in Central California, etc. I index time in my head by date, not timedelta.
On the other hand, "What were you doing 3 hours ago" is much better than "What were you doing on August 23rd, 2012 at 6:05 PM". It would take me a while to realize the question was asking about today. I'm not one of those people who seem to always know what date today is...
Programming is really two jobs in one. Writing new code, and maintaining existing code are two completely different tasks. Its surprising to m that the two jobs aren't differentiated more.
It's ort of like the difference between an aeronautical engineer, and an ircraft mechanic. The engineer's job is to design the airplane to be robust, safe, and quickly fixable. The engineer is not expected to whip together a new aircraft design in a few hours. He is expected to take his time and get it right.
The mechanic's job is completely different. His job is to fix the plane when it breaks. His job is to do it right, but emphasis is on getting it done quickly.
If all new code is written in a way that is akin to the aeronautical engineer, the act of extending and fixing the code is simple enough to not ever need MacGuyver coders to fix it.
At my last job there was a database table in out project that represented the markets our site was operating in. One row for Spain, one row for Brail, one for USA. At the time we only were in three markets so there were only three rows. The class that handled the markets had a function called `get_market()`. It didn't just d a SQL SELECT, it had a cache layer placed on top of it. The next call to that function would get the results from memcache. Anyways, when I say this I removed the cache and measured the time it took for the SQL. It took like 2ms (since selects from tables with three rows are super quick). I then measured the function call with the cache enabled and it took something like 25ms. In this case, the 'optimization' actually took longer. The lead developer had this belief that any time you hit a relational store, its 'going to take too long', so just about every single SQL query was wrapped around memcached.
I was thinking about this sort of thing a few weeks ago. I think it's more about 'control' rather than 'safety'.
Heres my take:
fiscally conservative politician = tight control on spending
fiscally liberal politician = loose control on spending (just throw money at whatever, who cares)
fiscally conservative programmer = tight control over code (refactoring, design patterns, documentation, tests)
fiscally liberal programmer = loose control over code (who cares if it's spaghetti code, as long as it runs)
socially conservative politician = tight control over people (no abortions/gay marriage/legal weed for anyone)
socially liberal politician = loose control over people (let people do what they want)
socially conservative programmer = tight control over people (heavy process, waterfall)
socially liberal programmer = loose control over people (light process, agile, "just write good software")
I'm a socially liberal, fiscally conservative programmer. At my last job everyone was fiscally liberal and socially conservative. I did not last long at that job.
As you become a better programmer, these refinements and rearrangements occur in your head. So when you begin writing code, you already know how you want the code to look.
When I write paragraphs (say, for a blog post), the process goes a little like this:
1. Write first sentence
2. change half the words in first sentence
3. Write second sentence
4. change more words in the first sentence
5. Rearrange the second sentence to make to flow better.
6. Write third sentence
7. Trash second sentence all together
etc
The reason why I write this way is because I suck at writing.
When I write code, its much different. I usually just drop my cursor into the document, and let my fingers bang out the code I want. I'm a much better programmer than I am a writer.
When I code, I use TextMate. When I write blog posts, I would probably be more efficient using vim.
If you're just reading, reading, reading, reading, then you're not going to get much out of the reading. If you take a few minutes after each article to correlate the information to your own experiences, you'll get more out of the article. Thats why I try to leave behind a comment to each blog/article I read. Like right now!!
Its sort of lik the difference between going to class, listening to the lectures but never doing any of the homework, as opposed to going to the class, and doing the homework each night.