Developer Distractions: The Available Tools

"A computer on every desk in every home"
“A computer on every desk in every home”

When it comes to computing, development, and related technologies, it’s really easy to be inspired by individuals such as Steve Jobs – and many people in our industry are.

I certainly am.

But I also remember, back in the 90’s, reading a lot about Bill Gates, his mission to have a computer on “every desk in every home,” the things they were working on at Microsoft, and certain things about programming that I was too young to really understand (but found interesting, nonetheless).

Recently, I came a cross a really neat interview with Gates from 1986 in which he talks about a number of things – his experience in programming, Microsoft, where computing was headed, and so on.

There are a number of really great thoughts that he shares in the interview, but there was one in particular that really stood out as it seems just as relevant today as it did 28 years ago:

Programming takes an incredible amount of energy, so most programmers are fairly young. And that can be a problem, because programming requires so much discipline. When you’re young, your goals aren’t as stable; you may get distracted by one thing or another.

Within the context of the original article, Gates is primarily talking about how, if you’re young, you need to work to stick with it despite because it’s a task that requires a lot of discipline, it’s also really rewarding.

But I couldn’t help but notice that nearly three decades later, we are still getting easily distracted. And though it may not necessarily be through other hobbies or interested, but through our own tools.

Developer Distractions – Our Available Tools

I believe that now – more than ever – we, as web developers, have amazing tools available at our disposal that make our lives much easier.

In the past five years, we’ve seen the rise of JavaScript, introduction of CSS3 and HTML5, we’ve seen browsers make incredible improvements in their ability to handle JavaScript, and we’ve seen tool after tool after tool made to help us minify our scripts, our stylesheets, lint our code, gauge performance, and so on all set to fire whenever we make a change to a single project file.

It’s actually pretty incredible.

Clearly, I’m not against things like that, nor am I against innovation. At the same time, I can’t help but ask what are we doing to ourselves?

“Release Tools, Not Improvements!”

What I see it coming down to is this: Rather than continually improve any given project (you know, the idea of kaizen that developers love so much to espouse), let’s forgo existing tools that are already doing a really good job of something, and create something that’s a stand alone tool that basically does the same thing that this other tool did, but adds one or two new features, and we’ll call it something else.

But why?

In the age of the Internet and sites like GitHub where so many tools are open source, why are we continually creating yet-another-thing-to-learn that’s just a little-bit-different-but-mostly-the-same and then writing about how it’s the best big thing (when it’s not) and how the previous tool is old news (which is dumb)?

We’re creating our own set of developer distractions with these shiny new things, then writing posts and articles about how it’s the next thing everyone should learn.

In a way, we’re cannibalising our own industry: First, we want to have developers who have an extraordinary amount of talent to produce good work all the while constantly forcing them to thrash into which tool is the next best thing to learn.

Beginners have it the worst, because every time they open their RSS readers (or whatever applications they are using to read stuff on the web), they’re being told that X technology is out, Y technology is in and they better learn it.

How can we honestly expect anyone to get anything done rather than learn the latest syntax of a preprocessor?

It’s getting ridiculous.

Learn Your Tools, Not Everything Is Important

Whenever people ask if my I know X, Y, and/or Z, I used to have this fear of saying no because I was afraid that it would make me less of an accomplished developer.

It was as if there was this sense of urgency that if I didn’t learn whatever I didn’t know, I was going to be out of a job, or I’d be less desirable to other companies (who already fluff their job descriptions with so many acronyms that it looks more like an eye exam than an actual job description).

But, at some point, I learned that knowing that a number of different tools exist (let alone actually know how to use them) doesn’t matter if I can’t actually produce anything with them because not everything is important.

So I got over it.

And I’m still here.

I Don’t Know Your Stuff, But I Know Mine

No, I don’t know every tool that’s out there, and no I probably don’t use some of the IDEs that many people constantly praise, I probably don’t like the most popular tools for automation, and I doubt that I’m the best person to ask about the coding standards of whatever new framework that’s released.

And I’m okay with that.

Because I want to be really good with what I choose to use so that I can be really good at the things I’m trying to build.

No, I don’t think I’m there yet, but I’m working on it.

Remember kaizen? That’s what it’s all about, anyway.

So pick what it is you want to do – distract yourself with the new, shiny things, or pick your tools, change when needed, and solve problems.

9 Replies to “Developer Distractions: The Available Tools”

  1. Great stuff. I was thinking about this yesterday, as people try to convince me that I need to switch from Grunt to Gulp—which is soon to be replaced by some other tool named after some other face-related onomatopoeia, I guess.

    Anyway, I lament that we’re in this state, but also that it seems like folks struggle to team up with the existing technology and work to improve its features instead of starting over. I know it’s easier to build from scratch, but it’s definitely not simpler.

  2. Well written, Tom. I like your thinking. Without having it as thought out as you do, that’s why I put off learning PHP and why I am not nothing with LESS or SASS: we want to do what we are good at and become better.

    There is a book on my shelf that I read in 2007 about improving what you’re good at instead of improving what you’re weak at. It will produce better results for others and yourself. Since then, and even another book I got at the same time, disagreed with that model, but the author was so convincing, I’ve tested it and ignored the dissenting opinion ever since.

  3. Old article but just wanted to say how glad I am to see someone saying this. Tools are just that, tools for the job, not something to learn because is currently cool. I picked up gulp, not because it was the hot thing but because I really needed synchronous task for the project I was working on. So much time is waisted jumping tools every time a new one comes out. Use what does the job required, new or old!

    I try to not get too excited when I see another “this new tools is way better then the old tool” article and focus on whether the benefit of the new tool will out weight the learning curve and teething problems.

    1. For sure! I’m glad that, even though it’s old, you’ve found it and felt compelled to leave a comment :).

      And we’re definitely on the same page: I still use CodeKit though a lot of people say I should be using Grunt or Gulp. I’ve tried both and I use either if a project calls for it (some projects use them so that’s what I have to use, you know?) but I do feel most at home with the suite of tools that are tried and true at this point.

       I try to not get too excited when I see another “this new tools is way better then the old tool” article and focus on whether the benefit of the new tool will out weight the learning curve and teething problems.

      Yeah — a lot of it is a new form of marketing and and hype to help create interest in something. It’s the long tail that’s the most interesting though. If people are still talking about it even a month after it’s been out, then it might be worth looking into.

      If a project is just at, say, 0.1.0 or basically not even at 1.0.0, I don’t bother really giving it much time right now.

  4. I think it could be classed as one of my pet peeved so I really liked to read someone talking about it!

    I really think that to pick up a new tool you really must be clear on what problem that tool is going to solve for your project and how important it is to solve that problem.

    I think a lot of the problem is that when something starts gaining traction and everyone is touting how great it is, people start using it when it really isn’t necessary for what they are doing.

    I started using gulp because it solved a big issue I was having for the project I was working on – the build time was ridiculous. But if all I wanted to do was compile my sass or concat my Javascript then I would either just run the command line tools or I would use Codekit.

    If your in a team there can be benefit in using a build script, but no so much if your solo. Completely project dependant! Which seems obvious but it’s surprising how many times that is not mentioned. I really want to see more articles better explaining what problems a tool solves and in what circumstances it’s helpful.

    I like your yard stick of the version number and longevity :)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.