As a tester it can be hard enough figuring out what technologies you should focus on to remain relevant in your career; not just at your current place of employment but at future ones as well. This gets even more difficult when there are “wars” within various communities about solutions and technologies. One such example is the supposed migration from Node.js to Go. So let’s talk about that.
The Challenge of Our Time
One of the key challenges that all of us in the IT world face is the rapidly changing technology set. We are surrounded by languages, libraries, frameworks, and so on. Assuming you have not specialized in one technology set, you often have to generalize a bit and learn just enough to know the basis of various technologies so that you can jump into them further should you need to.
That can be tiring. At least, it is to me. It’s fun, in a way. But still — it can be tiring. Particularly if you are trying to keep relevant in your career and stay ahead of the game, as it were.
Rails Fought Node — But Who Won?
There was a time when Rails was the cool thing to learn. People are starting to realize that while Rails still has a lot of benefit, Ruby is no longer the “cool kid on the block.” It’s matured, which is a good thing, but it also means that our industry, fickle as it is, begins searching for the new shiny objects.
Node.js, for some, is that new shiny object. As Rails started to “languish” a bit, according to some people’s opinion, it was felt that Node.js was stealing the thunder of Rails. Lots of people posted their thoughts on why they chose Node.js over Rails. Others, of course, told us the exact opposite and why they moved from Node.js to Rails.
There was a big hoopla about how LinkedIn and Twitter moved from Rails to Node.js, although some people tried to clear up the idea that it wasn’t because Rails sucked.
My point here isn’t to take sides. My point is to say the same thing is happening now with Node.js and Go.
Go with Node? Or Just Go?
Let’s take some immediate context here that is driving a lot of discussion. ExpressJS, which is a very popular Node.js framework, was recently transferred to a company called StrongLoop. The transfer of the Express repo by its creator TJ Holowaychuk to StrongLoop has left many wondering about the future of Express. Some people have expressed displeasure about how this transfer happened. For his part, TJ has stated his opinions and his rationale.
However, what sometimes gets lost in all that is this: the key driver here is that the reason TJ did this is because he is leaving Node. This, for many people was a wake up call. Some people clearly feel that TJ’s focus is possibly a bit misguided on this.
Yet, undeniably, as with the Rails-to-Node episode, many people have been expressing a desire to leave Node and head on over to Go. Consider:
- Why I Went from Python to Go and Not Node.js
- From Node.js to Go
- Why Did Koding Switch from Node.jsto Go
- The March Towards Go
- The Emperor’s New Clothes Were Built with Node.js
But, also as with the Rails-to-Node episode, people feel that this is not the right way to look at it:
- Why I Won’t Switch to Go
- Stop Fighting Node.js in the Enterprise
- Node.js is Taking Over the Enterprise
If you investigate this, you’ll find a fairly popular, if clearly biased, video that makes the rounds: Why Node and Scala will Dry Up. There have been some commentaries on this idea.
So … where does this leave you?
It leaves you in the same place you are often in if you keep your eyes open and ears to the ground regarding technologies to research. I recommend learning Node.js. I recommend learning Go. Learn just enough that you can understand the context and ecosystem in which they operate.
For example, people who already feel Go isn’t that great are already talking about Rust. Yet others are focusing on Nimrod. Yet others will tell you to look at Julia. And I suppose there’s still D. Oh, and let’s not forget Dart. And don’t forget that many peole are supposedly “leaving PHP” and going to Hack.
But here’s something to consider: if you are test solution developer, how much of those languages matter to you?
For me, what matters is if I can write test solutions in a given language and have it hit the application that I’m testing. So, for example, if I’m web testing, I can drive a web app with WebDriver and maybe Appium. And I can do that from Python, Ruby, JavaScript, Java, and C#. I can just pick my poison. I’ve used my own tool Symbiont, written in Ruby, to test applications written in Rails and in Java. I’ve also used it to test web apps and pure REST services.
So make sure you keep a clear separation in mind about why you are feeling like you have to learn so many languages. Many times, unless you are a developer, you don’t have to. Be aware of them, sure. Understand the trends in the industry, absolutely. But learning every nuance of every new flash in the pan and flavor of the month — not so much.
