Do make me think

Building the web of the past was easy. You’d write some HTML, CSS and JavaScript; followed by a few rounds in the ring with Internet Explorer and you’d be done.

Things have come a long way since those days. To reach the same end we now use various pre-processors, task-runners and code abstractions all of which often require some other form of framework, package manager or library. Of course we don’t have to use these tools but in a pursuit to optimise our workflow we often find ourselves adding more and more to the technology stack.

As a consequence we as a community have tried to streamline these processes by creating generators, bootstraps and more frameworks. The ultimate aim being to abstract these levels of complexity and allow us to focus on what matters most.

That makes total sense. We’ve got rid of the repetitive boring bits like concatenating code and optimising images and made our tools do that for us. But I cannot help feel there is a balance to be struck and often find myself asking “am I adding another layers of abstraction”?

Chris Coyer wrote about The Abstraction Point back in 2010:

Your abstraction point is the level of abstraction you feel most comfortable in getting stuff done from day to day. It might be using design view in Dreamweaver and adding interactions with IxEdit. It might be writing in assembly language. Neither one is “better” than the other. It’s just where your current comfort level is, and more importantly, using the tools you need to to get the task done with reasonable speed.

Ever since reading that post, the abstraction point has been something I’ve considered when choosing the tools and processes I use day-to-day; More importantly it makes me question how my decisions might affect teams who subsequently use those tools. It often feels like every time we pick a new tool or framework, we’re adding yet another abstraction to the technology stack. Whether it’s using jQuery or SASS, Bower or Bootstrap; we risk using the unlimited number of tools at our disposal without ever taking the time to understanding what’s happening under the hood or how our decision might affect others.

Using these tools is certainly not a bad thing. If it gets people started quickly or the job done more efficiently then it makes sense to do so! But it has risks. By making things easy we are telling people “hey there’s no need to think about this stuff… someone has already done the thinking for you”. That kind of approach is not healthy for anyone.

To put it into context, it’s not completely unheard of for a developer to say they have “used” a tool like Grunt; when the reality is they never even opened the Gruntfile. That approach is fine until things don’t go as smoothly as the README suggests. I myself have built sites using Bootstrap but rarely opened the CSS or JavaScript file to understand the how or why of the code underneath. I’ve also used tools like Yeoman and Grunt to automate repetitive tasks, but in doing so created a layer of abstraction for others. Ask yourself this, when was the last time you checked your compiled CSS (escpecially if you use Compass or Autoprefixer) or took the time to understand how a JavaScript plug-in you grabbed from Bower actually works?

So how do we strike a balance? We want to make things easier for ourselves (and others!) by using tools to automate or template the repetitive stuff, whilst at the same time we don’t want to deprive others of the learning opportunity we went though in the process.

Luckily I think most developers are quite inquisitive and take the time to understand how something works – ‘view source’ anyone? But encouraging that sentiment and convincing others to go beyond their own abstraction point and dig a little deeper can be tough at times. Often it’s not a lack of wanting but a lack of time. Documentation or training can help, but it’s also important to encourage a passion of wanting to understand why; both in ourselves and in others.

So the question is not, should we use these tools – the answer to that is most certainly yes! But in doing so, we should try to encourage people to go beyond their abstraction point and understand what’s happening underneath. Even if it’s just a tiny abstraction like understanding what .addClass() is doing or what tasks a “grunt build” command is actually running. We don’t have to understand every function, command or layer in the technology stack, but understanding even the smallest layer of abstraction that sits before and after our own focus point will help us to understand the how and more importantly answer the why.