When And How to Give New Tech a Try

At the start of each new year, after the festive season and the time catching up with friends and family, we likely have more free time than we do throughout the rest of the year. And if you and I are anything alike, this means that you have the opportunity to indulge in your passion for technology, whether that's software, hardware, networking, hacking, or whatever else.

Given that, perhaps you've been keenly waiting for a bit of a break around this time, so that you can learn something new -- something you've been wanting to try for so long. If so then, before you begin, I want to share my five rules for when and how to give new technology a try. That way, you can get the most out of your time spent.

Say you're a web application developer, but you find that you've been spending a lot of time tediously provisioning or deploying the applications you develop, using custom shell scripts.

The process works, but it's taking time away from your core focus, which is where you'd much rather spend your resources. You don't mind automating the deployment process, but your boss would rather that you focus on the code. Here you have the best of all reasons to learn a new technology. You have a clear, pressing need to learn something, so that you can get back to designing and writing code.

To a greater or lesser extent, you've already become familiar with how the deployment process works. Perhaps doing so is even something that you enjoy. If you're not careful, your core skills may end up going by the wayside, in favor of what you're about to invest in. Either way, now you have the opportunity to broaden your horizons and build a set of complementary skills.

What's more, it should be a no-brainer to justify the time and expense for one or more courses or books on relevant tools, such as Vagrant, Ansible, Puppet, and Chef. Whether to yourself or your boss, you can clearly demonstrate that, by learning these skills, you can reduce the time required for provisioning and deploying and get back to your development tasks.

If improved efficiency and focus aren't enough to convince you to try out new complementary tech, here's something else to consider: Do you enjoy spending all your time using one set of skills? Or would a bit of variety make your days more rewarding and challenging?

I can't speak for you, but that's why I got into technical writing. While I love software development and I also love technical writing, I wouldn't want to do either full time. By being able to switch between the two, I give myself variety. I'm also able to give myself the ability to look at what I do more critically and see if I'm becoming too dogmatic.

Regardless, by having complementary skills, we become more valuable to current and future employers and clients. We become more rounded as individuals. And we will likely enjoy what we do so much more.

This is one situation you may relate to, you may even agree with, but which, when push comes to shove, you may not do anything about: the need to get out of your comfort zone! Every one of us has one. We readily say that we need to challenge them, to confront them, even to step outside of them. But how often do we?

In the previous section, I suggested learning new technology when it complements our existing skills. But, let's now be contrarian. What about learning new tech when it's challenging?

For example, let's say that for your entire career, you've always been into software and left hardware to others. However, because of the rise of IoT (the Internet of Things), you've had your interest piqued and want to get to know hardware better. Sound like a reasonable expectation? But to get the most out of something, you have to genuinely know how it works.

Say you've chosen Arduino as your platform of choice, and you want to build a home-monitoring station. Specifically, the station will record:

• Ambient air temperature

• Humidity

• Light levels

• Wind speed

Given that, the Arduino board will need to have sensors to measure each of these environmental factors. Do you know how the sensors work? Do you know their thresholds? Are you aware of their maximum tolerance levels? If you don't, can you genuinely be sure you're getting the most out of the device?

In situations like this, you'll have to step away from your comfy software home and go somewhere you normally wouldn't. You'll have to become deeply familiar with the hardware, how it's built, and how it works.

That may seem trivial, but it's not. Hardware doesn't work in the same way as software. It's nowhere near as malleable. You'll have to think differently. You'll have to challenge your preconceptions.

But, if you do so, as one of my mentors once told me, you'll come out the other side much the better for it.

This is one of the most pragmatic reasons to learn new technology. We can become so engrossed in a technology, such as PHP or Linux for me, that we forget to take a look around. But the landscape in technology changes so often and so frequently. What's hot today won't be hot for long.

Take Ruby, Ruby on Rails, Node, or Go as four excellent examples. All three of these were what "the cool kids" were using at one time or another. And, if people were hiring, these skills were always in high demand. Depending on who you were hanging around, if you didn't know them or have some passing familiarity with them, you weren't going to be seen as up with the times.

However, consider each of them in turn. Are they still the languages and frameworks to know if you want to get ahead? Or has one or more of them lost their allure? To the best of my knowledge, Go (and to a lesser extent Node) still have a good amount of luster attached to them. But Ruby and Ruby On Rails no longer have the sparkle of novelty behind them.

Bear this in mind before you get too settled with whatever technology mix you have. And keep an eye on the ever-changing landscape, so that you stay abreast of coming trends. If you see something that looks promising, something companies and employers are starting to ask for, and that you feel interested in, perhaps it's time to invest some hours in a project to learn it.

For what it's worth, I'm not encouraging you to learn something just for career change or advancement. The last thing I'd want to see you do is to spend your time learning and using something you hate just for money. But if you can combine an interest and career growth, then I strongly encourage you to try it out and see where it takes you.

Now I'm going to throw you a curveball and riff off of my earlier point. As I said, technology ages. But, before that happens there will be a large number of projects implemented with it, leading to a large number of organizations depending on it.

Given that, while new and exciting projects may not be built with it anymore, there will be a prescient demand for suitably skilled people to maintain legacy projects. Have you considered learning a legacy technology to cash in on this opportunity?

This might sound incredibly counterintuitive. But stop for a moment and give it some thought. While new and “exciting” projects may not be built with it anymore, I'd suggest that there will be considerable opportunity for different experiences as a result of working with a range of different organizations who'd need your help.

Then come the follow-up opportunities. Eventually, most organizations will likely bite the bullet and commit to transitioning away from a technology when it's clear that the end is near. As you see this time coming, you have the opportunity to continue to profit by combining your knowledge of and experience with, the legacy technology, its quirks, pros and cons, and help guide the transition to the new technology mix.

Now you get to use your skills all over again.

This has to be my all-time favorite. Let's say that you've been considering learning a new software language, following the espoused philosophy in The Pragmatic Programmer to learn a software language each year.

But the question is, what language should you learn? You've looked around and narrowed the list down to three. But all of them are equally compelling. As a result, you can't make a final choice.

I was in this very position myself back in November of last year, weighing several languages for value and potential. A little while later, an opportunity presented itself. I was on a project where I had to do some DevOps work, reviewing an Ansible provisioning setup. The work needed a script to validate the semantic versioning of a set of packages and in walked my itch to scratch.

One of the languages I'd been considering was Ruby, and it was a perfect fit for the task. To be fair, I could have written the fix in Bash. But I went with Ruby anyway and documented my work and rationale for choosing Ruby. It took a little extra time than it otherwise might have. But, at least to my mind, the portability aspect felt sufficient to justify my decision.

And here's another reason why I feel that this is the best reason to learn new technology: When you have an itch to scratch, you have a hands-on, practical reason to learn something new. If it's just for academic reasons, I don't believe that you invest of yourself with the same level of passion nor will your decision-making process be as practical. When you have a specific need, however, I believe your choices are weighed and measured as in real-life and, consequently, they tend to be much more thought through.

Now that we've gone through four great reasons for learning a new technology, it’s only fitting to finish up by considering when not to learn one. It's something that's particularly apt in IT — the concept of the current "hot thing," the latest fad or trend, the KoolAid, and so on.

Just as I never recommend reading a book just because "everyone else" is reading it, I never encourage someone to learn a new technology just because it's the flavor of the month.

That's not to say that I actively encourage you to avoid a technology just because it's popular. Not at all. For example, in the PHP space there's Laravel, and in DevOps there's Docker. These are two great technologies with an enormous amount of traction. Both of them are well worth a majority of the hype that surrounds them.

https://js.hscta.net/cta/current.js

hbspt.cta.load(1169977, '05489183-4551-4d0e-a73f-b2bb8d741274', {});

But if something has gained a viral element, I tend to feel that in all the excitement, a lot of critical thinking may get thrown under the bus. What's more, I also fear the herd mentality may come into effect and sweep us all along.

Choosing new tech isn't like picking out a new book. If we start reading something new, there's no obligation either to finish it nor to read every other work by that author. However, if we start learning some new technology and create something with it, something that other people use, then we've linked a part of our reputation to that decision. What's more, if you're going to start learning something, it's not something you can accomplish overnight.

I'm not suggesting that you need to invest the minimum 10,000 hours that Malcolm Gladwell suggests is necessary to controller something. But there's going to be, I'd suggest, around a few hundred hours invested before we can become truly proficient with something. Do you want to spend all that time -- and potentially build libraries, applications, or some other service people may come to depend upon -- only to leave it all behind?

So if something is trending on GitHub or on social media, find a quiet place and ask some tough questions, such as:

• Is it actually worth it?

• What are the faults?

• What are the valid use cases for it?

• Who's behind it, and how committed are they to it?

The technology could be just fine. But don't go learning it just because you fear being left behind.

And those are my five rules for when and how to give new technology a try. I don't expect that you'll agree with me on each and every one of them. But I hope that they help you, if you have the semi-constant itch as I do, to try out new technologies, services, software languages, and everything else that goes with the tech scene. It's never been a more exciting time to be involved in the industry.