First of all, that’s very exciting! Software engineering is pretty darn cool—you get to learn lots of new things, understand the technology you use every day better, and contribute to the mysterious maw known as “the internet”.
Last February, I also decided that I wanted to pursue computer engineering. I’d been at Artsy for a bit less than two years at that point, first as a marketing intern working on SEO and then as a coordinator on the CRM (read: email) team. I’d consistently been working on small technical projects; first doing some work on a tool for SEO optimization for our Editorial team, then building emails with MJML, and a few other bits and bobs. But I didn’t think of it as a serious pursuit.
Mostly, that was due to my experience programming in the past—I did about half a CS major in undergrad. At the time, I felt that programming wasn’t right for me, and I dropped the major during my third year.
It was Artsy’s Engineering team that convinced me that programming was something that I both wanted to and could do. Our engineers have always welcomed learners and been happy to answer questions and empower other teams to do technical work. I eventually realized that the parts of my work where I was coding were the parts I enjoyed the most, and that I would likely feel more fulfilled if I made programming my full-time occupation.
Here’s what that journey looked like. Hopefully my experience proves helpful to you as you begin (or finish) yours!
Step One: Tell People What You Want
This might’ve been the single biggest learning I took away from this experience: if you tell people you want something, you might just get it.
That may sound super obvious. It wasn’t for me. I’ve usually been very passive in my career decisions, taking the path of least resistance and considering myself lucky when I was able to keep progressing. In this case, I was making a substantial departure from that idea by being proactive about what it was I wanted. This post by Noa Elad does a great job with this topic and is certainly worth a read.
The first person I told at Artsy was Orta. He’d often encouraged me to develop my technical skills, and since he knows Artsy’s engineering team and stack better than just about anyone, I figured he’d be able to point me in the right direction when it came to learning resources and navigating company politics to get to my eventual goal.
The second person I told was my manager on the CRM team. I fortunately had a very good relationship with my manager and was confident that she would help me if she could. And by telling her early, I was giving her more opportunity to advocate for me and making it easier for her to replace me in the event that I was able to switch teams.
The third person I told was Artsy’s CTO, dB. This was Orta’s recommendation—dB would be able to tell me if and when a move might be possible, and he could suggest things I should do to improve my chances of making the switch.
I also didn’t keep it a secret from the rest of my team or the company. I didn’t show up wearing a shirt that said “ENGINEER” on it, but I told people, “I’m working on becoming an engineer. I’m really hoping to stay at Artsy, but if there’s not a role open for me, that’s fine—I’ll search elsewhere.”
The net outcome of these conversations was that there wasn’t a role open right then (and that I still had lot to learn before I’d be ready when one became available), but I also left with a better idea of what I should learn and what I could expect from the coming months.
Step Two: Figure Out What You Want to Learn
The answer to that question really depends on who you are, where you work, and where you want to work.
I wanted to work at Artsy, and I felt that I was most interested in front-end work. So I asked a few of our engineers to help me understand our stack and to recommend frameworks/languages I should learn.
If you’re interested in changing companies as well as careers, it’s worth seeing if your target company or companies have open source code you can check out. See if you can find them on GitHub and look at some of their recently updated repos. If you already have some coding experience, see if you can contribute a little bit—even fixing small bugs or typos is a good place to start, since you’re both contributing to their codebase (which will help you if you land an interview) and learning more about their stack. dB recommended that I do this with Artsy’s code.
As with most companies that have been around for more than a year or two, Artsy is home to projects with many different stacks. However, most of our newer front-end stuff—things that are recently updated or currently in development—is built on React using TypeScript. So my first question was “what do I need to know in order to write TypeScript code in a React framework?”
Fortunately, a lot of other people have the same question.
Step Three: Decide How You Want to Learn It
First: there is no wrong way to go about learning to code. Whether it takes you 6 months or 6 years, whether you learn one language or a dozen, whether you ask for a lot of help or do it all yourself, you are learning and that is valuable. Learning to code is not a magical skill. Like just about everything, it’s a matter of putting in time. Just keep trying, even small things, and you will make progress.
Lots of people who want to become engineers go to coding bootcamps like Flatiron or General Assembly. That’s a very reasonable thing to do! I had a decent grounding in CS fundamentals thanks to my experience in undergrad, and as a result, I initially decided I wouldn’t do a coding bootcamp—I felt I had enough experience to benefit from the multitude of online courses and open source projects out there.
However, there are definitely real and significant benefits do doing a bootcamp. Here are three that I can think of:
- Clear curriculum. At times, I was overwhelmed by the possible ways to proceed and stopped making progress as a result. Bootcamps take the guesswork out.
- Timeline. Because I didn’t have a hard date set for a transition or interview, it was up to me to determine how fast/slow I worked on things, and I stagnated at times as a result.
- Community. While the open source community is very much a real thing, and you can find lovely people on the internet who want to help learners like yourself, it’s not the same as having multiple people learning the same thing at the same time in the same physical space.
The downsides, of course, are that coding bootcamps are expensive and time-consuming. Most of us don’t have the luxury to leave a job, pay $10K – $15K in fees, and spend a couple months at a full-time bootcamp with no income. There are other models, such as online-only bootcamps or after-hours classes, but those come with challenges of their own.
I’d say that If you can afford a bootcamp and have the time, it’s a great way to jumpstart a coding career, but you don’t have to attend one to become a good engineer.
If you decide to go the non-bootcamp route, you also have a lot of good options. I did courses through Udemy, which has a lot of courses that are literally always on sale for $10 - $20. There are many other similar services out there as well, like Udacity, Codecademy, and Treehouse.
I also highly recommend attending IRL meetups, because that’s where you can make connections and learn from others most easily. I’m a semi-regular attendee at the CocoaPods meetup hosted by Ash and Orta at Artsy HQ, and meetup.com and peerlab.community are great places to find other events.
Step Four: Get Comfortable Not Knowing Things
When learning engineering concepts (and practicalities), there’s a lot you’re not going to know.
This piece of advice is important both when learning and once you actually land an engineering job (it’s been one of the hardest parts of my first ~3 months on Artsy engineering).
Part of what makes engineering so cool is that you are always challenged to learn new things and solve new problems. But especially at first, the mental toolbox you have is pretty limited. When you don’t know a language or framework, it’s very hard to solve problems using it—your first problems are likely to be syntax errors and misunderstandings.
One of the best things you can do is learn how to ask good questions and then ask them. You might be asking them on a forum, in GitHub issues, in meetings, or in conversation with your favorite rubber duck. Regardless, just asking them will help, and asking lots of questions is one of the best way to learn things fast—but it takes humility and self-awareness. Julia Evans has a great zine that has good advice on asking questions, among many other things. For a few more fun and helpful resources, see Artsy’s README.
Step Five: Recognize What You Bring to the Table
Ok, so you’re reconciled to the fact that you have a lot to learn—but what about all the things you already know? Those are important too!
Even if your past work and/or life experience has nothing to do with computers or programming, it can still have value as you work towards engineering (and after you become an engineer). That value can take a lot of different forms, and since everyone’s experiences are different, I can’t say for sure what impact your prior knowledge will have.
For me, there are a few experiences I brought to engineering that were particularly helpful. Because I was transitioning from one team at Artsy to another (Marketing → Engineering), I brought with me a broad understanding of Artsy’s goals and needs, which helps with day-to-day prioritization. And when I’m in a sprint planning meeting or a product review and someone has a question about email or marketing, I can often answer—or at least I know who to talk to to get to the bottom of the issue quickly. Plus if at some point my team needs to code emails, my past experience will come in very handy.
There are also life experiences that serve me well on the Engineering team. My work as a server and bartender made me good at clear communication with stakeholders. Cooking for big groups of friends has made me better at estimating how long I’ll need for tasks. Don’t underestimate the power of “soft skills”—even companies like Google have come to recognize that it’s often the non-technical skills that separate good engineers from great ones.
————
Moving to engineering has been a tricky process, but one I’m very grateful to have experienced. I’m lucky to work at an organization where moving from email marketing to engineering is possible, and I’m even luckier to have had the support of engineers, friends, and engineer-friends in making the move. If you end up pursuing this course as well, I wish you the best of luck!