To those overwhelmed by all the programming languages and tools you can learn, changing daily, I’d like to offer some peace of mind. In my previous article, I questioned the rampant, disconnected proliferation of code. I don’t know why it is stuck the way it is. I dream of a revolution that cleans it up, but I don’t know how. Nevertheless, I have some tips on what you can do now in your ongoing learning of programming tools.
First, a frustrating, inspiring anecdote.
It’s highly opinionated, no doubt, but it stands out as a more rigorous visualization than you normally see, for such a low-level software bake-off.
It impressed the audience. Those who were about to switch build tools said they’d use it as a springboard for their own research.
To me though, in the wake of my previous article, it was tough to dig in, analyze so many tools, visualize them, and remain objective without exploding and criticizing the whole situation. In the same way I questioned the myriad jQuery and Wordpress plugins in my previous article, why are there this many competing build tools?
They’re expensive to learn and compare. A few hours playing with each hardly gives me a sense of their long-term consequences. I can’t give each months of my time. I have things to do.
Figuring out the slide’s 6 unscientific criteria for rating and then actually investigating was an exercise in itself. Just to make some sense of the landscape, probably only to me. Why are bake-offs so individual, so hard, and still not definitive?
This was considerable effort for what amounts to a necessary evil. My customers don’t care what build tool I use. So I’d rather be programming my app.
- Establish criteria for what is important to your team.
- The tool helping you and not getting in your way is most important, but this is the most difficult to measure at a glance. So you’ll need other criteria to identify cost and risk.
- Find what tools exist and which fit your criteria, from discussion with real users and code snippets.
- Choose one.
Don’t even go as deep as my build tool evaluation. I regret it some. I enjoyed the learning, but spent days preparing for what I hoped to be a high quality presentation by lying to myself that I was being comprehensive and objective. Really the bake-off was just packaging up my own bias and self-selected Google search results.
Besides, evaluating each candidate in depth might never end, if you keep an eye on the firehose of new tech on Hacker News.
“3 steps? That’s it?” you gasp. “What if I get stuck with the wrong tool?”
Much more effort and you risk analysis paralysis.
I can’t think of a technology company that was killed by its choice of tech. I can think of plenty that were killed by failing to get things done. There is an overlap there, but programmers put too much emphasis on it. With a small candidate set and just a little upfront research, a “bad” choice will matter less than you think. So choose.
Don’t worry about this now, but yes: down the road, if your tools get in your way more than they serve you, ditch them. You might worry now that the tool will take root in your organization and be hard to excise. If it gets to that point, you’ll be far along, and your enterprise will have bigger problems than a lone e.g. build tool you chose all those years ago.
The bad news about this formula is it’s still more art than science. The good news is you can start feeling better now.
A more general note from my Credo:
- Ongoing learning.
- Breadth: don’t judge books by their covers. Yet accept you can’t learn everything.
- Depth: don’t be zealous about the technologies you do study deeply. You sound like a dick, and blind yourself to complementary tech and better solutions.
Tech forums like Hacker News encourage a 5-second attention span for cutting edge development tools. Shamefully, this is how a couple build tools made it into my “top 6.” Do not fall prey to this. You’ll end up like this commenter.
It goes on. The deluge the commenter raises is real; programming is definitely in a pickle. But we can still accomplish things right now.
If you’re too up-to-date with cutting edge solutions, that attitude is not getting anything done. The Paradox of Choice can even be depressing.3
So do not stress too much that you can’t keep up. In reality, it’s better to just pick one tool, develop competence with it, and maintain a light awareness of other things going on. Most tools will not utterly pigeonhole you. They will grant you experience that applies beyond their walls.
Don’t get too comfortable either. Maintain an attitude of wondering if there’s a better way, up to but not including the stress you’re doing things wrong. There’s a difference between self-improvement and self-doubt. Accept you can’t learn everything. Enjoy what you do learn. Don’t be zealous about it. It’s a balance.
- I admire the bold aim of this build tool to displace every other build tool from my presentation. Take it with a grain of salt though, or else it’s a depressing reminder you previously picked the wrong tool.↩
- For great humor: Task Runners and Builders: Just Because You Can Does That Mean You Should?↩
- For a light, software-oriented intro to the Paradox of Choice, see Spolsky’s Choices = Headaches.↩