Do you even learn, bro?

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 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?

Evolving jQuery UI For Web Components

My job centers around writing reusable javascript components. As a result, I spend a lot of time reading, a lot of time writing code, and a lot of time revisiting those things I’ve previously written, and trying to improve upon them. In recent months, I’ve been obsessed with performance improvements, both with rendering state as well as optimizing them for the browser’s paint cycles. There are, by now, plenty of articles out there about window.requestAnimationFrame(), deferred objects and promises, development patterns, up-and-coming Web Components proposals, etc. This article is going to be an attempt to marry a lot of those disparate concepts in the context of the jQuery UI Widget Factory, which is one of the more widely used frameworks out there for reusable UI components.
Continue reading

My descent into AMD…

Asynchronous module definition. It almost sounds like something out of science fiction. What is this relatively newfangled concept, and why shouldn’t you just hike your pants up to your nipples and tell it to stay off your lawn? I, myself, had to be dragged into it kicking and screaming, and now that I’m familiar with it, I can’t imagine how we didn’t come up with the concept even sooner. Continue reading

The Javascript Console

Most web developers are familiar with some of the available developer tools out there in various browsers at this point. However, most people don’t use them anywhere near their full potential. The goal of this post is to explore the javascript console in a bit of detail, describing some of the features and techniques of using it, but without duplicating effort on the part of some other good blog posts. I’m sure I’ll miss some items that people deem appropriate or necessary, so please feel free to fill in the gaps in the comments below. I’ll mostly be speaking from the context of the Chrome developer tools, unless I specify otherwise, as I find them to be one of the more (if not the most) robust offerings currently. Continue reading

Never Stop Learning!

“It’s easy to sit there and say you’d like to have more money. And I guess that’s what I like about it. It’s easy. Just sitting there, rocking back and forth, wanting that money.” — Jack Handey

I love Jack Handey, and you know what else I love? Knowledge. Learning. Experimenting. Successes and failure both. I think it’s easy in this industry, for one to rest on his/her laurels, and not seek out any information on items outside of their immediate scope of work. I interview a lot of candidates that, when asked why they’re looking to leave their current job, or what they’re looking for in their next job, they say they’d like more opportunities to learn. Continue reading

My First jQuery Conference Presentation

So, I did my presentation for the Austin jQuery conference earlier today. Being my first time presenting at anything like this, and being fairly introverted, I think it’s being generous to say I was merely nervous. “Scared shitless” might be a more accurate phrase, which is good, because being shitless, I couldn’t crap my pants right there on stage. My voice was shaky throughout, my breathing was uneven, and I was sweating buckets by the end of it (a combination of the heat-lamp spotlight and my nerves), but I got it done, and got everything out that I wanted to say. Continue reading

To Bootstrap, or Not to Bootstrap…

We have a new product we’re apparently looking to spin off here at work, and as part of that conversation, someone threw out the words “Twitter Bootstrap“. For those of you not familiar with Bootstrap, it’s a predefined set of (both stylistic and javascript) visual componentsĀ and layout scaffolding that makes it fairly quick and easy to prototype websites, and is pretty snazzy in appearance to my developer’s eye, though you might hear differently from designers. Continue reading

Modular Widget Design Architecture

I’ve previously mentioned that I work on the Platform team within my current company, as the caretaker of our central UI widget repository. As part of an ongoing effort, we’ve been in talks with our offices in Washington, D.C. about how to share some of the development effort between our teams, and get the most out of the finite front-end engineering resources we have at our disposal. In our most recent round of collaboration, there was some terminology brought up that I really liked as a method of conceptualizing the building of widgets, and how they should relate to each other. It was put into the context of the building blocks of life itself: Elements, Compounds, Cells, and Organisms. Continue reading