I was motivated by an opportunity to win N1,000,000 (around $5000) in a programming challenge this weekend.
The challenge was hosted on Codility’s platform. I’d never heard of their service before, let alone used it, so I really didn’t know what to expect going in.
On starting the timed test, the most notable constraint was my inability to import packages from github, npm or http. Maybe Codility lets you do it, but I didn’t have time to experiment and there was no clear way to do so in the interface.
No github. No npm. No libraries.
The thought of writing JavaScript without jQuery, Underscore or access to random libraries is very intimidating for many programmers.
It’s not every day you’ll experience such constraints, but you must be prepared to work under peculiar conditions. Your toolkit must be flexible enough that there’s hardly an environment you wouldn’t be productive in.
All the questions in the coding challenge dealt with manipulating collections of data and teasing out results from them. Interestingly enough, I’d written a blog post on Writing Reusable JavaScript a little while ago. The purpose of the reusable code I’d written? Iterating over collections of data and teasing out results from them.
Could I have done the same thing using jQuery, Underscore, Lodash or some other package out there? Yes.
However I wrote my own function to understand what’s going on behind the scenes much better. Because I did, I knew the solution a bit more intimately and could pare down my tool to the bare necessities or add needed bells and whistles on demand. I can perform these operations in JavaScript environments without those libraries or fancy new JavaScript language properties.
When building your code toolkit, don’t be so dependent on ideal environments. You may work in a code base that doesn’t use the lastest ecmascript features. You may not be allowed to use a transpiler. You may not even have access to packages.
You need to understand the principles of what your tool do and how to accomplish it with the barest of necessities: a text editor and your wits.
If you find yourself heavily dependent on something, try to spend a little time creating a dependency-free version of it: a version that you can copy and paste and use without relying on specific libraries environment properties.
When I fell in love with the ability to decouple code with publisher/subscriber pattern, I wrote my own pubsub. As my needs grew, I evolved my pubsub into cjs-noticeboard (pubsub with a noticeboard pattern). Today, my server-side and client-side code use cjs-noticeboard extensively.
Maybe I’m biased towards my own tools because I built them. I think what’s more important is that I understand exactly how they work and that I can take them anywhere. I can put them in IE6, a Meteor.js app or in a Codility challenge and know they’ll work exactly as expected.
You don’t have to build your own tools but you must understand how to carry them with you to all sorts of environments. Not every environ will be ideal, but you need to be prepared to kick ass no matter the conditions.
I’ll conclude with some of my Considerations for Assembling a Practical Javascript Toolkit.
1. Is this dependent on a specific version of JavaScript? (do I need a transpiler or shim to get this working everywhere?)
2. Is this dependent on a library? (Can this work without jQuery or Underscore or a specific framework?)
3. Is this single-purpose? (does it come with baggage I don’t need?)
4. Is it something I can make by myself? (do I understand the principles behind it or is it magic?)
Ps.
Oh yeah … if I win the money I’ll be sure to write more about it 😀