Paul Ford and Rich Ziade talk to Natalie Podrazik about, in Paul’s words, “the gestalt of iOS programming.” Natalie traces her journey from studying comp-sci to backend programming to developing for Apple devices, where the title “engineer” often encompasses design and user experience alongside writing code. Also discussed: what it’s like to go to WWDC, the glories of the MTA’s Bus Time, and the fact that Natalie has probably watched you play Candy Crush on the subway.
Paul Ford: Hey, Rich!
Rich Ziade: Paul.
Paul: We’re back here at Track Changes, the podcast that tries to explain…
Rich: And culture.
Paul: Yeah. Those two things. Those are great.
Rich: And how they weave into one another.
Paul: I’m Paul Ford. This is my business partner —
Rich: Rich Ziade.
Paul: We co-founded Postlight. It’s a great agency in New York City that builds beautiful technology things like…APIs and platforms, if you know what those are.
Paul: Oh, you know, that’s actually a good thing to bring up, because we have a premiere and very interesting app developer, focused on iOS, here in the podcast studio with us today.
Paul: Her name is Natalie…blrughdfhdk;sgd.
Natalie Podrazik: Yes, that’s correct.
Paul: OK. How do you pronounce your last name, Natalie.
Natalie: Natalie Po-draw-zick.
Paul: Yeah. I thought it was Pah-drah-zick for years.
Natalie: You lose the confidence when you see the ‘z’ and the ‘k’.
Paul: Is that what happens?
Natalie: Mmmm. Mmm hmmm.
Paul: Hey, welcome. It’s good to have you here.
Paul: So give us the basics. You live in New York City.
Natalie: I live in Brooklyn. Greenpoint.
Paul: Do you work in Brooklyn or Greenpoint?
Natalie: I work in SoHo.
Paul: Ohhh. What train do you take?
Natalie: I take the G to the L to the N/R.
Paul: OK, OK, that actually sounds really complicat —
Natalie: Sometimes I’ll take the B62 to the M/J. Sometimes I will bike to the M/J. But I take a variety of routes. I have a lot of time on my hands.
Paul: What is the, what gets you to chose between one or the other?
Natalie: The weather, mostly.
Paul: OK, nice day…did you bike today?
Natalie: I didn’t bike today, no. But I bike sometimes.
Rich: Can we do a shout-out to the New York transit system?
Paul: Ah, it’s good. It’s good.
Natalie: It’s… [makes a noise that expresses how we all feel about the MTA]
Paul: Let me ask you a question: do you use Bus Time?
Natalie: Yeah, I do. I text buses.
Paul: OK, so this is, for people who don’t know, Bus Time is a giant API, it’s like a service you can use to find out when the bus is coming. I’m a heavy-duty express bus user —
Paul: Yeah, it’s really good because it’s like two blocks to my house to two blocks from my company, and it’s thirty minutes. It’s wonderful.
Paul: It’s a little more expensive, but it’s worth it. Anyway, it’s interesting that there are APIs for things like transit.
Rich: Well they killed it with Bus — there’s a great, I think it’s The Atlantic, that wrote up the backstory of how Bus Time came to be. They’re waaaay ahead of the trains, the buses are way ahead of the trains in terms of —
Paul: I mean — [muffled laughter]
Natalie: They’re above ground…
Rich: Well, I don’t think that was the only barrier to solving that.
Paul: So what you do when you’re confused about when your bus is going to come, you can look at bustime.mta.info, that’s bustime.mta.info, and you can see when buses are coming.
Natalie: Or you can text a bot.
Paul: Now see, this is the thing, I’ve never texted.
Natalie: I text the bot, of course.
Paul: There’s lots of ways to use this.
Natalie: The bot replies right away, and he’s always honest.
Natalie: Even if the bus is four stops away and that says seven minutes, you’ve got to round up.
Paul: It’ pretty good, right? It gets you within a minute. Like, if you’ve got to get there.
Rich: Also New York is a lonely place. And sometimes on a Saturday night, you just want to talk to someone.
Natalie: Mmm hmmm.
Rich: And you…just ask. Say hey. When’s the B41 coming?
Paul: I’m going to make a confession but I’m going to ask you guys first: have you ever looked at Bus Time when you’re not going to take a bus?
Paul: What about you?
Rich: I looked at the apps, yes.
Rich: I was just impressed by the whole thing!
Paul: I have a big window in my house and I look out and I see the buses go back and forth. I’ll occasionally just sort of check out Bus Time, just to see what the status of the B68 route is.
Rich: Awww. Carly Simon’s playing in the background?
Paul: A little bit of that. And there’s also an element of like, there’s a fantasy element, I think especially since I had the kids, of like, I could just go downstairs, get on the B68 in 3–5 minutes, and go to Coney Island, smoke a cigarette, drink a beer, look at the ocean. But not really gonna happen because I have two twins sitting in the other room who can’t really tolerate me being away for eight hours.
Rich: Right. But this podcast isn’t about Bus Time.
Paul: No, but it is about how people do their job, and I’ve known Natalie on and off for years, and she’s a very serious i-O-S developer.
Natalie: Yes. When we worked on a project together I was not an iOS developer.
Paul: What got you into i-O-S?
Natalie: It was a pretty straightforward transition. I was a backend developer working for media companies, as a part of SixApart, the blogging juggernaut, I think people used to use —
Natalie: — the phrase. Well, we worked on CMS technologies for so long, and these clients relied on us for our expert opinions for so long, that the Newsstand in iOS cropped up, and they said, “Hey, hey, put us in there,” and so I did —
Paul: Oh, so Apple did something.
Paul: You had an iPhone. People had iPhones. And Apple’s like, hey, we’re gonna have news now, too.
Paul: When was that? I don’t even remember anymore.
Rich: It was a few years after…
Natalie: 2010, or ‘11?
Paul: OK. So we’re talking five, six years ago.
Paul: And you had been programming…
Natalie: Perl. Python.
Natalie: Writing a lot of migration scripts and CMS extensions for these media clients.
Paul: So big web things. So then Newsstand comes down…
Natalie: So then Newsstand comes down, and —
Paul: How did you learn?
Natalie: How did I learn iOS development?
Natalie: Well, my college program was in C, so I was familiar with the basics —
Paul: Where did you go to school?
Natalie: I went to UMBC, University of Maryland Baltimore County.
Natalie: And since I had a C background it was not as horrifying as I think it is for a lot of people, but the basics were not there. I didn’t grow up using an Apple computer. I didn’t have this history and this respect for this guy named Steve Jobs. My first Apple computer was at my first job in New York in 2007 and I didn’t know how to use it, so I did everything by the Unix terminal [laughs] —
Paul: Oh, so you started —
Natalie: And people could see that.
Natalie: Now I’m an iOS developer and I look back and I just think, I was such a puppy. [laughter] It was really great.
Paul: So people who are listening may not know what C is. C is like a very low-level programming language. It’s not like the lowest level, it’s not like you’re flipping switches, but you are pretty aware of how the computer is working when you use C. You’re thinking about things like how the memory is managed, and the kind of the actual structure of the computer. Whereas something like Perl or Python, you get to forget a lot of that.
Rich: Safe to say it’s not as convenient or accessible as the sort of, let’s call it the friendlier programming languages, like Python and the like.
Natalie: Sure, I mean because you have to create and manage your memory in iOS development in Objective C anyway. It’s gotten better over the years with a couple additions to the language, but it’s a low-level thing. It’s a powerful thing.
Paul: So you’re getting into it actually at that moment, like you’re still thinking about the physical aspects of the computer —
Paul: — right? Like you’re thinking about memory management —
Natalie: Which I had never thought about before, in a practical way. As a backend developer you just develop dummy tests to prove certain conditions and it’s a very, like, human-less, not thoughtless because obviously backend developers are really brilliant people, but —
Rich: Wonderful people.
Paul: The best!
Natalie: Wonderful, but I would say certainly not as challenging as what I’ve been facing as an iOS developer.
Paul: My assumption there is that, like, a backend process tends to be very, very quick, for the most part. You’re pulling something out of a data store, you’re doing something to it, you’re going to make a web page or put it back. And so you might do that a thousand times a second, and if there’s a problem, you find out really fast, because it’s doing it over and over and you kind of fix it, and it can kind of clooj it together pretty quickly and you can avoid really bad failure states. So iOS was different?
Natalie: Yeah. iOS is different in that all of those systems-related challenges are minimized into one system, which is your app, and everything that your user of your app experiences. So you kind of own the whole stack.
Paul: So there’s all sorts of stuff happening with memory and with the pixels on the screen?
Paul: Right, because I remember, I worked on a tablet app early days, when the iPad first came out, and the things that were breaking on it, it would break like a Commodore 64 used to break in the eighties, like the screen would just get filled with stripes and stuff would kind of melt down in an old-school way that I hadn’t seen, like computers don’t usually crash that way anymore.
Natalie: Mmm hmmm.
Paul: So what is happening when something like that breaks? Do you know?
Natalie: Well on an older iPad, probably just ran out of memory and OS should have killed the app at that point, but something that bad…
Paul: Something weird is hap — like, it’s out of memory, which normally just isn’t a problem day to day.
Natalie: So this is the part that was hardest to learn as an iOS developer: I had to kind of listen to the symptoms and read between the lines of how frustrated the user was about the bug report to be able to actually understand what was going on. I mean, there isn’t a way to debug like there is on a backend web server — you can just read the logs.
Paul: Yeah, and it’s like, you know, had problem serving web page, couldn’t find data, couldn’t connect to whatever.
Natalie: Exactly. All these errors are standardized. In iOS, it’s kind of like a feeling: something doesn’t feel good right now. Is that a bug or is that intentional?
Paul: So that situation arises: what is your process to even, like, start picking that apart. What do you do?
Natalie: I ask them the typical bug-reporting questions: what did you expect to happen, what actually happened. But mostly I just try to listen to their tone, of how frustrated they are, because sometimes they just want to be heard and they just want a reply that someone is listening and actively improving their product as a result.
Rich: So this is interesting. This isn’t just ‘the thing blew up.’ Your sort of blurring into experience design and —
Natalie: Yeah. I mean, if something ‘blows up,’ I can usually reproduce something very —
Rich: Blatantly explosive that happened.
Paul: I tried to upload a 10 MB picture and nothing happened.
Natalie: Right. We traced that on the backend, the breadcrumbs are there.
Rich: You’re talking about, “I thought I wanted it to do this when they drag up and release, but it sort of looks strange and feels weird, let’s see what people say.”
Natalie: Yes. So this whole class of user-experience challenges I had never faced as a backend developer, and that was the number one toughest thing to learn as an iOS developer.
Paul: Oh, so suddenly you have to be aware of what little fingers are doing that you’ve never seen and will never see.
Natalie: Exactly. I was used to responding to error codes.
Natalie: Or, you know, out-of-memory errors. But this is just kind of a person complaining about their feelings and the app. It’s like a psychological thing, I have to actually listen and try think hard about what they’re saying.
Paul: That’s amazing, and —
Rich: So it’s not just memory management, it’s feeling management.
Paul: It’s true.
Paul: It’s trying to create better memories, and managing that.
Rich: Aw. [laughter]
Natalie: So, kind of as my skills have evolved in itself, and in the frameworks themselves, and as I’ve watched more and more WWDC videos over the years, and made more apps —
Paul: Wait, WWDC is —
Natalie: Worldwide Developer Conference.
Paul: That’s like the big Apple event that they do?
Rich: For developers.
Natalie: Coming up.
Paul: Do you ever go?
Natalie: I’ve gone twice.
Paul: What’s it like?
Natalie: Rad. It is so rad. It’s like the first week of school, and everybody is wearing their backpacks, and they’re so excited about all the new technologies, and then they go downstairs in the basement, and all the Apple developers are there, and you can ask them questions, almost any kind of questions! And they’re there, and they’re just waiting for you to ask the questions, and you can tell they only come out of their offices really one week a year to do this kind of thing, and they’re so excited to talk to you, and you’re so excited to talk to them. And the internet’s really fast. It’s so fun. It’s great!
Paul: So this is like the flipside of the you sitting in a room trying to figure out what happened to someone when they touched the screen, and like googling around and, like, puzzling it through. Instead you get to just go be in the place where all the people who have all the answers are.
Natalie: Yes. It’s…how do I describe this? You think that you have the dumbest question on earth, and you bring it to an Apple engineer, and they give you this look like, ‘I have been waiting for you to ask that question.’ And you just have this validation, and the Apple gods shine on you, and you a chorus —
Paul: How many people are there?
Natalie: 3,000. A couple thousand.
Paul: OK, so thousands of people. And you’re talking to people who literally are like, they’re writing the code for Apple. They’re writing the libraries and tools that you use —
Rich: That you’re negotiating with.
Natalie: Yeah. It’s an amazing program, because their job is to help you do your job, so you get to ask them anything. It’s a cooperative, co-dependent, loving relationship.
Rich: Except it’s one week a year.
Natalie: Yeah, it’s one —
Rich: Is anybody like —
Natalie: And not everybody gets to go.
Rich: — ”listen dude, here’s my email address, you’re going to run into some other stuff.” They’re not allowed to do that, right?
Natalie: Not really.
Rich: Yeah, so the door closes, so they’re not that cooperative, in fact. They’re cooperative one week a year. It’s like North Korea, essentially.
Paul: What is it like when WWDC —
Natalie: Swift is more cooperative, it’s been open source, they have a pretty good community.
Rich: Oh, interesting!
Natalie: They have a pretty —
Paul: We should talk about what Swift is. So when you moved over to iOS you were programming in a language called Objective C —
Natalie: That’s true.
Paul: — which is a lot like C, hence the name.
Natalie: Superset of C.
Paul: Right. So it added object-oriented programming, which we’re going to just say is out of the scope of this podcast, but like, it added object-oriented programming to C, and then about two years, three years ago, Apple released a new language called Swift.
Natalie: Mmm hmmm.
Paul: What’s the difference between Objective C and Swift.
Natalie: Oh my gosh.
Paul: It’s a pretty huge difference, isn’t it.
Natalie: It is…it’s kind of incredibly —
Paul: That’s kind of an unfair question, I’m sorry.
Natalie: So the language itself is more readable. It requires less characters per line to achieve the same effect.
Paul: And Objective C had been around since like, ’84, 1984, or like, around there, and it added a lot —
Rich: In some incarnation.
Natalie: It evolved from like, other languages of that time.
Paul: It actually came, like, it got acquired by Next, which was Steve Job’s company that he created after Apple, and then got brought back in as part of OSX, so it had a lot of stuff attached to it.
Natalie: So what Swift brought was, you know that strong typing, easier-to-read code, and a lot of new additions to the language that people working in Objective C as a career had been yearning for for years.
Natalie: Like easier extensions, like cleaner error handling, like structifying lots of strange things.
Paul: I’m not even going to try to explain what those things are, but like, Swift is different and way more modern in a lot of ways —
Natalie: Mmm hmmm.
Paul: — than Objective C. Do you find, are you using it more and more.
Natalie: I’m writing it in my spare time.
Paul: OK, so you —
Natalie: It’s my preferred fun language.
Paul: It’s fun.
Paul: OK, so —
Rich: But the day job doesn’t want you to use —
Natalie: It’s a mix. We’re starting to roll it in. My day job, I work at a place called Byte, on an app called Peach.
Rich: Byte, B-Y-T-E.
Natalie: That’s correct.
Paul: Where’s that?
Natalie: That’s in SoHo.
Paul: That’s the place in SoHo where you take all the transit?
Paul: OK. How many people work there?
Natalie: Mmmm, ten?
Paul: OK, so it’s a small company.
Natalie: It’s small, yeah. It’s definitely small.
Paul: What does Byte do?
Natalie: Byte makes creative apps for creative people. Byte was the name of our first app, it came out last fall, and it was a creative app for folks that wanted to make psychedelic layers of media? The inspiration was Super Mario Paint. It was kind of just a fun, maker kind of app. You should check it out.
Paul: And you’re sort of, like, painting with objects. Like, the things I’ve seen coming out of Byte are like, awesome skeletons, very psychedelic skulls…
Natalie: Yes. Layer the gifs, animate the gifs, compose your own music, loop a video, all together at once.
Paul: What struck me about it was it was really of the medium, like it wasn’t pretending to — like Instagram pretends to be an old camera. Like, Byte pretends to be on a portable supercomputer that can do weird stuff.
Rich: Now this is for iOS?
Natalie: Absolutely for iOS.
Rich: And available today?
Rich: And free?
Paul: And then after Byte you launched —
Paul: Which is a kind of social network…
Natalie: Peach is a social network for fast sharing with your friends. Its most notable feature is its magic words, which is, it matches what you’re typing, kind of like a Slack keyword, and then it will offer a little quick service for you, like gif lookup, or your weather, location, how much battery you have left.
Paul: Everyone got really excited about Peach and had an enormous number of opinions about it.
Natalie: Oh boy.
Paul: What was it like to be on the receiving end of so many opinions?
Natalie: It was so exciting, (a), to work on an app that exploded like that. (b) We launched as a beta, so it was a really exciting time for our backend team as well. [laughter] They did an amazing job. And we didn’t formally do any press around it, so a lot of the stories and the kind of message out there was unpredictable.
Paul: I mean, people just seemed to sort of project their own anxieties about everything onto things like Peach.
Natalie: Yeah, but we did what we did best, which was release a beta of new features and bug fixes every day during that cycle. We just kept shipping new versions and new improvements.
Paul: Peach is still running.
Paul: I log in, I see friends updating on it pretty regularly. Especially Choire Sicha, he is a serious Peacher.
Natalie: Oh my gosh, he’s a big part of Night Peach, too.
Paul: Night Peach! What is Night Peach?
Natalie: It’s when they post at night, I guess?
Paul: OK. That makes sense. That’s a good filter.
Natalie: I also learned the importance of bios in social media for younger people. We had to actually disable our friend of friend feature for a variety of reasons, but it was through that, kind of, two to three degrees of friends that I found out that teenagers really need, they need bios, they require bios. And a bio is just a tweet-length string to describe themselves, in emoji and pronouns.
Paul: But without that teenagers cannot survive?
Natalie: They require, yes.
Paul: OK. Peach is still running, but it seems like you’re on to something new.
Natalie: Mmmm hmmm.
Paul: What are you up to now?
Natalie: I have some side things that I’m doing, and the team is working on some new things. On the side I’m working on this app that was inspired by this woman who’s learning Swift, incidentally, I was volunteering at a Girl Develop It course for these women who were learning Swift after their day jobs, which is so inspirational, (a), and (b) I was just there to kind of help as a TA. And she said, “I wanna learn —
Paul: So we should tell people what Girl Develop It is.
Natalie: Oh, yeah! It is a nonprofit dedicated to helping women learn how to code as a second career.
Paul: We’ve had them at our offices, they’ve used our space to teach.
Natalie: They’re great.
Paul: They had a lot of seltzer water. Just a huge amount of…what is it, La Croix?
Natalie: Ladies love La Croix.
Paul: I guess they do. I came in and the fridge was —
Rich: Is that true?
Paul: The fridge was comp —
Rich: Or is that just a line?
Paul: No, I’ve heard a lot —
Natalie: Preferably pamplemousse, but that’s just me.
Paul: Yeah, I mean, people really, really like La Croix. I came in and we have this glass fridge and it was just filled with La Croix, and I’m like, what’s up, and they were like, “That’s for Girl Develop It.” I was like, “Oh, OK.”
Natalie: They get thirsty? I don’t know.
Paul: I respect it. People should have the beverage that they need.
Natalie: Our particular event was held at Blue Apron, and they have beautiful offices.
Paul: Do they?
Natalie: Wow. So much La Croix. So much.
Paul: Yeeaaaaah. See, I imagine — Blue Apron has to hook you up with nice stuff. It’s gotta be —
Natalie: I mean, I walked in and I —
Rich: I mean, the kitchen has to be the kitchen of Blue Apron.
Natalie: There is a kitchen! There was a communal kitchen, and I expected a man wearing an apron, you know, just kind of handing out radishes, but there was nonesuch.
Paul: [sad sigh]
Natalie: I digress. So the app inspiration came from this woman, who wanted to learn how to make an iOS app because she had an older phone, 4S, and she was running iOS 8. She was afraid to upgrade because she was so low on memory. She takes a lot of pictures, and she takes a lot of screenshots in particular. And she said, “I want to be able to organize my screenshots according to their purpose.” And I was like, “What are you talking about?” So I look at her photos, and she has all these lock screen screenshots of Spotify, of Apple Music, of YoutTube, of just things that she’s going to look up later. So…
Paul: Right, because there’s stuff always happening on your phone and you’re like, I want to bookmark this, and there’s actually no way to bookmark an event inside of an app, for the most part.
Paul: Like you can, if Spotify is open and you’re in it and you’re, like, right there at that moment, and you’re past the lock screen, you can save a song and add it to a playlist, but you’re often not in that state if you’re casually living your life instead of fooling around with your phone all the time.
Paul: So take a screenshot, and then you have a record.
Natalie: Yeah, so this woman had many, many screenshots of her own lock screen.
Paul: Is “many, many” dozens, hundreds, thousands…?
Natalie: Probably hundreds.
Paul: Hundreds. OK.
Natalie. Songs she’s meaning to look up. And that’s just manual stuff, and I thought, ‘I’m going to make an app to do that.’
Natalie: For her. So my app uses just some basic text recognition to understand if your lock screen is on and if it says Spotify — if it’s a music track listing, and then it looks up the API and builds a playlist out of it.
Paul: So you load in all these images?
Natalie: Mmmm hmmm.
Paul: How do you do text recognition? What makes that possible?
Natalie: Oh there’s a — there’s an open-source library called Tessaract that helps me do it. I’m not gonna do that.
Paul: Well no, nobody is, that’s a —
Natalie: Some other brilliant person. [laughter]
Rich: Solved that problem.
Paul: So you’re building this app in Swift. You go and you download the Tessaract library somewhere.
Natalie: Yeah, it already has a dataset against the English language, so I can just assume — I’m going to cross my fingers and it’s going to do the best it can against a music track listing of an artist.
Paul: And that comes with documentation that tells you, like, ‘hey, give us this picture and we’ll give you words back?’
Natalie: Yes. And there are some caveats to that, too. It says, ‘when you give us a picture that’s the exact size and frame, you know when it’s black and white only, we have a higher likelihood of predicting the text for, and if you give us a little more time, we’ll give you a little better quality.’
Paul: So there are all these rules and situations where using Tessaract will give you different kinds of results?
Natalie: That’s correct.
Paul: Like you can get really crappy text output if you just throw it a bunch of slop that’s in all sorts of colors, and you can get really good text output if you give it black and white?
Paul: And you can just get this thing totally for free?
Paul: It’s an open-source tool.
Natalie: It is.
Paul: OK, so this is, you have, you have the language, which is Swift.
Natalie: Mmmm hmmm.
Paul: You have the framework and the tools from Apple, which is like the XCode SDK kind of stuff?
Natalie: Yes. And a part of that is a lot of image manipulation, low-level stuff.
Paul: Oh, so Apple gives you that, kind of for free, out of the box.
Natalie: Yeah, yeah.
Natalie: Which is, it’s the best, best in class. So what I can get is, from a given photo, from a user’s camera roll, I can first assert that it’s the right dimensions of the phone.
Natalie: Because if it’s not the right dimensions, it’s not a screenshot.
Natalie: And then I can look for this magical key indicator, which is the status bar has a time in it.
Natalie: So if I look in a certain place in that image and it has something that looks like a timestamp, I’m like, pretty confident it’s a screenshot?
Natalie: And then from there every musical artist’s track and album listing is in the same place.
Natalie: Relative to the frame, so I know where to get the text from.
Paul: Oh I see, so you’re like, OK, this is a screenshot, I can sort of, use coordinates to figure that out.
Natalie: Mmmm hmmm.
Paul: Then I can figure out who the artist and the track are.
Natalie: Mmmm hmmm.
Paul: And then how do you turn the artist and the track into a song I could listen to.
Natalie: I use the Spotify API. I search against it.
Paul: So you go to Spotify and you say, hey I have exactly this much information in convenient alpha-numeric form.
Natalie: Yeah, best case.
Natalie: There are a lot of cases, and a lot of my screenshots, where it just picked up some text from some other app that was using the status bar actively. And so I have to build some more logic into my app to make sure that the user, who’s looking at these things I think are Spotify tracks, is actually confirming or denying that they all are.
Paul: So the computer could think that the song is called “Shmurghleblorblurg.”
Natalie: Exactly. Complete nonsense.
Rich: It could be like a notification.
Paul: Yeah, it could be, yeah it could be a notification.
Natalie: Yeah, or it could be a legitimate song but it’s just not on Spotify.
Rich: From something else.
Natalie: Taylor Swift or something.
Paul: Right, right. Or Prince. Prince is not on Spotify.
Natalie: Mmmm hmmm.
Paul: Sorry, I just brought every —
Natalie: No, it’s fine.
Paul: I brought everybody down by mentioning Prince, I’m sorry. So this is really interesting, so there’s all this latent stuff floating around in screenshot form.
Paul: And you’re taking that and turning it into musical playlists.
Natalie: Yeah, to me it’s about workflow. I think what I wanted to solve for this woman who had this problem was that she wanted to reduce the size taken up on her phone, and I just wanted to get, like, the rawest data from this large pool of photos. And then just like, slim it down, and deliver it in a platter for her, and say, “Here you go. Here’s the result.”
Paul: What would you say the difference is between the size, like in megabytes, of her collection of images versus what you are doing?
Natalie: I don’t know, like 10,000 to 1. I don’t…
Paul: Right. So you are shrinking down — the data that she wants is actually thousands of times smaller than the screenshot data.
Natalie: But it took so much less effort than unlocking her phone, pressing a button to add to a list, and then maybe like creating a new list out of it, every time.
Paul: See, I think people don’t realize though, like, your phone doesn’t know what it’s doing all the time? And I don’t know why, I don’t know where that comes from. But like, there’s no way for you as a programmer to go, “Actually, let’s put a big red button right here, and when anybody hits that red button it’ll save what the phone is doing, it’ll save the song they’re listening to — ”
Rich: Well, I think you’re touching on the sort of interface constraints and actually programatic constraints that iOS imposes. I mean, this is sort of one of Apple’s hallmarks, right? Which is, ‘we’re going to tell you exactly where the guardrails are, as to what you can or can’t do.’ I don’t know exactly the ins and outs of Android, but I’m guessing you can do just about anything if you’re willing to go there.
Rich: And you could put that button, there is a world, it’s not technical, the limitation. It’s policy, more so, than technical, because there could be — there was a day when it was unheard of to replace your keyboard on iPhones —
Rich: — and now you can replace your keyboard, because Apple decided to let you in. And the truth is you can put that button, if Apple said, “Hey, we’re going to let you put buttons on music — ”
Natalie: And they even offer that for the Apple Music app, on the lock screen they offer a heart.
Rich: Right, but they put that in.
Natalie: And what that heart does I’m unclear. I’m sure it’s saved, it makes a playlist, like —
Rich: It probably puts it in a hearted list.
Paul: But Apple keeps an eye on that data. That’s not going anywhere else.
Rich: But also a third-party programmer did not put that heart in. Apple put that heart in.
Natalie: Sure. Yeah.
Paul: That’s the thing, so like, I guess, so like Apple could release something called, like, FavoriteKit! And it would be a piece, you could be like, OK, this app supports FavoriteKit, meaning when you’re in lock screen you can hit a heart and it would then make some API call somewhere and say make this a favorite.
Rich: Apple historically —
Natalie: Yeah. Why not?
Rich: — has watched these patterns take hold and seen, sort of, these movements of like, hey we want this feature, it’s clear that it’s the way to go. And then they’ll sort of bless it, and let it in.
Paul: Maybe we should build that, though. If you — can you access the lock screen when you’re programming an app?
Natalie: No. I mean, you can access it if you’re playing music. You get the actions back if music —
Rich: Yeah, there’s like a handful of apps —
Paul: There’s like four or five — but like Spotify has a pause button, right?
Natalie: That’s a built-in construct, it’s not unique to Spotify.
Paul: OK, so, if there was some button that passes through from lock, you could make it the favorite button?
Paul: Maybe we should make FavoriteKit at Postlight and —
Natalie: File a radar? An Apple feature request, sure.
Paul: Yeah. OK. All right, so —
Natalie: But I feel like, going back to the UX discussion, I feel like the biggest lessons that I’ve kind of come to absorb as an iOS developer, whether I like them or not, I feel like there are three main principles that I always bring to the other designers or product people that I’m working with. And that is, like, number one, users don’t read. They don’t read.
Paul: They don’t read…anything?
Natalie: They don’t read instructions, they don’t read dialogues. They just want to do —
Rich: The thing.
Natalie: they just want to do the thing.
Paul: What about those little things beforehand, where it’s just like, “Here’s how to use this app!”
Natalie: Next! Immediately! Nobody. Never. I mean like, with, I’m actually, I’m speaking from a very realistic point of view, this is like, pretty real talk, as an iOS developer, but yeah, users don’t read.
Paul: OK. The experience of the first time that you open an app, the experience is the app experience. Don’t pretend that you’re ever going to be able to get someone to be like —
Paul: “Go up to the top right, with a double swipe — ”
Natalie: Nope! Rule number two: don’t do double swipe things. Support gestures that users would naturally do, which is tap, swipe, or maybe pinch to zoom. But that’s it. Everything else is very confusing.
Rich: Yeah like, hold and swipe —
Natalie: Double tap.
Paul: Well everybody got really into —
Rich: Triple swipe, I love Slack’s triple swipe, do you know about this?
Natalie: Five-point finger punch — I don’t know, you know?
Rich: I discovered this like two weeks ago.
Paul: Remember also they got really into shaking, like the iPad early days? That was a bad one.
Paul: Oh yeah, it supported shaking. Because you like, shake it.
Rich: To do what?
Paul: It would just register the shake, so a lot of times people would play a little vibration, or it would make a noise.
Natalie: Yeah, and then number three is give the user a chance to navigate.
Natalie: When apps don’t have either a bottom tab bar to kind of control where they are in the app or they don’t offer a back button, users are very uncomfortable.
Natalie: They feel stupid using the app because they don’t know where they are. So I always bring that back. And obviously because, like, Apple is so open-ended, and there’s almost literally anything possible because there’s so many animations you can possibly implement to make transitions between content, the navigation seems to be reinvented a lot of the times, and it’s hard to be the developer, to say, you know, this is really beautiful, this prototype, I really like it, but we’ve got to do what users know how to do, unfortunately. And that’s a tough discussion to have with designers and product people.
Paul: People want to get outside of that box.
Natalie: Yeah. I mean, the natural inclination is like, I can do better than Instagram. I can do better than what Facebook is offering. But the truth is I’ve been in a lot of user-testing sessions and users just want to do what they already know how to do, and you just have to kind of help them.
Rich: I mean the counter-argument to that is how do you a chance to innovate and try something new?
Natalie: I mean, you can still try.
Natalie: There’s still, like, you know, a lot of incredible apps that don’t offer standard navigation. Facebook Paper is my favorite.
Natalie: Not only because it offers this kind of infinite conveyor-belt of Facebook updates, but it also doesn’t have any ads, so I thoroughly enjoy it.
Rich: Is it still out there?
Natalie: It’s still out there! They haven’t updated it in a very long time. It was clearly an experiment, but it was a really fun one in UX.
Paul: What are the other beautiful apps that you pay attention to?
Natalie: Uh, that’s a good question. I mean, today everyone’s very, everyone has a lot of opinions about the Instagram redesign.
Natalie: Because they don’t —
Paul: Literally today, right?
Natalie: Literally today.
Paul: As we’re recording this, Instagram has come out with a new redesign, new logo, everyone’s excited.
Natalie: I think it’s fine. I think their nav is now just flat and black and white, the tab bars are still there, all the content is still there, it just got a nice, flat skin, and it makes it even easier to ignore the words.
Paul: Mmmm hmmm.
Natalie: Which is great.
Rich: The camera went away.
Paul: Oh, no camera anymore?
Rich: No, the logo used to be a camera.
Paul: Oh, right. Now it’s —
Rich: Which most eleven-year-olds don’t know what that is.
Paul: True. True, that’s fair.
Rich: It’s just this weird thing. So they got rid of it.
Paul: You know, it’s interesting talking to you, because you start as a backend developer, you move into iOS, and now an enormous amount of your attention is to design.
Natalie: Yes. And this, I could have never expected this in a thousand years. And the transition was not immediate, and it was very bumpy, I would say. But when you’re the only iOS developer you have to speak on behalf of what’s right for the user, and what Apple wants you to do. So you have to memorize the Human Interface Guidelines. You have to really pay attention to what people — not just like, your best users, not just your active users, but like, open-zero users, and what they’re doing.
And I asked both of you before I came in where you live. Paul, I know you live in Brooklyn, and now Rich, I also know that you live in Brooklyn, and I asked you what trains you take. What do you do in the morning on the trains? Like, what do you do with your mind?
Paul: I’ve taken the train with you. Thousands of times.
Rich: I usually read.
Natalie: Read — how do you read?
Rich: On my phone.
Natalie: On your phone.
Natalie: What app do you use to read on your phone?
Rich: Well, I’m underground.
Rich: So, uh, The New York Times app, which will go offline nicely.
Natalie: Mmmm hmmm.
Rich: And Readability, which will also go offline nicely.
Rich: So essentially a read-later app, and The New York Times.
Natalie: And what do you do, Paul?
Paul: I have a different kind of commute. When I’m on the — do you care if I’m on the train or the express bus?
Natalie: I want to hear both.
Paul: So on the train I read, usually on the Kindle.
Paul: And I listen to music on Spotify.
Rich: Kindle — not the device?
Paul: Kindle app on my iPhone.
Rich: OK, so he’s reading on his phone.
Paul: And then every now and then I will watch a movie.
Natalie: A movie!
Paul: On my phone.
Paul: And every now and then I’ll be into some game. Usually like twice a year, I’ll get into some dumb game. And then if I’m on the express bus, it’s pretty much the same, except I am online, so Twitter starts to creep back in.
Natalie: Mmmm hmmm. So let me ask a related question: do you do the same thing on your commute in your morning commute as you do in your evening commute, on your phone?
Paul: Pretty much, but I’m more likely to tweet in the morning.
Rich: Pretty much the same.
Rich: I should just try to, like, take a deep breath, I feel like, but you just don’t. You just keep eating shit. I mean, it’s worth noting, we are the crowded urban city with a big transit system. We’re the exception. Most people are driving.
Natalie: Yeah, and that’s exactly it. As an iOS developer in this city who takes the great equalizer to work every day, I’m watching people use these devices that I work on with a different part of my brain all day. So I really have to — it’s like a great context reset. I have to really think about what people are actually doing. I just kind of observed people this morning, and in a group of twelve people on an R train headed downtown, seven of them had their phones out, half of them were iPhone, half were Android. Three of those seven were playing Candy Crush or a Candy Crush spin-off.
Natalie: These are real numbers. [laughter]
Paul: No no, I saw, I mean, there was a point where it was just Bejeweled, only Bejeweled, on all the subways.
Rich: Or that, it’s a game type, it’s the one where like, the guy is endlessly running, and they’re turning corners all the time. Temple Run, kind of thing. But there’s a million variations of it now.
Natalie: Jumping over trains.
Rich: Jumping over trains, yeah.
Paul: Natalie, what do you do with your phone, aside from spying on people all the time when you’re on the train?
Natalie: I try actively to only listen to my headphones and zone out one day a week.
Natalie: And I actively try to observe the rest of the days. But when I’m not observing like a creep, I play Sudoku in the morning and then I usually read in the afternoon, on the way back.
Paul: Are you spying specifically for iOS understanding, or general human observation?
Natalie: Absolutely. I want to know what kinds of apps people are using offline, because that is a different problem set than the great majority of problems that I work on.
Paul: Do you ever just approach people directly and ask them what’s up?
Natalie: Sometimes I’ll ask them what they’re reading.
Natalie: Usually I can if they’re, like, squinting at a morning Lenny Letter.
Paul: Right, right, right. That’s Lena Dunham’s newsletter, right?
Natalie: A lot of people are just catching up on their, their like for-fun newsletter subscriptions in the morning.
Paul: So you’re observing tremendous newsletter penetration in New York City subways.
Natalie: I am such a snoop in the mornings. The L train is so crowded. How can I not?
Paul: It’s true. I see —
Natalie: It is right in front of me.
Paul: I see an enormous amount of activity on various screens, it’s true.
Paul: You just can’t help it in New York City.
Natalie: Yeah. So in my day job I’m literally, you know, solving data-animation, image-related bugs that come in. And I’m doing very technical, code-related work. But in my commute to and from every day, I’m just kind of stepping back and I’m watching the world around me, and thinking, like, I have to pay attention. I have to remember how people are actually using the things that I work on to be good at this.
Paul: It’s a life. See, I think this is really good for people to hear, because you get up and you’re living this. You’re looking at what people are up to on the train, and it’s in the context of this job.
Rich: Well, I think that what’s even more interesting is if we would have skipped over your resume, and you’d started describing what you think about and what you worry about, I wouldn’t have guessed engineer. I actually would have guessed design — I didn’t think today’s podcast was going to be about this. I thought it was going to be more about different libraries that you love.
Natalie: That’s the kind of most embarrassing, surprising part about becoming an iOS developer, is that they call it “iOS Developer” but really you’re an iOS product person. You have to know the whole package. You have to understand what people are going through when they use this product. You have to kind of understand all the design problems, all the user-experience problems, all the data problems, all of the, you know, past versions of iOS problems, all of Apple’s intentions going forward. You just have to have a lot on your shoulders, and it’s kind of a lot, you know?
I run a meet-up in this city called Cocoaheads, and it’s so supportive and it has a lot of Mac-developer veterans who’ve been doing this for many years, and they have, like, very strong opinions and a very long history with Apple. They use this group not because we’re sharing technical secrets, but because it’s almost like a support group. We need to help each other make better software and understand —
Paul: There’s so much —
Natalie: — what Apple wants us to do.
Paul: There’s just so much to know.
Natalie: There’s too much to know.
Paul: So if I wanted to go to that meet-up, what do I do?
Natalie: Check out cocoaheadsnyc.org for more details.
Paul: OK. That’s the way to get the information?
Natalie: Mmmm hmmm.
Paul: OK. So this is really interesting to me, right, because here you are, you’re a young person, you go to school in Baltimore.
Natalie: Mmmm hmmm.
Paul: And you major in computer —
Natalie: Computer science.
Paul: OK, and you’re learning C.
Natalie: I’m learning C.
Paul: What made you chose comp-sci?
Natalie: My dad was a double E PhD and so he could just do everything.
Paul: Anything with like, technology…
Natalie: He rewired the basement. He, you know, refurbished a Corvette. The man is unstoppable. He was incredible inspiration.
Paul: So you were like, ‘That’s cool. I want to — ’
Natalie: I want to do everything.
Natalie: And so I thought computer science is the key to that. So I did that, and I went to UMBC, and I was in a scholarship program for women and technology, and then…
Paul: Oh, right! We should point out that you’re a woman!
Paul: We’ve been leaving that mostly alone for this conversation.
Natalie: You can tell! [laughter]
Paul: But we were talking a little bit and you said, “You know, I’m kind of post-women in technology.”
Natalie: Yeah, so in my college program I was surrounded by women majoring in computer science, electrical engineering, and information systems, and we were coding in the dorm together, you know, kind of whiteboarding algorithms all the time. So it’s just very common for me, so…
Paul: That sounds great!
Natalie: It was heaven. And I also founded a sorority for women in technical studies, so math, science, and engineering. So it was just nerd heaven.
Paul: And normal.
Natalie. Normal nerd heaven.
Paul: You’re like, nineteen, this just is like, let’s go.
Natalie: It’s like breathing. And so, you know, in the start-up scene where it’s mostly men, and they’re kind of uncomfortable with me there, it doesn’t go both ways. I’m comfortable with you because I’m a nerd. Like let’s get this over with.
Paul: Are you still in touch. Is that a community that —
Natalie: Yeah. A lot of them stayed in the Baltimore area because the jobs there are great.
Paul: OK, so you are a computer scientist, and then you went into sort of backend-oriented work, because that made sense? What happened next?
Natalie: A lot happened next. I went to an internship at Microsoft, and then I went to a graduate program briefly…for the Department of Defense, and then I dropped out. That was in California. And I found a job on Craigslist in New York City, and I moved on a whim, and took a job with my old boss, David Jacobs.
Paul: Wow, it’s good to be in your twenties, isn’t it?
Natalie: It was awesome.
Paul: Yeah. That is really, that’s —
Rich: You sort of shrug, and you’re like, eh, why not?
Natalie: Yeah, he was like, let’s work on blogging software, and I was like, [whispered] “I don’t know what a blog is.”
Paul: That’s great. That’s great. David’s a good friend of ours and runs a company called 29th Street Publishing.
Paul: And you worked with him for quite a while.
Natalie: Very long time. Great guy.
Paul: And then migrated your skills onto iOS.
Paul: And now you are here.
Natalie: And now I’m here.
Paul: Well thank you for coming.
Rich: This was great.
Paul: Do people need to know anything that we didn’t hit.
Natalie: Live life in airplane mode.
Paul: Very good. Well, come back any time. Come and visit us. If you ever need to use our space for any event, you know what to do.
Natalie: Thank you. That’d be great.
Rich: Is that your Twitter profile?
Rich: Live life in airplane mode. That sounds like a Twitter profile.
Natalie: No, I was going to say “low battery mode,” but not everyone’s on iOS 9…
Paul and Rich: [raucous laughter]
Rich: Life advice must wait until iOS 9 is well-propagated.
Paul: Natalie Podrazik, thank you.
Natalie: Thank you guys.
Paul: Oh, what’s your Twitter handle?
Paul: All right. People should follow you.
Rich: Thank you, Natalie.
Paul: Ahhhhhhhhhhh. You know, Rich, I asked for Natalie’s Twitter handle but I should have asked for her Github handle. It turns out it’s the same.
Rich: I would have guessed it would be the same. So. But here we are.
Paul: She is a busy person.
Paul: She is up to stuff.
Paul: I also learned actually quite a bit about the gestalt of iOS programming, which is big and complicated.
Rich: And the struggle. Sort of just a collective…
Paul: You have to deal with this enormous monolithic organization —
Rich: It’s a lot, man.
Paul: But it seems like, what’s interesting, listening to —
Rich: And you only get to talk to Daddy one week a year!
Paul: I know, it feels like —
Rich: What kind of visitation rights are these?
Paul: It’s not good. That part’s not good, but it’s so tricky, right? What is interesting, listening to her, is how she feels that Apple is very strongly in the interest of the user and that it’s her job to work with them to get that software into people’s hands.
Rich: I think that is the culture that they’ve created.
Paul: That’s the mission, right? And that’s really interesting. That is probably one of the unbelievable piece of their success: they take a backend programmer, give them the keys to this, like, the constrained keys to the kingdom, and say, “OK, go forth and make something really good along these lines.”
Rich: And care about these things.
Paul: Yeah. They broaden what you need to do.
Paul: All right, so we should tell everyone that this is Track Changes.
Paul: I’m Paul Ford.
Rich: Rich Ziade.
Paul: We’re the co-founders of Postlight, a nice agency that would love to talk to you about —
Rich: Just a warm, friendly place.
Paul: We build iOS apps…
Rich: We build all apps…
Paul: Yeah, we build Android, we build backend, we build web apps, we do all that stuff. So.
Rich: [email protected] —
Rich: There we go. Have a great week, Paul.
Paul: Talk to you next week, and actually probably in the next two minutes as we walk back to the office.