On August 18, 2015, I was on a one-way flight headed to Copenhagen from Toronto Pearson Airport. I was starting my two semester exchange at the Copenhagen Business school.
I can easily remember the date because it was my brother's birthday. He was forced to spend it at the airport with our family as they sent me off to Denmark, for what they thought would only be 8 months.
My only familiarity with Copenhagen was from watching the CPH Open on Thrasher Magazine's YouTube channel. Luckily for me, I absolutely fell in love with the city and, after my first semester abroad, I made it my mission to stay here even longer. I was due to start an internship upon returning back to Canada and challenged myself to find one in Copenhagen instead.
Working in Copenhagen
I didn't really have a plan, so I started looking for roles as a sales development representative (SDR). I had just learned about this entry-level role in one of my classes. Since all of my previous experience was in sales and customer service, I thought it would be a good fit.
I sent out my application to a young startup and within 4 hours, I was on the phone with my soon-to-be sales manager. That was my first taste of how quickly things can move in startup-land! About a month later, I had my first day. This was also the first time I had met professional developers.
I've always had a deep interest in technology, although the closest I'd been to software development at that point was in my Visual Basic class in high school!
Starting my new job was the first time I got to work directly alongside developers. It was thrilling to hear about their work. There were always so many buzz words and technologies they spoke about – React, Ember, Scala, Python, TypeScript, boilerplate-code, compliers, rendering. It was intimidating to think you had to know about so much to develop software.
I spent the next year and a half continuing to progress in my sales career, eventually being promoted to account executive. I felt like I had greatly developed my communication, time-management, and presentational skills.
Although I was successful in my current role as an account executive, I wasn't sure if a future in sales was exactly what I wanted. It was also limiting to my future job prospects if I wanted to continue to remain in Denmark – it's not easy find a good job selling in English in a country where the first language is Danish!
I found myself reading more, searching for a new hobby or challenge. That's when I found the freeCodeCamp blog (it was still on Medium at that time). It actually took me a few days before I realized freeCodeCamp wasn't just a blog, it was an entire platform available to learn how to code online, for free! As if the name didn't speak for itself...
It only took completing a few HTML challenges before I was absolutely hooked. It was then that I decided I would spend all my free time working through the freeCodeCamp curriculum, with the goal of one day in the long-distant future maybe becoming a developer. I loved the idea of being able to speak to my colleagues about React, however far-away that felt.
Struggling with the Basics
I was feeling fairly confident in how quickly I was learning HTML and CSS until I actually attempted to complete one of the projects. Create a simple portfolio? This should be easy!
But it was overwhelming how lost I suddenly felt in an editor outside of freeCodeCamp. Attempting to start a project from scratch seemed impossible and it was frightening how quickly it felt like I forgot everything. Becoming a real developer suddenly felt like an impossibility.
Finally asking for help was the best thing I did for myself. After stewing in my frustration for far too long, I reached out to a colleague who patiently guided me through using VS Code, structuring my HTML document, and linking it to a CSS file. After finally cobbling together a portfolio, I checked the box as done, even though I felt my work was terrible compared to others attempting this same challenge.
It was certainly helpful in solidifying the basics for me – after all, repetition is key. However, the biggest mistake I made in my learning journey was not going back to attempt those challenges.
Starting at Pleo
From there, I jumped straight into another course, this time on Node directly followed up with a course on React.
Somewhere between the Node and React courses, I had started a new job as an account manager at what I still deem to be Denmark's coolest startup. It was and is incredibly exciting to be a part of a company growing so fast. It was even more exciting to meet so many new and talented developers to learn from.
About three months into my new job, my manager and I were discussing how my role could develop in the future. I was honest with her and said I wasn't interested in any further responsibility. I wanted to spend any and all excess capacity teaching myself to code, with the hopes of one day becoming a developer.
This is not something you want to hear from a relatively new sales rep on your team. But to my surprise, she was incredibly supportive and made a commitment to help me any way she could, as long as I hit my targets.
Attempting the Coding Challenge
After speaking with one of our engineering directors, it was clear that for us to continue a conversation around what a transition from sales to product would look like, I would need to complete our frontend hiring challenge, like an outside candidate would.
The thought of attempting this was both incredibly intimidating and motivating. This is when I started staying late in the office every night. I didn't want to waste time biking home, so the second the clock hit 17:00, I would scurry to find some dinner, returning to my desk as soon as possible, to start my day pretending to be a developer.
I had finally finished my React course just before the Christmas holiday and was working on a few side-projects, although I never really followed through with any of them. I knew I needed to start applying my knowledge but found it difficult to complete a project without a real end goal.
With some extra time on my hands over the holiday period, I began to look through the frontend challenge again. I still felt far from capable to produce a worthy submission, however, I felt it gave me some sort of end goal to work towards so I could actually finish something.
Luckily for me, our frontend challenge was very similar to the final project of the React course, so I could reuse much of the boilerplate and components for my submission. I definitely felt like I was cheating.
But I sent through my project anyway and eagerly await feedback. Having my code reviewed by two of our senior engineers was incredibly scary and I was prepared for some harsh feedback.
After a couple weeks, my grade was in, and my submission wasn't a total failure! I had received some really great, actionable points of criticism. One of my colleagues even spent an hour with me after work, talking me through each line of feedback. Our code review session went so well, we decided to meet again, week after week, until well after I transitioned into becoming a developer.
My First PR
My sales manager and the director of engineering continued to check in on my progress throughout the coming months. In April, the opportunity was presented that I could possibly work on the side with our internal tools team. There were many small, non-urgent tickets that needed attention in our back-office system.
I was excited – it would be a great way for me to get some real experience in working with the product team and it was made very clear this wasn't to interfere with my work in sales. That thought of working with real, production code was INSANE!
After a bit of coordination, an introduction to the team, and an invite to our company Github org, I was given my first ticket to work on.
I was to add an input to make a field editable for our compliance team. It was immediately clear I had no idea how to do this. Sure, I've added an input before and I knew vaguely how forms worked in React but this code felt like nothing I'd seen in any of my tutorials.
I was suddenly left with an ocean of questions. How does TypeScript work? What is a branch? How do I make a PR? What do all of these libraries do? How does my code even get built and sent to our users? What happens if I break something important?
It took me a couple days to get my bearings, but after much patience and help from the engineering lead, I managed to get two approvals and ship code to production. That was a huge milestone in my journey.
Making the Switch
Over the next five months, I continued my routine of staying in the office late, working 09:00-17:00 in sales and 17:00 until whenever pretending to be a developer working with what I considered to be real code.
As you could expect, my desire to continue in sales dwindled every day and I started pressing to see if we could agree on a date for me to officially switch.
It certainly didn't go smoothly. No one had experience in what it means to move someone from sales to our product team. First and foremost, I had to be on target. I think that's true with most sales organisations – everything always comes back to making your quota.
After much back and forth, an agreement was made that I could officially make the switch August 1st, contingent that I remain on target. This was the light at the end of the tunnel for me. It was absolutely baffling to think I would soon be presented with an employment contract for my new role as a software engineer. The weeks leading up flew by. By 17:00, Wednesday, July 31, I was no longer an account manager.
There was definitely a transition period in getting used to my new role. It felt like being a stock broker working on the trading room floor to suddenly becoming a librarian.
Noise aside, there hasn't been a single day where I haven't been excited about coming into work. I've continued working in our internal tools team, building out our compliance and customer support back-office.
What I learned
The experience I gained in sales is incredibly advantageous in my work today. Strong communication, time-management, and presentational skills have been invaluable as a dev. But I have found these to be lacking in most dev communities I've observed.
I realize I'm incredibly lucky to have been presented an opportunity to work with production code so early on. It was without a doubt a huge leap forward in my learning and massively helped in expediting my understanding of the realities of working as a dev that is impossible to gain from online tutorials.
Having a mentor to work with hugely accelerated my learning and was extremely helpful in keeping me accountable for always having a project on the go, so we always had something to work with. Without all of the support around me, I think I would still be spending all of my nights and weekends working through tutorials or building random Pokemon generators.
I made a commitment early on to spend all of my free time continuing with my development. I think it's very easy to underestimate how large of a time commitment this journey is. Access to a mentor is a huge help, although even someone with enough knowledge to occasionally answer questions can save you hours of frustration. Don't be afraid to ask for help.
Looking retrospectively, I wish I would have spent more time building small projects and applying the things I learned. I frequently started projects but never followed through because I felt like I couldn't code something the correct way.
Spending time struggling through something has been way more helpful for my learning. There is certainly safety to staying on the rails of an interactive coding course but it can put a ceiling on your ability to apply your knowledge in the real world. I definitely fell into that trap.
It took me a while before a realized no one knows what the right way is, it's all made up. As a novice developer, there is value in a fresh perspective.
If there was one piece of advice I wish I had earlier on, it would have been to make a greater attempt to apply my knowledge as I learned. There is no such thing as real code or the correct way to do things, especially when you're learning. Any chance you have to apply your learnings along the way is valuable.
You're not a developer once someone pays you to be a developer, you're a developer the second you start coding.