About a month ago I started learning Ruby. I thought learning a popular back-end language, when paired with my front-end focus, would help my career and let me start code more amazing things. What a coder knows is their greatest asset, after all, so wasn’t this a great investment?

Turns out, while it wasn’t really a bad one, it wasn’t the best.

Questions to Ask Before Learning a New Language

As I kept learning the Ruby basics, a few questions hit me:

Zell Liew wrote a good post on whether or not to learn new “shiny new tools” for one’s workflow. While Ruby is too established and trusted to be a “shiny new tool,” I still wanted to judge it with the same criteria. One of the first steps he mentions is knowing what sucks in your current workflow, and choosing a tool that’d make it suck less. That’s a quick, effective to find something worth learning.

As great as Ruby is for server-side apps, that’s not even a real part of my workflow. So investing so much to learn isn’t worth it.

Start your search for new tools by finding the worst parts of your workflow, and what will make them better.

Don’t get me wrong, considering how many Ruby developers I work with, knowing the basics of the language - syntax, classes, and object-oriented programming - is useful. But in-depth knowledge of serious Sinatra or Rails apps isn’t. As a front-end developer, my time is better focused elsewhere.

Where to Focus Next

With that decided, the next question was “what sucks the most in my current workflow?”

After some introspection, I think my focus on Ruby was me displacing some frustrations with Jekyll. I love the popular static-site generator, but its limitations for dynamic content were a consistent wall. Jekyll couldn’t handle most ideas for simple projects with just a little dynamic content. Learning Ruby to solve this is like buying an entire plumbing company to fix one leaky pipe.

So I looked for a tool for simple sites or apps with dynamic content, is easy to manage, and preferably in a language I already know. I quickly landed on Express.js for Node, a tool I’ve used many times (albeit just to run Gulp). It uses JavaScript and does exactly what I’m hoping for. It also boosts my JavaScript knowledge and experience, which I’ve wanted to for a while.

If they don’t do all this? At least I’ll know to cut my losses sooner and search again. But I found this tool with the better “what should I learn next” criteria, so I’m less likely to be wrong this time around.

Moral of the Story

I don’t regret learning more Ruby, since now I understand the basics and how others use it. But I do regret giving it too much time and energy when it wasn’t the right fit for me.

I think newer developers like me always feel more pressure to learn something new based on its hype and usage. But the more pressure there is, the more critical we should be about learning it. How much will it help our current work? Do we know we’ll use it later? Am I learning this because I want to or others want to? Are they right?

So if I do return to it someday, I at least know I’ll have much better reasons for sticking with it. Until then, I know my priorities are elsewhere.

Cheers, Max A