2 An Interview with Ellen Shapiro

Ellen is a mobile developer who has been building iOS and Android apps since 2010. She worked for years in Chicago, where she eventually became Director of iOS Development for a small agency called Vokal, then Lead Mobile Developer for the parking app SpotHero. She moved to the Netherlands in 2017 and joined Bakken & Bæck’s Amsterdam office. She’s recently joined Apollo GraphQL to work on their iOS SDK, and now lives in Madison, WI.

Ellen Shapiro

Connect with Ellen

Twitter: @DesignatedNerd Website: designatednerd.com

Interview

You are one of those individuals who are extremely talented in both iOS and Android mobile platforms. What’s your secret, and how do you stay at the top of both development communities?

Part of my secret is that I started learning both around the same time, with the idea that I’d specialize in one when I felt like it—and that sort of happened. I’ve always been fascinated by the two different approaches to what is essentially the same problem. Here is a device, for example, that fits in your palm. It’s got a somewhat weaker processor than a normal computer. It’s definitely got less RAM, and it’s got a terrible battery. How do you take all of that and make an experience for users that’s good, consistent and interesting? And iOS and Android have long had different approaches to that problem. I find it interesting to see, both from a developer-tools standpoint and from a UX and hardware standpoint, how each platform approaches it.

I’m better at iOS than at Android. You might try to stay completely up on both, but there are only 24 hours in a day, so you tend to have more expertise in one area or the other. But I try to cultivate working with Android teams and then also continuing to follow Android news and Android development trends because I do feel like I learn a lot from how both platforms attack the same problem.

It’s definitely something that I feel like I accidentally stumbled into. But it’s something that I do feel like I keep purposefully continuing with because I think it is something that has provided me some valuable insights over the years.

You’re the founder of your own company, Designated Nerd Software. What’s the focus of your company, and what motivated you to start it?

At this point, Designated Nerd Software is mostly the umbrella name for all the random stuff that I do. I actually get paid by Apollo GraphQL at this point. When I first started Designated Nerd, it was called Designated Nerd Technical Support. I used to work in television production, and I always joke that I’m in technology because I knew how to set up a Mac with a networked printer in 2003—because I knew how to do that, people kept asking me more and more complicated questions, and I got better and better at Googling the answers.

There came a point at which I was working at a couple of different television shows; when you’re a peon at these TV shows, you always have more time than money, but there’s a fairly large number of people who have more money than time. If people needed their home network set up, I would go to their homes and set it up or help them troubleshoot their computers—and I got paid for it. That was the birth of Designated Nerd Technical Support. Then, once I actually learned how to develop, I turned it into Designated Nerd Software and Technical Support. That was how I put out my first few apps when I first started programming. Then, over the years, I dropped the technical support side because I don’t have time to go to people’s houses and set up their routers anymore.

Then you started developing apps for other clients?

When I first started developing apps, it was mostly trying to build a portfolio. I wanted to have something to show, primarily because I didn’t have a computer science degree. I had a certificate in application development from UCLA Extension. I wanted to try to be taken at least somewhat seriously, so I started building apps. Then, I tried to make things better app over app, trying to show that I could grow an idea over time—roughly at the end of 2011 when I finally got a job.

I knew I was not the world’s best developer, particularly when I got hired. I got thrown into the deep end on my first job, but I don’t think anything that I’ve ever worked on for software on my own has ever even threatened to pay the bills, so I’ve always had more traditional jobs. That’s actually been really useful for me because I spent most of my career working at agencies or consultancies.

But, essentially, I get contacted by a company that I work with and they say, “Hey, we want you to build a thing.” And I build it. So I wind up working with all kinds of different industries, solving all kinds of different problems, working with technologies that maybe I haven’t worked with before. It is something that was helpful, particularly at the beginning of my career, because it gave me a lot of chances to work—and to try and fail and try again in an environment wherein I had people who were there to help; they were there to be able to answer questions that, normally, I would have been going to Stack Overflow over. And that was hugely helpful for me; it’s a big piece of why I like working on teams.

“The best way to learn is to teach. The way that you walk through the knowledge is by watching somebody else do something, then you try something yourself, and then you show other people how to do it.”

In addition to doing this, your developing career, you work full-time as a speaker and creator of educational content for developers. What have you learned from working on all of these diverse projects?

How to operate on very little sleep. No, that’s a bit of a joke. But I think it’s all tied together. One of the things that I’ve learned from preparing for talks is that, the more that you dive into any subject, you realize how much deeper that subject is than you thought it was when you first decided to dive into it. You start to see a lot of the nuance that you might miss trying to work with it just once.

When I was at my first job, the thirteen-ish-year-old son of a guy I used to work with was interested in doing iOS development, and I wound up tutoring him remotely over Skype. One of the things that I thought was interesting was that I realized that, in order to explain a concept to someone else, I had to understand it way better than I felt like I already did. Even trying to explain something like delegation, when I first started doing that tutoring, was an eye-opener. It’s a critical, core principle of iOS development—especially at that time because this was in 2013. In 2013, if you couldn’t explain delegation, you were going to have a hard time explaining a lot of other stuff. I found it to be interesting how mentoring is not just beneficial to the mentee but to the person who’s mentoring, forcing them to understand something before they try to explain it to other people.

The best way to learn is to teach. The way that you walk through the knowledge is by watching somebody else do something, then you try something yourself, and then you show other people how to do it. That’s obviously a fairly long process going from one end to the other, but I think it is a useful way of learning in a way that sticks.

What is your daily motivation and inspiration to work on software engineering?

Being able to work on a team is the most important thing for me. I enjoy working with other people and building something cool. I have always been someone who enjoys making things—I was a songwriter when I was younger; I went to film school; I worked in TV for a long time. One of the biggest things that I enjoy about doing iOS and Android development is the opportunity to create something from nothing. Being able to work on a team of developers and designers, and other people who are involved in trying to make something awesome that works for a lot of people is super fun. It’s something that keeps me going, even when I’m working on something that makes me want to throw my computer out the window.

In setting yourself up for success, how do you start your day off with a bang? Do you have any secret morning routines that set you up for success?

Oh, god, no. My morning routine is such a mess. Particularly when I was at Bakken & Bæck working in Amsterdam three days a week, which is about an hour-and-a-half train ride from where I live. If I was working in Amsterdam, my mornings were usually spent desperately attempting to get to the train. Then, if I wasn’t working in Amsterdam, I was usually arguing with myself about when to get up. I am so not a morning person in any way, shape, or form. Early on, when I had finished the schoolwork that I had done, and before I was working a job, I basically wound up working from 8:00 in the evening until 4:00 am, sleeping from 4:00 in the morning until noon, and then going out during normal human hours from noon to 8:00 pm.

I have a weird internal clock, and so I think one thing that is very helpful for me in terms of getting started in the morning is having a routine. It’s one of the things that’s been hard about having something that I’m not doing five days a week; I have a routine for the days that I’m scrambling to get out the door, but I don’t have quite as much of a routine for days I’m working from home. If you’re not a morning person, having a routine is really helpful because you can sort of zombie your way through that and get to the point where you’re like, “Okay. I made it to my desk. I have whatever caffeinated beverage will actually get my brain working right now.” And then you can proceed from there.

There is no single recipe for success. It seems that it’s very up to the individual.

I’ve certainly found that to be the case. I think any work-structure that tries to overly enforce schedules—everybody has to be here from this time to this time—winds up being so counterproductive because you’re not accounting for the things that some people are better at or some people prefer. For example, Bakken & Bæck, where I used to work, has offices in Amsterdam, and headquarters are in Oslo. There’s also an office in Bonn. But the Oslo office has this reputation that everybody is at their desks by 8:00 am, and everybody is gone by 4:00. And the Amsterdam office is like, “Oh yeah. If the whole office is actually there before 10:00 AM, there must have been a meeting.” And people there work later. For a strict schedule, for people that are better workers early in the morning, that’s great. For people who aren’t, that sounds like torture. Allowing people to have the schedule that allows them to be the most productive is best. You need core hours when you can have meetings and do business, but allowing people to set their own schedules makes everybody a lot happier and a lot more productive.

What else would you recommend to an aspiring developer who is starting their career? Which first steps should this individual take in order to have a successful career as a software developer?

One of the things that I feel like a lot of people experience, including me when I first started learning development, was feeling like there was a point at which I would learn everything. That’s not possible. One of the things to remember is that, particularly as these platforms grow and evolve, things are going to change a lot. The thing that’s much more useful in the long term than learning any particular API or particular way to do things is learning how to learn new stuff. There are always going to be new tools and techniques to try. There are always going to be people saying, “This is the one true way to do things,” and then other people saying, “No it’s not. This is the one true way to do things.” Being able to look at those claims dispassionately and figure out what actually works for you is the bigger thing to focus on in terms of learning.

I’m a hyper-competitive grade grubber, which helped me early on. I was always good at school, and I was one of those obnoxious kids who’d said, “Yeah. I got an A in everything,” and then, “Oh, my god. I got a B+. I’m gonna die now.” So I had this paralyzing fear of failure. When I first started developing, it was hard if something didn’t work when I first tried it; it felt like a failure. I had to sit back and realize—and it took me a long time to do this—that if something doesn’t work, it’s trying to tell me something through the way in which it doesn’t work. Either I have a compiler error, or I have a crash, or something doesn’t show up on the screen. Why didn’t I get the result that I wanted?

People joke about debugging being like trying to solve a murder mystery in which you are the murderer. I started slowing down, just throwing stuff at the wall to see what worked, and asking myself, “Why didn’t that work?” I was able to come to an answer. That kind of thing also helps you the next time you come back.

If you try to do something, and, the first time you try to do it, it takes 100 tries to get it right, the next time you go back, it’ll take you maybe 25 tries to get it right. All of that time that you spent having it not work was actually useful because you basically know what not to do the next time. Over time, as you continue to build more and more, you learn patterns, you learn what to look for over time, and you start to see why things aren’t working the way that you think they should. And that’s a big thing in terms of being able to hunt down a problem, learn new things, and try to figure it out.

Are there any trendsetters or leaders that have been helpful for you through your career—people that you follow and like to learn from?

Peter Steinberger is one. I first heard of him when I was trying to work on something that involved a bunch of weird nonsense with PDFs. He’s the guy behind PSPDFKit. He is someone who, even when his company was basically just him and a couple of other people, has been doing tons of programming for years. He’s able to find all kinds of crazy bugs and workarounds in PDFs. One of the things that I enjoy about him is that he gets just as exasperated as everybody else, and I think, particularly as a younger developer, there were often times when I would feel dumb because I couldn’t get something to work. Then I would see more advanced developers like him also couldn’t get it to work, and it was a lot more comforting. Having someone like Peter at a community level, who is able to work through some of the more difficult problems and who is a leader in reporting those problems to Apple, has been helpful in that.

In terms of other leaders, I often also wind up following my peers, the people that are working on similar things that I do or people whose talks I found interesting. Finding other people who you feel provide helpful advice or commiseration is helpful.

What are the traits of a good leader from your point of view?

Who is a good leader often comes down to what they are trying to lead. Are you trying to lead a small development team? Are you trying to lead a huge development team? Are you trying to lead an entire company? A good leader of a small development team means being able to personally interact with the people on your team and understand what they are trying to accomplish, what is hard for them, and how you can help them work around those issues. That’s a great trait for the leader of a small team. But when you get to a certain size of team, you can’t have the CEO worrying about what every single person does because then they don’t have time to actually deal with the consequences of everything that’s happening in a company of that size.

A lot of people don’t necessarily realize that leading increasingly large groups of people leads to completely different challenges. Some people recognize this and do a great job of trying to prepare themselves for the new levels, but then there are some people who think, “I want to lead a bunch of people because that’s the obvious next step in my career,” without thinking about the challenges. Leadership isn’t only being in charge of people. It’s figuring out how best to support them, not just given what those people are doing, but given what you’re doing, given what your actual job is.

Is there something you wish that someone had told you when you started in software development that you had to learn the hard way?

When I first started, testing on iOS was not really a thing. We would find out something was wrong, and it was several months later after the app went through QA that I’d have to figure out what I was working on three months ago – what was I even trying to do? I wish I had understood that tests take more time up front, but they save you so much more time both in debugging later on, and they ensure that the app actually does what you want it to do.

Testing also helps whoever comes and looks at the app next because they know what the previous developer expected it to do, especially if there’s an app in which you don’t have a lot of documentation about what it’s supposed to do. Having tests is helpful in terms of being able to figure it out. Testing is never going to have you shipping bug-free software, but at least you can understand what it’s supposed to be doing when it’s working right and potentially some of the cases in which it could go wrong. The emphasis on testing has shifted pretty dramatically over the last few years. We see what a huge difference it makes in terms of the quality of the product that you’re making and your ability to make changes without screwing everything up.

In drawing insight from other sources, what do you read or listen to?

One podcast that I have enjoyed for the last twelve years is a podcast called Planet Money from NPR. I don’t have any background in economics, but it basically looks at how economics and money shape the world that we live in. It started as a sort of a response to some of the financial crisis in 2007 and 2008, trying to explain what was going on. But over the last few years, it’s been something that’s evolved to explain how hidden economics affect things or your own life in ways you might not expect.

Particularly for software developers, we always have to be on the lookout for these confounding factors. When people say, “Okay. I want to do this and that and the other thing.” But have you considered this aspect that is also affecting all these things that you’re doing? I think it’s a useful podcast to show that you have to look deeper where you aren’t necessarily expecting to find something. You have to think about the things you aren’t taking into account.

Ellen’s Recommendation

• Planet Money podcast | National Public Radio (NPR)