A lot of times I get asked by technical testers the following question: “What language should I learn?” The rationale for the question is obvious: there is limited time and they want to focus on that which will do them the most good. The good news is: this is a false dilemma.
Clearly testers want to learn the languages that will most help them construct test solutions and — ideally, or so the thinking goes — those will be in languages that your work environment already supports. Do you have to align your language of choice with that of your development environment? Not necessarily; I talk about that a bit in an aligning languages post. There are benefits to doing that, but there are also benefits to not doing that. This does, of course, assume you have a choice in the matter.
All this being said, on the dilemma of “which language should I spend my time learning”, I would argue, and have argued, that testers should learn many languages. See my following posts for examples:
- Why Test Engineers Should Learn Groovy
- Why Test Engineers Should Learn Scala
- Why Test Engineers Should Learn Ruby
Should you learn them all well enough to be an “expert”? Up to you, but I personally wouldn’t and haven’t. I’ve specialized in being a test solution developer by generalizing how much I know about various languages. I don’t plan on ever having expertise in any of these languages. I plan on being good enough in them to know when I would use them for a test solution in a given context.
Yet, even with that focus, I’ve never really articulated why this mattered or why I felt it was a good approach. I tried to talk about being cross-discipline associative but I’m not sure that made my point very well and, in fact, may have even confused it.
The dilemma that I stated at the beginning is framed by testers as this: “Yeah, but what if I’m wasting my time?!? What if I should have spent that time learning Language X, but I focused on Language Y?”
To my way of thinking, learning a programming language — any programming language — is never a waste of time. Further, what you learn in one language will translate over to what you learn in another. Perhaps not directly in all cases, but the thinking and analysis skills most certainly will translate. Still, though — I never articulated this well.
Then I came across the foreword to a book called Scala in Action. The foreword was written by Chad Fowler and it so nicely captured what I feel about the learning process that I quote it here:
You’re standing in front of a huge, steep wall of rock. Your neck is straining as you bend your head back as far as it will go to take it all in. If you squint, you can barely see something moving around at the top. There’s probably some really good stuff up there. You’ve heard from people you trust that it’s worth climbing this wall. But, you’re damned sure going to hurt yourself on the way up. You can already see some of the jagged edges jutting out. And what if it turns out that you don’t like what you see when you get there?
Learning difficult things is like this — and make no mistake: Scala is difficult to learn. And you may very well not like what you see when you get to the top. I’d guess that only a small fraction of developers learning a language like Scala ever put it to use. But it’s almost always the climb that makes a challenge worth the effort. Scala is a lot to chew on. It’s got what seems way too many features. It’s going to appear, at least initially, over-designed. You’re going to hurt yourself on the way.
By the time you reach the top, you’ll understand why those features exist, how they make your Scala programs better, and, more important, how they make you a more effective programmer. You’ll still be sore from the bumps along the way but that pain will help you remember the lessons learned.
Some of the concepts in Scala in Action are going to be more foreign than others. When you hit these bumps, take your time. Musicians don’t become great by playing the songs they know over and over. Elite athletes don’t consistently stay in their comfort zones. It’s the jagged edges that improve us.
If you approach this climb properly, you’ll reach the top sharper, more open-minded, and, best of all, less afraid.
The bolded parts are my emphasis. The “hurt yourself on the way” equates to what many testers seem to mean when they talk about wasting their time. But I think testers striving to improve their technical skills have to realize one thing: there is no waste of time in this context. Are there perhaps more efficient ways to spend time initially? Sure. And that will depend on your environment, which you should make an effort to determine. But nothing you learn in any programming language will be a waste. If nothing else, you will make learning your next programming language that much easier.
So pick a language and dive in!