I see a lot of discussion about how to learn a new tech stack. Whether you’re a frontend developer, interested in learning a backend langauge, or vice versa, or maybe you’re interested in branching out into more operational disciplines, like Kubernetes and Docker.

There are four basic approaches I’m aware of for this type of career move, and I’ve used each (except the first) in my own career, in various ways.

1. Go back to school. There’s always the option to just quit your job, and go back to school to learn something new. This is probably not a good approach for most of us, and I would advise almost everyone to skip this option. I only mention it to be complete.

2. Afternoons and weekends. This is probably the default option most of us consider. We grab a stack of Python books (or online tutorials), and hack away in our spare moments. But once you’ve learned something this way, there’s the problem of proving that you’ve learned it to a potential employer when you’re ready to change roles. Also, many people simply don’t have the time (or interest) in hacking in their spare time. For this reason, this approach is often best coupled with one of the following.

3. A new or side project at your current job. This isn’t possible in all companies, depending on size, management style, and other factors. But there’s often a good chance that you might be able to at least dabble in some new technologies in the course of your current role. This is how I first experimented with Go. My job at the time predominantly used Perl, so I volunteered to re-write a poorly performing service in Go. This is especially powerful if you’ve been learning a new technology in your spare time. Even a few hours per week at your day job using the new technology can let you legitimately put it on your CV.

4. On-the-job training. Many companies are willing to hire engineers who don’t have direct experience with their tech stack, as long as they believe they are willing and eager to learn. This is probably most common for up-and-coming technologies, where it may be difficult to find experienced developers already trained in that area. This may also be difficult to do very early in your career, before you have a track record, but even with as little as 2 years experience in another technology, I have hired people onto my teams to learn the technology we’re using.

There is no silver bullet if you want to make a lateral jump in careers, but these are some solid and proven approaches you can take to make a move if that’s where you want to go.

What other tactics have you used successfully to change technologies in your career?