Your Tools are just tools

Some years ago, back when I was still studying at university I remember having a discussion with one of my tutors as he observed my workflow. I was working on a series of ‘hyper realistic’ paintings - a poor imitation of the then-current artist Glenn Brown, for the most part because I couldn’t think of anything better to do (and I wanted a vanity project to test the limits of my technical painting skills).

In questioning my technique my tutor asked why I giving myself the additional complication of transferring the detail of my source material to the much larger canvas using the old method of a grid line reference. Other Students doing similar work had transferred their source material to slides which they projected onto the canvas to effectively trace around. This technique was readily available to me and led to excellent end results so why wasn’t I using it?

My short and hasty answer was that I felt that to be cheating. This answer did not massively endear me to my tutor and with hindsight I also don’t think it’s true either. Yes, I was stubbornly doing it to test I had the skill to do just as accurate a job using the more cumbersome method - but more importantly I didn’t really have much else to achieve beyond that. The technique was the end of itself, rather than being the means by which I produced the end result.

So why is this anecdote appearing on a blog about web design and development? Because those same justifications were some of the reasons it took me so long to adopt certain tools to improve my workflow, like Sass or some of the front-end frameworks out there. For years I kept away from developing ontop of stable, standards-compliant front-end frameworks because I felt it to be cheating, simply reheating the work of others. My point now is that if the work you deliver at the end of the project is not going to be indistinguishable from a vanilla-install of Bootstrap (insert equivalent popular frontend framework here) then the questions you need to ask are to do with the finished design not the technique to implement it.

I totally agree that front-end developers need to understand the detail of what is going on underneath the hood of whatever they’re building upon and have the skill to adapt any of it as suits their purpose. But once you have that knowledge, there’s only limited rewards to be reaped from testing this by continually coding afresh these basic components like cross-browser line-height resets or normalising table spacing. Get these rote pieces of the job out of the way with any of these tools readily at your disposal to leave yourself the time to really sweat the detail of the design and build something new and interesting on top of that foundation.