"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.