How I Learnt to Code as a Beginner (and how you can too)

Starting at Marvel

When I started as a support agent at Marvel, I had no plans of becoming a developer. I had recently finished design school and was looking for an interesting day job where I could do some freelancing on the side. Not only did I find an interesting job, but I found one where I was surrounded by engineers, many of whom were self-taught and keen to support any interest I had in programming.

I spent much of my first two years at Marvel trying to decide the direction I wanted to take my career. I went to design school and got a degree in illustration, so going for a design role at Marvel made a lot of sense. As I looked into it further, I found it quite draining to have my main hobby as my job. Normally after a long day I like to sit down and paint, but that method of relaxation becomes a lot less successful when you’re doing the same thing at work.

I thought I would look further into other career opportunities, specifically directions I could take within Marvel. I had coffee with people from lots of different teams to ask them about their roles and see if they might be right for me. I also spoke with my manager about continuing up the ladder in the support team.

I thought engineering would be a bit of a long shot. I was never particularly good at maths, had never studied computer science, and had always thought I didn’t have the brain for programming. After speaking to a few engineers, I learned that there’s no one type of person who’s best suited for programming. It’s also not something that’s particularly important to have studied in a formal setting. There are tons of resources for people who want to learn how to code and a lot of programmers are self-taught. The most important thing you need to learn to code is to want to learn to code.

My first choice to make when I decided to learn how to code was which language to learn. I was somewhat familiar with which languages were used by which teams from my experience working closely with the engineering team in support. I narrowed my choices down to frontend (HTML, CSS, and JavaScript) or backend (Python).

(There are many other languages used by both frontend and backend engineers, as well as other specializations in engineering. I decided to focus on these two specific areas of programming because I had hopes of moving into a product engineering role at Marvel)

Frontend vs Backend

If you’re not familiar with the difference between frontend and backend, I find comparing it to a restaurant to be helpful. A restaurant is made up of the front of house and back of house. The front is what you see as a customer - all the tables, seating, and decoration live in the front of house. The back of house is where the ingredients are and where the cooking gets done. It’s purely functional. The front and back interact by the front of house requesting food from the back, the back finding ingredients and making the food, then passing it to the front of house to be served to the customer.

The frontend and backend of a website work in much the same way. The frontend consists of what shows up in your browser - like the layout, colours, buttons, and how they all interact. The backend is where the actual data lives and is organised.

When you log into your Marvel account, the frontend is where you type your email address and password, while the backend is what takes that information and finds your projects to display in your dashboard.

Frontend made sense for me because of my design background. Working with the layout and appearance of a website would naturally be my cup of tea. Plus, I already knew the basics of HTML and CSS from design school and editing the theme for my portfolio website (and from adding glitter to my MySpace page before that). I dabbled in a bit of Python and had coffee with a backend engineer at Marvel before deciding it didn’t catch my attention in the same way as frontend. That’s when I was sure I wanted to be a frontend product engineer.

Learning how to learn

I tried a few different ways of learning how to code and found a balance of each of them that works best for me. The main three methods I’ve come across were documentation, tutorials, and pairing.

Documentation is the most independent method of learning I tried when beginning to code. I started with HTML using MDN Web Docs. A coding language’s documentation will have some tutorials you can work through and a reference section which is a repository of information about the language. Learning solely from documentation can be a bit boring, but it’s really useful to understand how to navigate early on. You’ll be using documentation to reference bits and bobs throughout your coding career.

The next method I tried was video tutorials. I specifically used egghead.io and Frontend Masters to learn more about JavaScript. Both of these sites and others like them have many different tutorials that feel like you’re in a classroom setting. You can watch the instructor go through the material and work alongside them (though you may have a hard time doing the work simultaneously if you don’t have an external monitor or you’re using a small laptop screen).

What led me to decide video tutorials weren’t right for me was the speed. I found myself constantly pausing the video or skipping back 30 seconds because I got distracted. Personally, I need a learning method that allows me to go at my own pace. I still use video tutorials occasionally when I want to learn about the theory behind a practice with lessons that are more lecture based.

Written task-based tutorials are easier for me to follow along with, and Codecademy is great for this. It’s more similar in structure to Duolingo than a university course. A mix of short tasks, self-lead projects and quizzes makes the process of learning less monotonous.

Find a study buddy

The most helpful thing for me when learning how to code was pairing with a mentor. Having someone looking at your screen and guiding you through a project is a great way to make sure you’re not picking up bad habits. It’s also great for learning tricks to help speed up your workflow. I learned keyboard shortcuts and installed plugins for my code editor that now I can’t live without.

A great option for pair programming is a tutoring program like Codebar. Codebar matches coaches with students to work through projects or tutorials together at weekly events, in addition to hosting workshops. Codebar and programs like it have the added benefit of introducing you to like-minded people to talk about programming with and learn from.

I’m lucky enough to have been given small engineering tasks at Marvel after about 6 months of learning on my own, as well as being assigned a mentor to pair with me on these tasks. Pairing is a huge part of the workflow at Marvel and makes sure that everyone is up to speed and on the same page.

I was lucky that Marvel was looking for a junior product engineer around the time I was ready to fully change careers, but after a year of mostly self-directed learning I was qualified for most junior web development roles. What allowed me to move into my desired role so quickly was a combination of finding a learning style that worked for me and not being afraid to ask questions. Roughly six months after deciding to learn, I was given my first small engineering task at Marvel. Eight months after that I became a full time engineer.

My biggest takeaway from learning to code is that any question will be seen as stupid to someone, so you might as well ask it anyway.

Lain Bader
Junior Product Engineer