Web development is constantly evolving, rewarding those that learn and adapt; developers that cling to older methods do so at their own risk. Yet the industry’s heavy workload and tight deadlines place many in a paradoxical situation: Due to their proven and familiar status, older techniques and programs often stay at the forefront of a developer’s workflow.
So how does a web developer learn and evolve while still making their deadlines? Having been in the industry for nine years, recently shifting into a position where I’ll be mentoring junior developers more often, I’ve been reflecting on that question a lot.
A mistake I made early in my career was associating training as strictly something that had to be done in lieu of project work. With project work a consistently higher priority, training rarely got the attention it deserved.
I’ve found a better approach: consider training as part of the project deadline instead of a substitution for project work. In particular, factor into your next web project a new tool or technique you’re interested in, giving yourself a few more hours of work in project estimation. Good managers and clients can often agree that integrating the learning process results in a better developed project and a more productive worker.
For example, in one web project, I was tasked with the unusual alignment of text across several web pages. It was an excellent opportunity to learn about CSS3 based flexbox layouts, and considering the main focus of the site was modern browsers, the new technique would provide more maintainable and flexible code in the long run for the client. Technically I could have used this argument as a way to say I wanted a few hours of flexbox training before starting work, but given the tight deadline, this wasn’t a strong argument. Instead, I just increased my project estimate by a few hours to make flexbox one of the project’s delivery requirements. By project end, I learned a new skill while also delivering a better product; a win-win situation for everyone.
I find especially among junior developers, one of the biggest excuses for not trying to learn new web skills is, ironically, loss of productivity. Learning curves are perceived as high and the old ways just feel faster, especially at first. My response is nearly always the same: give it a try, but if it doesn’t gel that’s ok, try alternative methods. Even though I find the web development industry can change far more rapidly than other tech fields, part of that flexibility stems from its very openness and unlike other industries, there’s rarely a single agreed upon way of doing things. For instance, I tend to dislike CSS frameworks like SASS; I’ve found I’ve been able to programmatically just move faster with plain vanilla, well organized CSS.
Overall, I’d estimate the majority of the new web-focused helper programs, tools and skills I discover and learn are abandoned after only a few uses. Yet a small percentage become not only useful, but an essential part of how I do my job. Examples range from little applications like ColorSnapper and Skitch to larger tools like the HTML5 Boilerplate and modernizr.js. That’s what makes a regular commitment to learning so important: more attempts with more tools or more in-depth usage increases the chance of discovering a real gem.
We’ve all probably heard of or seen firsthand clients, web teams and managers that rely on dated forms of development. Maybe it’s because the leaders are too steadfast in their outdated workflows. Maybe it’s a company that has such tight deadlines that design and development evolution takes a back seat. If you are working in such an environment, and there’s no sign of change, it may be time to leave. You might like the salary, your coworkers or project content. Yet, if you’re committed to the web development industry, not having real project experience on modern tech can hamper your career in the long run.