So you’ve been at your company for a couple of years. Your parents tell you to stick around for another five, but other people in tech - and your adventurous self - tell you it’s about time to learn something new. What if you could do both? The most common path to take in order to learn something new, advance your career, increase your salary or simply Change Things Up A Bit involves leaving your company for something else. This is especially true in tech. (Sadly, the salary part is especially true in tech; to the point where just about the only way to get a raise is to say that you’re leaving for a better deal, and either take the deal or the inevitable counter-offer from your current workplace. Not cool.)

Restlessness isn’t all bad

After about two years @ Vipps, I honestly almost left. I had learned a lot from a lot of great people, and I had made some cool stuff that I’m still quite proud of (and a few things that make me cringe a bit). But I’m more of a pioneer than a maintainer, and my need for adventure kept rising, and it felt like I could do most of my day-to-day work half asleep. I missed the thrill of being in over my head, fighting to learn and fighting to work fast enough and good enough to keep up. At the time I was taking point on both recruiting and onboarding new Golang developers, and I also had gathered a few interesting programming books for both new and seasoned developers. As I skimmed through Lex Sheehan’s “Learning Functional Programming in Go” (which – spoiler alert – basically tells you all the ways in which Golang is not suited for functional programming…), I somehow got caught up in the concept of Tail-call optimization. I did an unnerving amount of research and tried to find a sane, popular and useful programming language that did elegantly support this. I found Kotlin.

Let’s learn something new!

Before I knew it, I had applied for a position as an Android Developer. Where? @ Vipps. The thrill was back, but my friends were still nearby, as well as some of Norway’s finest Android guys. I got to know new people, but we didn’t start completely from scratch. I got to do something other and learn something completely new, but – and this is quite an interesting part – I was still treated like a senior developer. I had a track record at the company that gave me a head start I would have completely missed out on if I left. True, I could have taken on a position more similar to the one I had, but that would sort of defeat the purpose of changing jobs in the first place. When transferring within the company, it turned out, I could make an even bigger change. Trust was established, and we shared both history and values.

Changing jobs is always a gamble, and you can’t always go back if you have second thoughts. I think this limits the amount of change and risk we’re willing to take, and understandably so: the friction involved when breaking up with your company is not minor in any way, and if things go sour you’re stuck between a rock and a hard place. But I knew that I could actually go back, without the disgrace and discomfort usually involved. The whole job change was framed as a mutual experiment, which again enabled me to make a bigger leap than I would normally dare. How about that?

So how did it go?

I ended up not going back, and I think the switch has made me an overall better developer. There are definitely a few domain-specific things that one needs to learn from scratch, but at the end of the day, we’re programmers, tech leads, architects, problem solvers, code reviewers and team players – regardless of platform and language. Not everything you learn will be directly transferable to other areas, but your overall understanding of tech, product and problem-solving will improve nonetheless. And, to be a bit technical it turns out my timing was awesome. Jetpack Compose is the new big thing in Android, and it’s basically kind of React ¯\(ツ)/¯. So long, RecyclerView and XML; our brief encounter was more than enough! Bonus perk: When I get bored and fed up with doing Android all day, I have quite a few opportunities to help out on projects that require skills from my pre-app developer era at Vipps, which I enjoy a lot more now than when that was all I did. Win-win!

What if my boss says no?

• Tell him/her to read this post and reconsider.
• Ask “what would this switch have to look like in two months to be considered a success?”, and commit to reaching those goals. Chances are they’re more reasonable than you’re afraid of.
• Willingly submit yourself to be coached and evaluated regularly. What if you actually nail this?
• Agree on a mutual escape clause. What if the grass wasn’t greener on the other side after all? Or what if you didn’t quite have what it takes to succeed in that other area (yet)? If so you should have a plan on how to celebrate finding it out in the safe context of a healthy experiment. (I assure you, this is still cheaper than replacing you!)
• Although this shouldn’t be your opening line, the fact is: When push comes to shove it might boil down to whether or not you make the switch within the company or leave the company.

️Notice the helmet ☝️