J Cole Morrison
J Cole Morrison

J Cole Morrison

Developer Advocate @HashiCorp, DevOps Enthusiast, Startup Lover, Teaching at awsdevops.io

Complete Guides:

Finding Mastery in the Technology Field

Posted by J Cole Morrison on .

Finding Mastery in the Technology Field

Posted by J Cole Morrison on .

Finding Mastery in the Technology Field

From the outside looking in, the technology field looks like a magical wonderland of iron-willed entrepreneurs, Merlin-like hackers, 10x ninja developers, and exciting revolutions. Whether you're at a startup or an enterprise, if you're in the tech industry, then you've probably gotten questions like:

"Is it anything like that show Silicon Valley? I love that show!"


"Oh yeah, I watch Mr. Robot, can you do stuff like that?"

When you couple this with the relatively high compensation that tech workers get and the dominance of giant tech companies, fantasy and reality begin to blur. Not literally. But the messed up perception can be enough to confuse new entrants, annoy veterans, and lead to tech recruiters and companies using fantasy archetypes (wizard, mage, etc) in their job postings. And so, while fantasy may see us as energy drink fueled mad scientists, the reality is that most of the time we're just trying to keep our heads above water.

You see, the thing is this - all the movies and shows on hackers/programmers skip a fundamental piece that sports movies have never missed:

The Training Montage.

Sure, we show the aftermath of the brilliant developer cracking a system or building their app the day before a conference. But, aside from the fact that it'd be boring to watch, we don't show training montages because they'd be a never-ending loop. This is because, as workers in tech, we rapidly face something that most fields only flirt with.

Skill Depreciation

Everyday, there's a new tool or framework in our field. Everyday, there's a new tool or framework that's been declared "King" among the choices. And everyday, there's a tool or framework being deprecated or "sunsetted."

This means that as workers in tech, our skills rapidly depreciate. Pull aside any veteran and ask them how many languages or tech frameworks they know. If you're new to the field, then when they show you their long list of previous tools, you'll think they've got Batman's utility belt all for themselves. But the truth is that even though the experience always helps, they know that many things because they HAD to know. If you were writing flash applications or Java applets, then by default you had to learn something new as those went out of style.

And so, for many of us, that long track record of skills and tools is less like a superhero utility belt, and more like a storage unit. Sure, there's some good stories in there of working with Visual Basic...but I'm not going to pull that out in a new project. Plus, if it's been more than a year since I've touched a skill or tool set: (a) I'm not going to remember the finer details and (b) it's probably been updated and revamped to a point where I don't know it at all now.

This is very different from most fields. In law, for example, yes precedents and major cases will change things here and there...but for the most part, if you learn one foundation of the law, you can build more knowledge on top of that. The same goes for a skill like cooking where learning how certain foods respond to heat or understanding effects of composition and ratios in dishes won't have to be relearned.

"But Cole, what about all of the Computer Science fundamentals and principles??"

What about them? Sure, they're good to know, but unless you're working at a university, a think tank, or a specialized position at a big tech company...that's not your day-to-day. Your day-to-day work is building systems with tools and frameworks in which theory will have very little practical application.

What Causes the Skill Depreciation?

The positive part is that what causes this phenomenon is actually a good thing: rapid progress. Technology advances at an exponential rate, and thus it's insane to expect anything else.

However, the way it advances is what makes our job as tech workers so complicated. It advances through survival of the fittest, which in our field comes down to how well marketed, funded, and supported it is. Even though the most productive of the technologies should always win, as is human tradition, the most popular will almost always win. Especially if it can achieve the same result as the most productive technology with little loss in quality. And ESPECIALLY if it has a really cute mascot. The second one is probably more important.

This adds another gauntlet to our skill progression as workers in the tech field. With every technological advance, we generally get 100s of options in terms of tools that can be used in that advance. Mac, Linux, or Windows? Git, Mercurial, or SVN? Docker, LXD, or RKT? AWS, Azure, or GCP?

This wide selection is what makes progressing as a tech worker, and thus finding mastery, so difficult. Our progress with technology is largely based on the tools and skills we choose to learn. If we learn the right ones, great! Now we can capture some success from making the right decision. But if not...then it doesn't matter if we're aware of the general concepts of whatever change has come. Even though it'd be great if companies hired based on general knowledge and products could be built on white papers, that's just not how it works.

It's also not as simple as picking a skill set and going with it.

The Real Challenge is Making Good Bets

"What am I going to bet my time and mindshare on?"

Granted, this is the process for most things in life, but as tech workers, we do this with every new skill or technology we pick up. I'm also using the term "bet" because the fruits of our learning aren't rewarded on merit. If we learn a useless technology, no one cares that we know it. Furthermore, even if we pick the objectively correct technology, if we're subjectively wrong, we still lose.


Selecting the right technologies is like going to a messed up horse race where the winner isn't based on speed. Instead all of the horses are ready to go and everyone comes in and places their bets. However, the winner is based on whichever horse received the most bets. You know when the race is over because regardless of who's finished first, all of the folks who bet stand up and start saying things like, "Lucky Logan has won the race!" or "Lucky Logan has clearly won the war!" or in the fan club for Awesome Andy, intruders pop in with, "Why'd you pick Awesome Andy?? Lucky Logan has won the race!!"

Eventually one of the groups is loud enough to drown out the others and the race ends. Lucky Logan wins the race, even if it he wasn't the fastest. And now, since the restaurants and bars are only serving Lucky Logan supporters, everyone else must join their ranks.

A Non-Horse Betting Explanation

Okay, so my Louisville, Kentucky background made the previous analogy very clear...to me. But if it wasn't, here's a more direct explanation:

When a set of technologies come out that solve the same problem, the one that achieves network effects fastest is going to win. The more people that use it, the more valuable it gets. The more people that use it, the more likely a company is to adopt it, and the more likely said company is going to hire for it. If more companies are hiring for it, then more people are going to learn it.

When we combine that with the mere exposure effect, even more unsuspecting folks get pulled in. The way this effect works is simple - the more we see something, the more we like it ASSUMING that our first impression of it was neutral or positive. Well, if you've got a technology with network effects, then that means you likely have far more people discussing and posting things about it. If all the posts are "Why I use Lucky Logan" and "Lucky Logan is the best thing since sliced bread" or "Introducing Lucky Loganless!" ... folks new to this decision are going to give Lucky Logan a lot more consideration.

Bad Bets + Skill Depreciation = Difficulty in Mastering Skills

If what you know is always depreciating and if what you SHOULD know is this wonky betting game...well, finding any level of mastery is hilariously puzzling. I mean, you have to find comedy in it to stay sane if you've been in it long enough.

Mastery requires that you can invest time into particular skill sets to a point to where you don't have to think about them. This way, you can add more and more on top of them. This way, you can quit thinking about how to use a tool and instead focus on what to build with it.

Think about the best performers out there. If you've never done anything in music before, then watching an extremely expressive instrumentalist may be confusing to you. How do they 'express' the emotion? Well, having played guitar for over a decade, I can tell you it's about NOT having to think about the technical part of the music. It's about getting the notes and the song so ingrained into muscle memory that you no longer think about "playing" it. If you don't have to think about playing it, then you can focus on everything else around it. The emotion. The performance. The flair. The subtext.

Contrast this with modern web software development. No matter how long a developer has been in this game, I guarantee you that they spend a great deal of their time hopping between documentation, edge cases, and minute technical errors. Had this same developer been working with the exact same framework for 10+ years, then the workflow would be radically different. But considering that most of the modern web frameworks out there haven't stayed the same for a full decade, this shouldn't be surprising. Though, I suppose at this point we could point out that adapting to constantly changing tools and skills is a skill in and of itself.

And so, though deliberate practice and discipline are usually the alpha and omega for mastery in many fields, for technology skills and tools, it begins with making a good bet.

Making a Good Bet

First, I want to separate GOOD from RIGHT. I've done it a bit already with my long-winded Derby analogy, but just to be clear...a good bet doesn't mean a RIGHT bet. Is HTML really the RIGHT thing for us to be creating full-scale applications with? After all, it was made to create...documents...not apps. Well, does it really matter? It was a GOOD bet if you picked it up.

Second, we're talking about skills and tools that you'd pick up for a return on investment. Not hobbies.

That being said, there's 4 things to look out for in a good bet:

1 - It's Been Around, Will Be Around

Yep, I know, I know, I know. This rules out all of the sexy, bleeding edge technologies. However, unless you've got insider knowledge that gives you 100% certainty that the bleeding edge technology you're looking to learn and master will absolutely make it...wait. Wait for the crazy technology Derby to happen and shake itself out. Sure, experiment around, but don't over invest yourself in it. Remember, we're looking for MASTERY which REQUIRES the technology of interest to be around.

On a side note, I'd say that frameworks and tools that have an identity crisis every other month, and rewrite themselves entirely, would not count here.

2 - It's in Demand

If companies are demanding a particular skill set, then it signals more than just job security. It suggests that the skill/tool/technology can actively produce value. No, it may not produce the MOST value that alternative "losing technologies" might, but it must produce enough.

If it's in demand, that means its ability to give you a return on investment is far greater. This means the likelihood that you'll be able to sustain continued skill development with it is also higher.

3 - It's Legitimately Useful and Value Adding, From a Tech Perspective

It can be around. It can be in demand. But, since you're in technology, and since you've responsibly experimented with alternatives (you have right?), then you can probably get a sense of its usefulness.

The question you have to ask yourself is whether or not the technology being used is just in a popularity bubble or if it's legitimately value adding. Company judgement of a technology is one thing, but they're far more protected. As long as their customers are happy, they can use the same tech stack as long as they'd like to. Having done work in the car insurance industry, it's amazing how many of the firms out there are still operating on old CRTs, outdated mainframes, and DOS.

However, unless you're planning to stay with that company indefinitely, the moment you leave...what you know better translate to other companies. In the end, demand and track record will take a technology far, but if it's not legitimately useful and value adding, it'll be discovered for what it is OR new alternatives will pop up in its place.

4 - And....It's Popular

Though I wish we could factor this out of the decision...we can't. No, it doesn't need to be the Derby winner, but it should be in 2nd or 3rd place. This is not about paranoia and following lemmings off a cliff. It's about mastery. If no one uses it, what barometer will you use to judge yourself by? What places will you go to to find support and answers? Who will you discuss the technology and formulate ideas with?

Sure, it can feel like justice has been served by going with an obscure underdog. However, unless this is some inconsequential tool (which suggests you're not trying to develop mastery with it), then you'll regret that decision when you're up at 3 AM dealing with an esoteric bug that no one has heard of.

And so our final criteria here is a necessary evil. It's a means to the end, but without it, there won't be much of a path to walk on.

But I want to innovate!

Absolutely! For some fields and interests, you're going to have to play this never-ending game of catch up. However, for a lot of businesses out there, that's not the case. You have your company's stack and tool chain and that's what you work with.

The thing is this - at some point you've got to ask yourself, "Am I trying to learn indefinitely, or do I want to build something? Do I want to take something to the next level??" And if you DO want to build something and take it to the next level, you need the foundations you're building it with to be stable. But if your building materials change every other month, along with the instructions on using them, then you won't get far in anything beyond...learning and re-learning.

Learn What's Stable, Build What's Exciting

No, picking up the more stable tools and skills isn't as fun to talk about with co-workers as the latest trending topics. However, those "boring" technologies will let you work on them and understand them without fear that they'll disappear or radically change. This means that what you learn today will carry over to what you learn next year. Think about skills like Linux and SQL. These two are examples of technologies that, had you learned 10 years ago, would still be applicable and helpful today. But learning BlackBerry app development...not so much.

If what you're learning is aggregating and compounding, it means you'll be able to think past the HOWs on everything you do and begin to focus on WHYs. It means you can begin to build something exciting without having 20 browser tabs of "X vs. Y" open. It means that you can finally find some stability in this crazy, ever-changing field of ours.

J Cole Morrison

J Cole Morrison


Developer Advocate @HashiCorp, DevOps Enthusiast, Startup Lover, Teaching at awsdevops.io

View Comments...
J Cole Morrison

J Cole Morrison

Developer Advocate @HashiCorp, DevOps Enthusiast, Startup Lover, Teaching at awsdevops.io

Complete Guides: