Switching Careers from Product to Engineering: First Job as a Programmer

A month ago, on October 1st, I started my first job as a programmer. It's a significant shift for me after ten years in strategy and product, and I'm still not used to this new identity even almost a month in. I now work for a Dutch company based in The Hague, but I'm remote from Amsterdam while the pandemic continues worldwide. We combine in-house apps for ourselves with building apps for others in the Atlassian ecosystem, a marketplace with over 2,000 apps to extend their products (and growing). I work primarily with Javascript, React, and Typescript, and I'm learning a lot about APIs and integrations through creative new ways to twist things to work in the Atlassian world. Anyway, I binged article upon article about other people's personal experiences while learning how to code, so I feel compelled to give something back. So I figured the answers to the most common questions I got from friends, family, and other people learning to code might be of interest. ## Why the switch? I moved over to rediscover an old passion, challenge myself. I'd done product-y things for so long, it was no longer appealing or exciting. The upwards trajectory towards product leadership removes you more and more from the interesting stuff. It made me realize I'm happier closer to the proverbial coalface of where products are made, rather than the boardrooms. Anyway, most of our lives run on code one way or anoyher. We read, decide or even date people based on what other people's code tells us to do, so ... why not create the code myself? At some point I'd love to even teach it, because I look around and weep at how little our politicians and schools know about it. But it'll be some time before I do. On a related note, I had coded from primary school well into high school, but not in any serious capacity beyond school projects. In 2007, in Romania, when neither the Kindle nor the iPhone had yet launched, programming didn't appeal to a career choice. I didn't know anyone who worked as a programmer or talked casually about programming careers. So my life took a different path through the UK and the US, and fifteen years of no coding later, I remembered virtually nothing from all the C++, Pascal, and Visual Basic I'd touched in school. The turning point happened in San Francisco, where I was lucky to work with some fantastic programmers and technical leads. They made programming and problem-solving fun and became the role models I never had as a teen. ## Some specifics Everyone's journey will look different, but mine not as neat as the stories I read online. **I didn't switch to make more money.** I did it because it's a genuinely interesting and broad field where you're always learning new things. Money is nice, more money even nicer, but it's not everything in life. If I wanted money, I'd have stayed in San Francisco but would've been a more anxious, highly-strung person as a result. **I didn't go to boot camp or university.** I made my own curriculum, with help from people more senior than me, and more or less followed that, with small detours along the way. I've worked with many people who graduated them and don't rate or recommend either, though tech leads would still rank a CS degree more valuable than boot camp. In short, it boils down to either being taught the wrong things or not enough of what matters on the job. **I didn't code on the side until I could make the jump.** That is sane advice that most people could and should follow before big changes. Sometimes, the parachute will appear after you jump because you'll create it out of necessity. As it happened, I went through burnout, a divorce, and a country move from the US to the Netherlands. It took me 6-9 months while learning a new language in parallel. In short, what doesn't kill you makes you weirder. So what it boiled down to was deciding to do it and doing it. ## "What advice would you give someone starting out?" **1. Put yourself first, and don't get too caught up in your identity or group belonging.** I know we're social creatures who need to belong. But learning to code is a marathon, not a sprint. So that means putting your sanity and knowledge first, the two things you're in direct control over. During my journey, I saw many people wonder, 'When can I call myself a real developer? Or should it be a programmer?' My advice: the less you think about this, the better. You can be a 'professional' when someone pays you for a good or service. Otherwise, there's no shame in being an apprentice or hobbyist. Either way, engineering skills are problem-solving skills, and the world of software is vast. Don't box yourself into a genre when you haven't explored so much of it. Worry about what you (want to) know and your mental models, and whether you're a happy, healthy, and balanced human being. **2. Learn as little as possible.** I'm serious. This seems counterintuitive and warrants its own post, but I had to re-learn how to learn. If you try to know everything, you'll go a bit crazy. You can ask 'why' forever until you reach either the abacus or electron spin and speed of light. My advice is to spend most of your time on the areas most relevant to you getting paid and learn the least amount of stuff to make progress. This will help you focus on the most important, relevant, and accurate information. One thing I did whenever I came across a new topic was to ask and research the answer to, "What do people who might want to pay me \[e.g., engineering managers] think is important to know about this?" Everyone has opinions, and people disagree, but even opinions eventually converge into a list of "must-know" and "nice-to-know" things. So learn as little as possible, so long as it's the most relevant thing that can move you further. Everyone knows there's too much to learn, and you'll inevitably be slow, forgetful, or inexact, either the interview or on the job. That's life. Good employers and managers know it can be overwhelming and that the learning never stops. **3. Learn how to get yourself unstuck.** When you get stuck and still don't know how to do things, your brain will go weird and want to nope out of the discomfort. My advice is to learn techniques to manage your time and get yourself unstuck based on your situation and personality. First, figure out how much you will (or can) spend on an issue something before reaching out to someone else. Then, if I have time, my personal favorite approach is to write things down, coupled with George Polya's system from 'How to Solve It.' It deserves a post of its own but revolves around making connections between 'what you have' and 'the unknown' you want to get to, asking things like, "What happens if I do X?" Or, "If I want to get to/achieve Y, what can I do with what I have?" When being at my desk just won't work, it's nice to go for a walk, sometimes vent, and leave things unfinished to take advantage of the [Zeigarnik effect](https://memory.ai/timely-blog/zeigarnik-effect-productivity). If you can practice these alongside coding, you're halfway on the road to being a good debugger who can ask thoughtful questions. This is still something I'm working on, but trial and error and thinking about my thinking helped me overcome challenges I didn't feel as much when I wasn't coding. Hope this helps you on your journey too. Feel free to reach out if any of this struck a chord or you have any questions. ## Useful links * [How to Solve It](https://press.princeton.edu/books/paperback/9780691164076/how-to-solve-it) by George Polya * [Letters to a new Developer](https://letterstoanewdeveloper.com/) by Dan Moore * [How Do It Know?](http://www.buthowdoitknow.com/) by J. Clark Scott * [Crash Course Computer Science](https://www.youtube.com/watch?v=tpIctyqH29Q\&list=PL8dPuuaLjXtNlUrzyH5r6jN9ulIgZBpdo)