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 if you are going to work in a Ruby shop, learning Ruby would be really good. But what happens if you then end up working in a Java shop? In that case, learning Java would be really good. Ah, but what if you are in a Ruby shop and a Java solution would be a more effective language for your test solution? Or vice versa? And what if you end up somewhere where they prefer Python or C# or something else? Or what if you work somewhere where they use C++, Perl, and Clojure. (Hey, trust me: it can happen.) And even with all that, what if you want to build a test solution that also has a web interface. Now you might need JavaScript even if your core test solution is in some other language.
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!
Nice post, which language did you chose at last ? Scala ??
I haven’t really chose one, per se. Most of my test solutions are written in Ruby at the moment. Any Java-based dynamic languages still don’t quite have the facility of Ruby, in terms of maximum flexibility for DSL creation, as just one example. (At least so I’ve found; I’m still learning.) That said, a key point I believe is that any programming language we use informs the way we think about and solve problems that require developing solutions.
So, with that thought in mind, lately I’ve been looking at how tools like JBehave integrate with JUnit or how SpecFlow integrates with NUnit. I want to start tailoring some of my solutions in that regard. In the Ruby world this would mean tying my solutions more directly to a runner, like RSpec. I’ve also been studying how tools like GSpec, Easyb, and Spock (for Groovy) or ScalaTest and Specs2 (for Scala) work. This has allowed me to leverage JRuby to sort of bridge the divide but also get myself into the Java camp should I want to go that route.
I really like Scala but I find that for test solution development, it’s currently a bit of overhead that isn’t needed. Groovy is often a much better solution. (I say that relative to the context I work in, not as a value judgment of which language is “better.”) Groovy much more closely aligns with the good parts of Ruby and it also aligns much more closely to Java. All this being said, however, I absolutely like how Scala works and I am eager to re-craft some of my test solutions in Scala to get a better idea of what is and is not possible.
“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.”
I think you just nailed it.
i too faced such dilemma about what to learn??.
i liked the way u said ” it’s almost always the climb that makes a challenge worth the effort. “..
thats true what ever we learn adds as a skill set and never goes waste..
learning should never stop..your post is an amazing boosting for beginners ..just to dive in and excel