Forgive me for the generalization, but, as developers, we love shiny new toys. Sure, you could say that about many people, but developers seem to suffer from the compulsion for the next big thing more than most. I was at an antique car show the other day and, while I didn’t take a survey, something tells me there were few developers among the many classic car restorers. On the other hand, I bet developers are an over-represented group in a Tesla showroom.
I mention this because our love of shiny new things seems to affect the way many of us, myself included, seem to approach our work. We overly focus on the latest and greatest tool to add to our toolbox. To keep with the car metaphor, this sometimes leads to us being like the rows of spots for electric vehicles you see in many parking lots – we’re a solution to a problem that doesn’t fully exist yet. In this post, I want to look at examples of the ways in which we tend to focus too heavily on tools, why I think it can be detrimental, and some ways in which we might be able to adjust our view towards solutions rather than tools.
After I am done, please feel free to tell me you think I am right or full of crap in the comments. This is meant to be a discussion. (Note: these opinions are my own and not necessarily those of my employer)
The Most Guilty Party? Me
I want to look at a number of examples of what I mean, but rather than call anyone out on it, I will use my own work as examples. As it turns out, I am as guilty as anyone, and more guilty than most, of this behavior.
Let’s look at some examples. Take my most recent article, Retro Game Music using Web Audio and Band.js. Nothing against the Web Audio API or Band.js (they are both awesome) but notice how even the title focused on what tools were used more than what was trying to be accomplished. Why not title it “Creating Retro-sounding 8-bit Game Music in the Browser?” While that title may not be perfect, it focused more on what I was trying to accomplish rather than the tools used to accomplish it. I should also emphasize that the point isn’t the title, but titles are generally reflective of the approach to the article.
This “disease” even affects my work. For example, “Building responsive web designs with Adobe Edge Reflow” could be “Designing Sites that Work Across Devices” (or something like that). Do you care if the tool in this case is Reflow or even a technique like Responsive Web Design? If the article showed you a great way to build sites that worked across various screen sizes and DPI’s, you probably wouldn’t care if it was called Buttmuncher (well, maybe you would, but that probably wouldn’t stop you from using it).
No Plugins! New API’s! CSS Only!
Think about it this way, if pure CSS was slower or less functional, would you use it? It might be a fun experiment, but that’s all. The same goes for other things too, like new API’s or doing X without a plugin. Focus on the real benefit – is it a better experience for your user? If not, is it easier to develop? Easier to maintain? Etc.
Why Is This a Problem?
The way I see it, this focus on tools leaks into the way many developers approach their day to day work. It’s just natural that once you have a tool, you want to find ways to use it. I work at a company that makes tools, so I constantly have the latest and greatest piece of software in my own hands. This often leads to an approach whereby I am looking for a problem to fit my new software rather than utilizing the new software to solve a problem. It leads to often replacing a fully workable solution with a new one, just because the new one is new, not because it is better.
Obviously new tools and new features are designed to solve problems. I am not advocating that you avoid learning them. Yes, you should know about the latest additions to the CSS spec or be familiar with new libraries and frameworks out there or be aware of the new features in your favorite software. I am by no means saying otherwise. Just stop and think about when it is appropriate to use them rather than using them for the sake of their newness. To make a silly analogy, the day you learned to use a hammer, you didn’t suddenly start hammering screws; you put it in your toolbox and took it out when necessary.
How Do We Solve It?
So hopefully at this point, whether you agree or disagree, I’ve done a decent job of laying out the problem. So, what’s the solution? That’s the tough part – and I don’t have any easy answers. Clearly I’ve shown I am as guilty or more guilty than most, so it is harder to break my addiction. However, here are some ideas:
Stop Teaching Just the Tool
Stop putting emphasis on the wrong syllable. Put the emphasis where it belongs, on the goal, rather than the means of getting there.
Stop Qualifying Your Title
Don’t refer to yourself as a Node Developer, Backbone Developer, Sass Designer, etc. If there is anything I’ve learned in my career it is that tools are temporary, so don’t box yourself in.
Stop Trying to Hammer Screws
Be aware of the tools out there, learn them, but don’t try to force them into situations where they don’t belong.
Go ahead and experiment with trying a new library or new features in your software or doing something in CSS only. Just keep an eye on when and why it would be appropriate to use (or even, why not, as not all experiments work out).
I’ll be working hard to change the way I approach these things both in my writing, my presentations and in my work over the coming months. It’s not going to be easy, I know, but I think it will make for better results. I’d love to hear your thoughts.
Brian has published in a variety of technical publications over the years, has presented at numerous conferences and events and has served as a technical editor on a number of books.
You can read Brian’s blog archive with 9+ years of content at remotesynthesis.com (he still posts, infrequently). You can find a full list of Brian’s past publications and presentations. Follow Brian on Twitter @remotesynth.