Becoming an Engineer

I started working as an engineer at Twilio this summer. It’s my first engineering job, and I love creating internal tools that make our business more efficient. However, I didn’t start out as a computer science undergrad, and I hadn't written code professionally before. Instead, my path started two years ago, when I joined Twilio as their first customer service rep.

Growing up, I never thought I’d be an engineer. I went to a liberal-arts college and graduated with a degree in Economics. My first experience writing software was through Stanford’s introductory CS class, available online for free. I got addicted to the process of struggling to solve a problem and the thrill I felt when my program finally worked. Still, whenever I talked to other developers about the problems I was working on, they’d say, “How cool! That reminds me of the stuff I did when I was twelve.”

Growing technical chops at Twilio

Joining Twilio was my first opportunity to work closely with engineers. As technical tickets came in, I learned how HTTP works, how web applications work, and how our engineers build and maintain the service. I became interested in the work our engineers do and recently had the opportunity to take the plunge. Twilio has grown significantly over the past few years and this gave me the flexibility to start a two-month rotation with engineering this July. It was the ideal environment to learn programming; I worked full-time as an engineer, but I could relax knowing I had my primary job to go back to.

Early work is all uphill (for nearly everyone)

The first few weeks were tough. My first task was to add a dismiss button on a Javascript popup. I thought the task would be easy, but each page actually has dozens of files of code fitting together to make a page work– style sheets, controllers, distributed all around the code base. Even when I found a similar feature to copy from, the task took me half a day of trial and error. I griped about this to my teammate. Instead of being off-put by how long it took, or being overly sympathetic, he just said, “Yup. That’s what development is. It’s very frustrating until it works.”

Good process makes it easier to join as a newbie

Our team develops by breaking projects down into to-do items, each taking as little as an hour to complete. This itemized approach is perfect for integrating newbies. I got tasks that could have been picked up by a senior engineer– I just took much longer to complete them, and that was fine. And if I ever had a question, there were many possible teammates I could turn to, because very few projects are siloed in the code base.

Learning how engineers work, and learning engineering skills

To become an engineer, I had to learn how our systems actually work. When I was in support, whenever engineers solved a problem I brought them, the way they found the issue and fixed it may as well have been magic. Joining engineering was like opening up the black box.

First off, for those of you learning learning to program, ask a mentor how to access your server logs and write those directions down. If your code is ever not doing what you expect it to do, you could sit around and guess what’s wrong. Or, you could check your logs. Logs can tell you what values your program is calculating at each step before it returns your result, and if it’s running into an error, it will tell often you the line of code where your error is at. It’s like turning on a flashlight in the dark.

Also, if you’re a new programmer participating in a large project (whether at work or in open-source), make sure you have a place to get your feet wet. When I first started, I felt lost within the code base didn’t understand the big picture of how it works together. One day at lunch, my team lead told me that whenever he’s in a new code base, he’ll make a new page within the site, just to see how everything works. That night, I stayed up late and made a page on a private branch. It printed out the user’s name, it did some silly animations– it wasn’t pretty, but it got me much more confident adding features going forward.

Becoming a full-time engineer

Once I got comfortable picking up one small task each day, I asked our engineering director what level I’d need to be at in order to stay on full time. In response, I got a project, spanning the last two weeks of my rotation. I could ask questions all I wanted, and if I completed the feature with a reasonable degree of independence, I could stay. If I didn’t, I’d have my old job back, no harm, no foul.

With a lot of help from my mentors, including three code reviews, I got the feature done. It took me much longer than an experienced coder to complete, but because of code reviews and version control, knew that we weren’t releasing highly buggy or poorly-designed code. And, immediately after that project was due, I used an extra week to pick up a similar project– this time finishing it a lot faster, and with much less coaching.

Now I’m full-time on internal tools and reporting. I still work slowly compared to other engineers, but I’m watching myself get faster. And my advantage is, after two years of support, I’m very familiar with how our support team works, and I know our internal tools like the back of my hand.

Being part of a development team is some of the most satisfying work you can do. If you read about the Silicon Valley talent wars, you can get the impression that you need to be brilliant to become a developer. To be honest, it’s more important that you’re diligent and a methodical problem-solver. Your code won’t be great at first, but it will improve with time. Just start at whatever level you’re at, and keep going.