TranslateProject/sources/tech/20190816 How to plan your next IT career move.md

[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to plan your next IT career move)
[#]: via: (https://opensource.com/article/19/8/plan-next-IT-career-move)
[#]: author: (Matthew Broberg https://opensource.com/users/mbbroberghttps://opensource.com/users/marcobravo)

How to plan your next IT career move
======
Ask yourself these essential career questions about cloud, DevOps,
coding, and where you're going next in IT.
![Two hands holding a resume with computer, clock, and desk chair ][1]

Being part of technology-oriented communities has been an essential part of my career development. The first community that made a difference for me was focused on virtualization. Less than a year into my first career-related job, I met a group of friends who were significant contributors to this "vCommunity," and I found their enthusiasm to be contagious. That began our daily "nerd herd," where a handful of us met nearly every day for coffee before our shifts in tech support. We often discussed the latest software releases or hardware specs of a related storage array, and other times we strategized about how we could help each other grow in our careers.

> Any community worth being a part of will lift you up as you lift others up in the process.

In those years, I learned a foundational truth that's as true for me today as it was then: Any community worth being a part of will lift you up as you lift others up in the process.

![me with friends at New England VTUG meeting][2]

Matthew with friends [Jonathan][3] and [Paul][4] (L-R) at a New England VTUG meeting.

We began going to conferences together, with the first major effort by being the volunteer social team for a user group out of New England. We set up a Twitter account, sending play-by-plays as the event happened, but we also were there, in person, to welcome new members into our community of practice. While it wasn't my intention, finding that intersection of community and technology taught me the skills that led to my next job offer. And my story wasn't unique; many of us supported each other, and many of us advanced in our careers along the way.

While I remained connected to the vCommunity, I haven't kept up with the (mostly proprietary) technology stack we used to talk about.

My preferred technology shifted direction drastically when I fell in love with open source. It's been about five years since I knew virtualization deeply and two years since I spoke at an event centered on the topic. So it was a surprise and honor to be invited to give the opening keynote to the last edition of the [New England Virtualization Technology User Group][5]'s (VTUG) Summer Slam in July. Here's what I spoke about.

### Technology and, more importantly, employment

When I heard the user group was hosting its last-ever event, I said I'd love to be part of it. The challenge was that I didn't know how I would. While there is plenty of open source virtualization technology, I had shifted further up the stack toward applications and programming languages of late, so my technical angle wouldn't make for a good talk. The organizer said, "Good, that's what people need to hear."

Being further away from the vCommunity meant I had missed some of the context of the last few years. A noticeable amount of the community was facing unemployment. When they went to apply for a new job, there were new titles like [DevOps Engineer][6] and [SRE][7]. Not only that, I was told that the deep focus on a single vendor of proprietary virtualization technology is no longer enough. Virtualization and storage administration (my first area of expertise) appear to be the hardest hit by this shift. One story I heard at the event was that over 50% of a local user group's attendees were looking, and there was a gap in awareness of how to move forward.

So while I enjoy having lighthearted conversations with people learning to contribute to open source, this talk was different. It had more to do with people's lives than usual. The stakes were higher.

### 3 trends worth exploring

There are a thousand ways to summarize the huge waves of change that are taking place in the tech industry. In my talk, I offered the idea that cloud, DevOps, and coding are three distinct trends making some of those waves and worth considering as you plan the next steps in your IT-oriented career.

  * Cloud, including the new operational model of IT that is often Kubernetes-based
  * DevOps, which rejects the silos, ticket systems, and blame of legacy IT departments
  * Coding, including the practice of infrastructure as code (accompanied by a ton of YAML)



I imagine them as literal waves, crashing down upon the ships of the old way to make way for the new.

![Adaption of The Great Wave Off Kanagawa][8]

Adaption of [The Great Wave Off Kanagawa][9]

We have two mutually exclusive options as we consider how to respond to these shifts. We can paddle hard, feeling like we're going against the current, or we can stay put and be crushed by the wave. One is uncomfortable in the short term, while the other is more comfortable for now. Only one option is survivable. It sounds scary, and I'm okay with that. The stakes are real.

![Adaption of The Great Wave Off Kanagawa][10]

Adaption of [The Great Wave Off Kanagawa][9]

Cloud, DevOps, and coding are each massive topics with a ton of nuance to unpack. But if want to retool your skills for the future, I'm confident that focusing on **any** of them will set you up for a successful next step.

### Finding the right adoption timeline

One of the most challenging aspects of this is the sheer onslaught of information. It's reasonable to ask what you should learn, specifically, and when. I'm reminded of the work of [Nassim Taleb][11] who, among his deeply thoughtful insights into risk, makes note of a powerful concept:

> "The longer a technology lives, the longer it can be expected to live."
>  – Nassim Taleb, [_Antifragile_][12] (2012)

This sticking power of technology may offer insight into the right time to jump on a wave of newness. It doesn't have to be right away, given that early adopters may find their efforts don't have enough stick-to-it-ness to linger beyond a passing trend. That aligns well with my style: I'm rarely an early adopter, and I'm comfortable with that fact. I leave a lot of the early testing and debugging of new projects to those who are excited by the uncertainty of it all, and I'll be around for the phase when the brilliant idea needs to be refined (or, as [Simon Wardley][13] puts it, I prefer the [Settling phase over the Pioneer one][14]). That also aligns well with the perspective of most admin-centric professionals I know. They're wary of new things because they know saying yes to something in production is easier than supporting it after it gets there.

![One theory on when to adopt technology as its being displaced][15]

What I also love about Taleb's words is they offer a reasonable equation to make sure you're not the last to adopt a technology. Why not be last? Because you'll be so far behind that no one will want to hire you.

So what does that equation look like? I think it's taking Taleb's theory, more broadly called the [Lindy effect][16], and doing the math: you can expect that any technology will be in existence at least as long as it was before a competitor came into play. So if X technology excited for 30 years before Y threatened its dominance, you can expect X to be in existence for another 30 years (even if Y is way more popular, powerful, and trendy). It takes a long time for technology to "die."

My observation is more of a half-life of that concept: you can expect broad adoption of Y technology halfway through the adoption curve. By that point, companies hiring will start to signal they want this knowledge on their team, and it's reasonable for even the most skeptical of Sysadmins to learn said technology. In practice, that may look like this, where ETOA is the estimated time of mass adoption:

![IP4 to IP6 estimated time of mass adoption][17]

Many would love for IPv6 to be widely adopted sooner than 2027, and this theory offers a potential reason why it takes so long. Change is going somewhere, but the pace more aligned with the Lindy effect than to those people's expectations.

To paraphrase statistician [George Box][18], "all models are wrong, but some are more useful than others." Taleb's adaptation of the Lindy effect helps me think about how I need to prioritize my learning relative to the larger waves of change happening in the industry.

### Asking the right questions

The thing I cannot say often enough is that _people who have IT admin skills have a ton of options when they look at the industry_.

Every person who has been an admin has had to learn new technology. They excel at it. And while mastery takes time, a decent amount of familiarity and a willingness to learn are very hirable skills. Learning a new technology and inspecting its operational model to anticipate its failures in production are hugely valuable to any project. I look at open source software projects on GitHub and GitLab regularly, and many are looking for feedback on how to get their projects ready for production environments. Admins are experts at operational improvement.

All that said, it can still be paralyzing to decide what to learn. When people are feeling stuck, I recommend asking yourself these questions to jumpstart your thinking:

  1. What technology do you want to know?
  2. What's your next career?



The first question is full of important reminders. First off, many of us in IT have the privilege of choosing to study the things that bring us joy to learn. It's a wonderful feeling to be excited by our work, and I love when I see that in someone I'm mentoring.

Another favorite takeaway is that no one is born knowing any specific technology. All technology skills are learned skills. So, your back-of-the-mind thought that "I don't understand that" is often masking the worry that "I can't learn it." Investigate further, and you'll find that your nagging sense of impossibility is easily disproven by everything you've accomplished until this point. I find a gentle and regular reminder that all technology is learned is a great place to start. You've done this before; you will do so again.

Here's one more piece of advice: stick with one thing and go deep. Skills—and the stories we tell about them to potential employers—are more interesting the deeper we can go. Therefore, when you're learning to code in your language of choice, find a way to build something that you can talk about at length in a job interview. Maybe it's an Ansible module in Python or a Go module for Terraform. Either one is a lot more powerful than saying you can code Hello World in seven languages.

There is also power in asking yourself what your next career will be. It's a reminder that you have one and, to survive and advance, you have to continue learning. What got you here will not get you where you're going next.

It's freeing to find that your next career can be an evolution of what you know now or a doubling-down on something much larger. I advocate for evolutionary, not revolutionary. There is a lot of foundational knowledge in everything we know, and it can be powerful to us and the story we tell others when we stay connected to our past.

### Community is key

All careers evolve and skills develop. Many of us are drawn to IT because it requires continual learning. Know that you can do it, and stick with your community to help you along the way.

If you're looking for a way to apply your background in IT administration and you have an open source story to tell, we would love to help you share it. Read our [information for writers][19] to learn how.

--------------------------------------------------------------------------------

via: https://opensource.com/article/19/8/plan-next-IT-career-move

作者：[Matthew Broberg][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]: https://opensource.com/users/mbbroberghttps://opensource.com/users/marcobravo
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/resume_career_document_general.png?itok=JEaFL2XI (Two hands holding a resume with computer, clock, and desk chair )
[2]: https://opensource.com/sites/default/files/uploads/vtug.png (Matthew with friends at New England VTUG meeting)
[3]: https://twitter.com/jfrappier
[4]: https://twitter.com/paulbraren
[5]: https://vtug.com/
[6]: https://opensource.com/article/19/7/how-transition-career-devops-engineer
[7]: https://opensource.com/article/19/7/sysadmins-vs-sres
[8]: https://opensource.com/sites/default/files/uploads/greatwave.png (Adaption of The Great Wave Off Kanagawa)
[9]: https://en.wikipedia.org/wiki/The_Great_Wave_off_Kanagawa
[10]: https://opensource.com/sites/default/files/uploads/greatwave2.png (Adaption of The Great Wave Off Kanagawa)
[11]: https://en.wikipedia.org/wiki/Nassim_Nicholas_Taleb
[12]: https://en.wikipedia.org/wiki/Antifragile
[13]: https://twitter.com/swardley
[14]: https://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html
[15]: https://opensource.com/sites/default/files/articles/displacing-technology-lindy-effect-opensource.com_.png (One theory on when to adopt technology as its being displaced)
[16]: https://en.wikipedia.org/wiki/Lindy_effect
[17]: https://opensource.com/sites/default/files/uploads/ip4-to-etoa.png (IP4 to IP6 estimated time of mass adoption)
[18]: https://en.wikipedia.org/wiki/George_E._P._Box
[19]: https://opensource.com/how-submit-article