When it comes to working on the web I spend time learning a new skill. Not only is it important to be good at any job, but any worker needs to keep up with the industry and best practices that will help them as an individual to be better at what they do. As I read articles about the web I also try to make sure I look for instances where this practical skill can be used. There are some developers that try to take an article and use it across a site that wasn't even part of the use case that the author of the article had intended it to be used.
I get irked on occasion when I see developers read an article, take the context out of what was being written about, and then try to evangelize that new direction to a web team when in reality what they are taking about was never meant for the site they are trying to evangelize about. While some articles talk about new ways to display images for mobile devices or how to organize your responsive design; all those articles have their context and purpose, which doesn't always apply to what you are working on. This is when disaster begins to strike.
For example, earlier this year I had to contend with another developer about adding excessive markup to a page while trying to fix a problem with CSS. While there are good reasons to use Internet Explorer overrides on certain occasions they should also be used with caution, especially when this code is residing in the head of the page, not in a CSS file. I know there are probably a few front-end developers our there that just cringed at that thought. In some cases when I design a new website I look not only at the CSS but at the HTML markup itself when building. If my styles start to get out of control when trying to get something to work in Chrome chances are that this will cause more problems in IE or other browsers, thus leading me to change the markup. When you come across a developer that adds excessive markup in both cases then please stop them for the sake of your team and others.
I may be coming across as harsh or unforgiving in the case above, but in my position I need to make sure that code and procedure works when we start to apply it on a large enterprise scale. All the pieces need to fit or we cannot move forward. I have spent the better part of a decade learning to code and during that time I have learned most of what I did was wrong and then had to learn how to do it right. I'm extremely thankful for those developers that realigned my skills and best practices in order that I start looking at procedures in context. When a developer is used to building mom-and-pop sites it can be hard to think enterprise. There's definitely a learning curve that needs to happen when you start looking at sites that go from being 10-15 pages to being 4,000 pages in size. That leap can be hard to grasp at first which make most of what you used to code like obsolete. You have to think in terms of scalability, reusability, and use across all those pages. If I don't start thinking about these aspects first when I come across an error it will be much harder to fix because half the site is using an ill-conceived template.
In the long run I encourage every developer that I train to learn a new skill monthly. It doesn't mean that you need to learn Ruby in a month, but that you add a new skill to your belt. If for example you are interested in responsive design, then start reading articles, download some responsive frameworks, build your own, or start experimenting in some other way. The only way to learn to do something new is to get your hands dirty and learn it. Don't be the developer that reads, evangelizes, and doesn't honestly know how the process works.