ES5 is fairly mainstream at this point, but a lot of real-world developers still have to deal with the likes of IE8 or other legacy support, and shims and polyfills to add missing and expected functionality. ES6 has been pretty heavily fleshed out, and is starting to gain adoption amongst some of the evergreen vendors, but still has a long way to go. ES7 is still very much in the proposal stages.
A lot of you out there may be struggling with the same concerns I often have myself: How does one keep their skills constantly evolving when the day-to-day demands of our jobs require that we stay handcuffed to legacy environments?
tl;dr: I don’t have the answer to that.
All I can say is that the ever-expanding ecosystem of development tools, the Cambrian explosion that is npm, and the constant raising of the bar in the world of Javascript development make for an exciting mix for anybody that’s willing to dive in and give it a shot.
I myself find it difficult to work on anything in my spare time, because what spare time? In my day job, there are constant tight deadlines that need to be met, and in my <finger-quotes class=”Dr.Evil”> “off-time” </finger-quotes>, I tend to catch up on work that’s fallen behind, catch up on paying down technical debt to keep it from accruing too greatly, or veg out in front of a TV (I love my brainy-turn-off time). However, that leaves little time for expanding one’s skill set.
Pick your battles
At work, we’ve been fighting to get NodeJS approved as a viable middle-tier technology option. I recently attended a conference at HomeAway, EnterpriseJS, that specifically dealt with some of the religious/political battles that can occur when trying to get new technologies implemented in a company with more traditional monolithic applications. It also covered some of the emerging trends in NodeJS and in the development mindset. API-first mentality is getting to be a must, and anybody that’s not seriously considering and/or actively pursuing SOA at this point is doing themselves and their company a disservice.
However, pioneering internal change can be difficult. The powers that be, those that sit on high, they don’t often like to consider paradigm shifts in their technology stacks. “If it ain’t broke” can be a powerful mantra when considering the bottom line. And to be fair, it’s a perfectly valid argument. The challenges come in trying to reconcile what’s best for the business with what’s also best for your own growth as a developer. How can you get approval for playing with the new and shiny while also proving its value to the company when it’s not exactly proven out?
You have to figure out which battles to choose, and which ones to let go of. If you don’t, you’ll drive yourself insane from the struggle, or blow up at someone, or burn yourself out trying to do everything for both the company and yourself. See if there’s a small portion of an application that can be used as a test bed for vetting a new technology. See if there’s a way to budget time as part of a development sprint to be used specifically for research for proof-of-concept purposes. Start an internal project with a few other people of like minds, and used that shared effort to get something meaningful done with a reduced amount of free time.
Why am I even rambling about this?
Simply put, because it’s my blog, and it’s been forever since I posted anything, and I’ve had a lot of this stuff on my mind lately. It’s easy to feel like you’re falling behind your colleagues when you can’t look up from the trenches long enough to take a breath, let alone learn anything new. And it’s exciting to feel the revitalization in your craft when you actually do get to play with some new piece of technology.
In my current project, I’ve been crash-coursing myself in ReactJS for the past 4 months or so, and it’s been amazing. I have to admit, the pill of embedded JSX was a little hard to swallow at first, but like so many others, I got over it quickly, and find it second nature at this point. I’ve also recently started trying to figure out how to get my hands on some ES6 syntax. I know I’d personally love to start playing with native Promises, and fat arrow functions, and class constructors, and getters and setters, generators, native module imports, a whole slew of things that come with that step, and the babelify transform for browserify will allow me to use that with React. However, I want to be able to use it as part of my top-to-bottom workflow, so will most likely start working babel into my NodeJS project as well. It’s a piece of work I’ve carved out for myself that’ll take some up front configuration and refactoring, but will hopefully pay off in reduced development time over the long haul.
Share as often as you can find the time to
It’s a lot easier to get time budgeted and approved when it’s for a group meeting, than when it’s for an individual. If you go through the struggle of getting your own time carved out, and learn something valuable from it, arrange to dump that knowledge back out there for your other coworkers to benefit from it. Not only does it make you a stronger developer (if you’ve never done anything like this, you’ll find that you research the topic even more intensely, so as not to look like an idiot when you’re up in front of the group), but will give you practice in soft skills and public speaking, and position you in the eyes of your peers as more of a domain expert, both of which are always good for your career.
I’m currently putting together a series of trainings for the other front end engineers at work. I’m about 60 slides deep into a ReactJS immersive workshop I plan to host, and have also considered putting on a much shorter workshop for Promises in general, since some people I know still have a hard time wrapping their heads around how they work, and when and how to use them.
It’s a lot of work and a lot of responsibility, but in the end, it’s all about keeping that bar moving upwards, for myself and those with whom I work most closely.
What kinds of projects are you working on, and what do you wish you had the time to work on? How do you attempt to block off time for those goals without overbooking yourself and burning out?