Reading Time: 9 minutes
Elaine Uy is a senior software engineer at Tapjoy, a mobile advertising and marketing automation company. This week, we had the chance to sit down with Elaine to talk about turning a monolith into an SOA, what “senior engineer” even means, and why programming classes as a high-school requirement are probably a good idea.
An Inside Look with Codeship is a regular series providing an insider’s perspective on the tech industry. Each session, we chat with some of the most exciting voices in tech and ask them where they’ve been, where they’re going, and what we could all be doing together. You can read all Inside Look interviews here.
You’re a senior software engineer at Tapjoy. Can you tell me a bit about what you’re working on right now?
Sure. I am the tech lead for the Content Team, so I’m responsible for the technical architecture. Tapjoy is an advertising company, so very specifically, I am working on the actual ad content and delivering that.
I make sure that everyone has the right work and that we’re working on the right things to accomplish the greater team goal. My concern is specifically the technical architecture and the things that we are actually producing.
You have a tendency to stay with companies for several years. When so many devs move on (or burn out) after a year, how do you keep going?
Maybe I’m atypical from the standard dev, but I kind of like staying somewhere for longer. I find what’s rewarding about the job is building a team and solving hard problems together, rather than being a strong, individual contributor and “if people aren’t doing things my way, I’m going to leave.” I’ve seen that attitude once or twice.
I can’t speak for other people. Maybe they get incentivized to leave because the pay is so much better somewhere else? Or maybe they get incentivized to leave because they think they should have more responsibility, or more work to do.
When you first joined Tapjoy, you were part of a team that moved your internal architecture from a monolith to an SOA. Can you talk about the challenges you ran into there?
The analogy that I like to give about doing this kind of work is imagine you have a very fast-moving race car and you want to live-swap the engine out. That’s kind of like what that work is like. It’s actually really exciting and kind of terrifying — but really exciting.
We started out pretty conservatively, and of course we didn’t just live-swap code. That is always a bad idea, so we had tests in isolation. We had ways to run basically tests with code side by side, both the new code that’s going through a microservice versus staying in the monolith. There was a lot of isolation code work that had to be done and tests that had to be rewritten, and it was a process, that’s for sure.
But it was time for it, and it needed to happen. One of the things you’ll find when you are in a early-stage startup is you’re trying to iterate as fast as possible and trying to put out as many features as possible to sort of get into your Agile stride, right? You’re not doing anything at scale, you’re just trying to get users or whatever metric you’re judging your growth by. You usually do that all in one application, right?
Tapjoy had actually grown to the point where it was cumbersome to have everything that we were doing — and there were so many things that we were doing — under one roof. It didn’t make sense anymore.
One of the most important lessons that we learned while we were breaking up into microservices was that you should only do it when the amount of work put in is worth the output that you get back. So, the first two or three that we did made sense, but as we started getting into the more nitty-gritty, integrated, hard-to-intertwine bits of code, we actually realized that we needed to back off. That would be a longer effort than building on top of what existed. So, there was that interesting tradeoff we had to make.
What’s the most unique technological difficulty you’ve had to figure out?
The hardest technical challenge that I’ve overcome is definitely the microservices problem, because I had never attempted to break up a monolith of that size. It comes with a huge tax, not only in the infrastructure you need to build to support it, but also in smartly thinking about how to extract bits of code into single services.
But there’s kind of multiple ways that you can answer this question, and it kind of gets into the definition of what you think a senior engineer is.
I wouldn’t say that I have great knowledge in a single technical area and great depth of knowledge where I could identify a groundbreaking, technological problem to overcome in a specific space. I do a breadth of things. I think that’s kind of testament from how I started off, on hardcore, internal services and back-end, and now I’m leading a more front-end delivery team.
In the end, what it means to be a senior engineer is the amount of responsibility and accountability you take on. It means that for some instances and some problems, the senior engineer needs depth of knowledge, and for other instances they need to have a breadth of perspective.
The difference between that and an individual contributor is you expect your senior engineer to keep all the right things in mind to solve the problem. You could approach a senior engineer who might be categorized as – I don’t like using “full-stack,” but let’s say for this conversation “full-stack” engineer. You would expect that senior engineer to immediately say, “Wait. This is going to require more knowledge than I have” and then be responsible enough to bring someone else in or to do that research.
It seems like you’ve built your career in Ruby. Can you tell me why you were drawn to Ruby in particular?
I really like Ruby. It is probably my favorite language. It’s just so much fun to write in. I have also worked in Java. Not a huge fan. I think it’s really clunky for what it is. I also don’t like waiting for compile time, because I’m impatient, so I really like the automatic feedback of Ruby.
I’ve also worked in a lot of the scripting languages, like Perl and Python. Not in formal web frameworks, but this goes back to my days when I was a system engineer, and I was doing a lot of data analysis and integration work, which required more scripting than formal software development. The output of my work there was a result set as opposed to my output of my work now, which is running software. So, it’s very different.
What drew you to a bachelor’s in computer systems engineering?
It was probably videogames! I liked playing a lot of computer games, so I was always on the computer. My dad was an engineer, but he wasn’t a software engineer. I kind of always looked up to the sciences, but I was always fascinated with being able to program. That idea alone and seeing its applications in building a webpage, or writing a script to auto grind for me or something like that – that always was appealing to me.
I went to an all-girls school, but our computer classes, which were required for all students, were split up into two sections. One was learning things like Microsoft Word, Excel, and computer applications. The other half of the year was learning how to program in Basic. Not Visual Basic, Basic. So, with line numbers and “go to” statements and loops and everything. It was the best kind of exposure I guess you can get. So beginning to think algorithmically was happening in my freshman year of high school.
I found really fascinating, too, that in my graduating class of high school, a lot of women who would have never been exposed to programming at all actually went on to become programmers or work in IT or tech fields. I don’t think they would have if it wasn’t for that class.
Are there any mentors or resources that were key to your development as an engineer?
“Mentor” is different than “inspiration,” I think. I feel like there’s this idea that when you join a new startup or a new job that you should find someone who’s really invested in your growth, right? So, yes, you want to work in a place that has that culture and that attitude; but I actually don’t think that there’s going to be anyone ever who hands you information. That’s not how it works.
You actually have to work for it, and you actually have to struggle through. And only after that really late night after you have that failing test that you finally get to pass does it all click in your head. You need moments like that to push you forward.
Mentorship is good and healthy to help you feel supported in your efforts; but it’s really going to come from the fruit of your labors where you actually grow intellectually and are able to solve bigger and harder problems. Learning by example is really good, and having someone there to provide you examples is great, and it gives you a good leg up; but in the end, it sticks with you best when you’ve really worked to earn it.
How do you decide if you’re being successful at whatever you’re attempting?
I feel successful when whatever I’m working on finally gets released and I get positive feedback.
But for my personal success, I feel successful when I’m able to identify upcoming problems and find a way around it before it becomes a problem. I feel bad when I miss them, when a production error comes up, and I could have caught it, right? Reducing that makes me feel successful. “Oh, you know what? This might be a problem in the future. Let me think about this a little.” And, lo and behold, it does become a problem in the future, but, hey, I thought about it, so I have the solution.
What are you looking for in another dev that would make you excited to work with them?
If I am looking to join a team, I am most interested in working with people who are problem solvers, who care deeply about making the right solution even if they personally are not right. Also, I want people that I can learn from. Those are my key indicators of a team I will join. If I am putting together a team to solve a problem, I’m going to look for people who I communicate easily with.
Tell me what your vision is for your career personally. Starting your own company? CTO?
I struggle with this question on a weekly basis.I want to continue to solve hard problems with teams that I’m excited to work with and continue learning and growing. Eventually, I would like to apply this to problem spaces that are not well-developed.
[Laughs] I kind of had a mid-career crisis. Not even mid-career. I had an early-career crisis where I was like, “I have this engineering degree, and I can do so much. Why don’t I use it to change the world and make it a better place?” Then I realized how hard that was, so [laughs] — yeah.
What would you have liked someone to tell you when you took your first job in the field?
Oh, there’re so many things I wish I could’ve known when I first started. If you feel a little bit afraid, or if you feel a little bit apprehensive, you’re probably moving in the right direction, frankly. I’m very risk-averse, but I’ve only grown and have only gotten as far as I have because of the couple of times I decided to ignore the knots in my stomach that, like, “Oh, no. I’m about to take a huge leap. This is a huge risk. Why am I doing this?” That’s okay. Maybe okay.
I also learned that it’s okay if you’re the only girl the room. That’s happened to me on many occasions, but that doesn’t make me weird. And other things like, you are just as smart as everyone else. Don’t get intimidated just because everybody else seems to be talking about things you don’t know. That’s okay.