By Brian Rinaldi
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.
Obviously, in the HTML, CSS and JavaScript worlds, a new library is born every 1.2 seconds (I kid…sort of). I love reading about them. I even write a weekly blog post that aggregates many of them. I also love to write about these new tools, even keeping a running list of ones I potentially want to write about in the future. Here’s the thing though, my love of tools often makes me focus on the tool rather than the problem it is trying to solve.
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!
Let’s even get beyond software or techniques like Responsive Web Design. Lately the trend seems to be to show how to do things using the latest API in the spec or do them in CSS only. I think these posts are awesome fun experiments, but they so often seem to focus on the means to the ends, rather than the why. It’s great that we can solve this classic UI problem in CSS now, but what is the benefit? For example, you might show how to do an animation using CSS without JavaScript, but the goal really is better performance, especially on less powerful mobile devices. So instead of focusing your article on “Doing X Animation with CSS Only,” the article should focus on “Faster and More Performant X Animations.” Using CSS only is a means to an end.
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.
Have Fun
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.
Hello Brian. Your is a great article and I totally agree with you. We really should focus on problems and not on tools. However, I think there is a simple reason behind all this.
Apart from what you defined as “nice experiments”, in most cases when we write an article is because, during our day to day work, we faced a problem and wanted to share the solution we reached Usually, due on the project constraints, we had to solve it while working with a specific framework, library or language. We share our solutions for several reasons, for example: showing our expertise in a specific field, helping others, driving traffic to our website, or career moves. Therefore, we have to engage readers that have to solve a specific problem, but that have also to solve it with a given tool to achieve our goal.
Probably someone won’t agree but this is the reason I always gave myself to explain this phenomenon.
I think you do make a good point, but I would say that the developer’s ingrained passion for new and exciting frameworks, shortcuts and solutions is a big driving force behind the evolution of the internet.
There are probably other ways of making a responsive website, other than Bootstrap. But people getting excited about it and blogging about it organically is what drives the growth and development of the internet. Maybe, if people didn’t sometimes have a bit too much enthusiasm, these frameworks would have never been picked up – a great loss to developers everywhere.
I wanted to do I dance when I saw your title. I’m a big proponent of, “if you don’t understand the concepts behind a tool or what *problems* it can potentially solve you probably shouldn’t use it”. When I read about new technology, I’m looking for ways to improve what *I* do, not a cool thing someone else has already done for me. Writing about new tools are, much of the time, a distraction.
I sometimes feel like an island on this issue, and that perhaps my protest is that I don’t like to try new things. Really, I just don’t want to spend time learning custom classes and methods on a tool that I could have built myself if I had the time and interest and that may well be outdated or overshadowed by a new tool in the near future. And talking about things I can and can’t build myself: if I don’t understand the concepts behind how a particular technology works, then I’d rather take that as a challenge to learn those things rather than blindly putting my faith in a popular git repo. I may get ridiculed for this, but I find little value in jQueryUI; Any features I might want to take advantage of I can write custom much quicker than it takes to try to customize the API, and at a fraction of the filesize. (jQuery itself is a tool that does significantly improve workflow and actually saves quite a few Kbs in the long run.)
Bloggers, let’s have more focus on the problems to be solved and think about semantic, performant, *conceptual* solutions and leave the toys in the “Further Reading” section.
This article really resonated with me as a sort of generalist. I’ve never really identified with any job title prefixed with a tool. I’ve never been a “WordPress Developer”, but I’ve built with WordPress. I’m not a “Sass/LESS/Stylus Designer”, but I’ve used those tools at different times. I’d even extend this to languages. I think we shouldn’t limit the conversation to “just use X” or “don’t use Y”. Developing is less about the how and more about the why. The bigger question should be, as you said, “how does this improve my work/benefit visitors/solve problems?” Only then should we worry about the method.
I haven’t yet used Bootstrap, because I haven’t run into a problem where Bootstrap was needed yet. Same with Foundation. I’d never call for dropping our tools, but mindfulness goes a long way. Many libraries and frameworks out there were built to solve specific problems. Not as a catch-all for any problems that might appear. It’s like how Phil views jQueryUI. I’ve never used it either. Not yet. The problem hasn’t presented itself yet, so I don’t need the tool.
At the same time, I can totally understand how developers can get caught up in endorsing our tools as the One True Tool. When you use something like Sass frequently enough, and to great effect in your own workflow, it’s easy to attribute your boost to the tool itself rather than how YOU used it. I fell into that trap not long ago. I was so passionate about the tools I used, that the idea of someone not using those tools was foreign to me. And that’s how we can box ourselves in. The instant we start to tie our effectiveness and ability to do our work to a specific collection of tools, rather than how they make us effective, we are screwed.
By shifting the focus away from the method back to the rationale, we can make our tools work for us. No matter what they may be.
from my experiences, I see the main reason for a developer’s reliance on certain libraries/frameworks is mainly because they don’t actually know how to program and lack fundamental knowledge of the languages and technologies they are using. this type of developer relies heavily on the code easily obtained from online examples and tutorials. without this code to copy, paste and slightly manipulate they would not be able to do their job.
this helps foster a certain perception around developers and the libraries/frameworks they use. so when the people in charge of a project, with little understanding of UI — and possibly any other type of — development, start looking to hire new people, they believe that said libraries/frameworks are incredibly complex and require people with “specialised” knowledge in them.
backbone is perfect examples of this. backbone is a mere ~2,000 lines of code, including comments. when i see jobs that advertise for developers who are specifically “backbone developers” i can’t help but laugh, cry and die a little inside.
a wise person once said to me, “if you only know how to use the tool, you’re worth is limited and bound to that tool. if you know how to use, and understand the language behind it, then you’ll never be limited.”
I’ve worked with people who claim to be “specialist developers”, I generally know more about the library/framework they “specialise” in, within 30 minutes — assuming I haven’t used it already — simply because I downloaded the development version and read through the source code, whilst they use the production — minified, obfuscated — version in their dev environment and wonder why they can’t fix a bug…
another wise person once said to me, “if you can stick your finger in a glass of water, pull it out and leave a hole where your finger was, that means you’re not expendable.” I don’t think this has anything to do with your post — I was trying to get a pay rise at the time — but I think it’s worth saying, coz it’s cold and it’s nasty, but it’s the goddamn truth!
So true! Shiny new things without added value. Must have!
Self-reflection is always good, thanks for that.
That does not go only for tools but also about the vocabulary used to describe something. I love people coming up with a new way of programming, a scientific name for it and new wiki link study without telling us what problem it actually solves.
I tried be open minded but at the end of half the javascript posts today, I end up with a “why?” or a “that’s it?”. (Not talking about your post here).
It is true that we should always be remembered why we do something.
My last post title on this site was “Your way out of chaotic JavaScript”, and funny as it is, we spend an hour with two people to find a title that describe what I tried to explain without making my framework while it was deeply involved in the article.
Agreed. If developers spend half as much time understanding requirements and managing complexity as they do playing with new frameworks, then much better line-of-business applications would be written.