Your idea about tracking daily pain points was the most important thing I ever did, as well-- sort of.
I tracked, over a one year period, every single defect that made it into production that I had to correct. I did this at the inspiration of a book on continuous improvement I read. I analyzed the underlying causes of the defects, organized them by category, made Pareto charts, and looked at my underlying procedures to see how I could avoid them.
What I learned surprised me, and changed the way I approached projects from then on. What I learned was that by far the number one problem I needed correct in order to avoid production defects and downtime had nothing to do with my code.
I discovered that the number one cause of avoidable defects in production had to do with the quality of my test data, differences between production environments and test environments, and discipline in how code gets promoted to production. And of course establishing a process for such things as promoting code-- a process which is formalized, followed, every time, and continuously improved as needed.
Learning this gave me a new respect and appreciation for the importance of a faithful and realistic staging environment that mirrors production as closely as possible. It's often impractical or expensive to various degrees to replicate or simulate a production environment faithfully for a variety of reasons. What I learned is that not all projects deserve the expense and trouble of that faithful reproduction of the production environment, running production loads in staging. But to whatever degree we don't do that, we take on more risk, and it's good to at least understand those risks.
Perhaps I'm talking more about project management, infrastructure, process and procedure than about pure "programming". But what I learned through this one year exercise was that often times when people think about wanting to get better at programming, improvements in some of those areas are really what's needed to get to the higher tiers of excellence.