Dan Heath: Taylor Hughes is a software engineer. He's worked at small startups and some of the biggest tech companies like Facebook and Google. He was at YouTube in 2011 when he developed a feature that still exists today.
Taylor Hughes: Yeah, let's say you're, you know, watching an episode of TV and like something really funny happens at this moment, you can share the video at the moment.
Dan: So if you just share a YouTube video with a friend, it will start at the beginning by default. But if you wanted them to start at a specific moment, you know, eight minutes and 13 seconds in, then you can use the checkbox Taylor created.
Taylor: When you press share on YouTube, it pops open a little dialog and then there's a checkbox in there that says "Share link at this time," like where the video currently is playing.
Dan: I've used that.
Taylor: Yeah, that implementation with the checkbox and the shareable URL, it's been like exactly the same since I made that in like 2011.
Dan: So Google, which of course owns YouTube, actually earned a patent for Taylor's tiny checkbox.
Taylor: The big companies are trying to just get as many patents that- as they can because it's a defensive strategy so that when a patent troll comes after you or, you know, Larry Ellison decides to come after you for something, you can throw, you know, like, well, actually you're violating my patent on this checkbox in the video share flow.
Dan: Oh, that's so interesting.
Taylor: Uh, so you basically... The product managers in the company are kind of incentivized to patent anything that they can.
Dan: Taylor doesn't earn residuals for his checkbox unfortunately, though he did get a bonus from Google. And he also got the satisfaction of creating something that many, many, many millions of people have used.
Taylor: It's fun that it's become a thing that people know about. At the time, I think, you know, in 2011 it was just a throwaway sort of piece of work, but it's just funny that that thing survived.
Dan: I'm Dan Heath and this is What It's Like To Be. In every episode, we walk in the shoes of someone from a different profession, a PR crisis manager, an ice cream truck driver, an audiobook narrator. We want to know what they do all day at work. Today we'll ask Taylor Hughes what it's like to be a software engineer. We'll talk about how one small code change on Christmas morning led to children crying around the country, who software engineers tend to argue with inside their teams, and why so many of them have irritable demeanors. Stay with us.
Taylor is now the co-founder and chief technology officer for a startup called Hypernatural AI. So customers can create shareable videos using its AI tools, and Taylor spends a lot of his day fixing code.
Taylor: So we have customers writing in with things that are broken every day. I actually broke a piece of the creation flow yesterday in the live website for like 25 minutes, and so I got 10 support emails during that time and I had to then respond to all the support emails after I fixed it. There's... Half of my time right now is sort of like dealing with stuff like that, and then we try to spend the other half thinking about like, okay, here's the next big thing we wanna launch that sort of changes across the whole flow of someone signing up into the product. We wanna sort of like make something major.
Dan: Consumer tech is constantly changing, and so is the way it's rolled out to consumers.
Taylor: The ancient philosophy of the '90s and shrink wrap software is like referred to as like waterfall style of development. So you sort of like make all these changes on your local computer and no one ever sees them, you know, until finally the team is ready and you've, like, you've put the last little, like, touch on it, and then it goes to, like, somebody else who runs QA.
Dan: QA is quality assurance. They're the people who test the software before it's finalized, and then-
Taylor: You release it to everyone in a box.
Dan: And then you have another version in four years after that.
Taylor: Yeah, exactly. And most people work now, you know, by basically trying to build all of the little pieces without breaking the current thing and kind of continuously pushing that out.
Dan: That's such a good and helpful description. You wanna keep adding the new things without breaking the old things, and there's just a natural tension there 'cause every time you poke at the system, you're just taking the risk.
Taylor: Yeah, yeah, and that's the job. The people who are really the amazing software engineers in at least the kind of product-focused, uh, world that I live in are the people who can make massive changes that solve real business problems while also not breaking everything. The whole job really is sort of like you hold the structure of what the existing thing does in your head. It's like this big set of flowing gears and arrows and stuff, and then you wanna just tweak like this one, uh, and then you ship it and make sure that like everything's still working and that your new thing is also working, and then tomorrow you do the next thing until all of a sudden you have a- a different shape at the end.
Dan: So when you roll out new features or new releases, is it easy to get feedback? I can imagine people complaining and I could also imagine we're so used to bugs that we just work around them and don't say anything about it. How do you get feedback that you can trust?
Taylor: Yeah, it totally depends on the scale and the type of company that you have. So, uh, one of my friends from a previous job just built an app that was an AI therapist, so they didn't know what the users were saying to their app because that would be an invasion of privacy.
Dan: Mm.
Taylor: So they relied 100% on sort of like, "Hey, like, please tell us if something's wrong 'cause otherwise we're not gonna know." In massively scaled consumer things like the Facebook app or YouTube.com, there's all sorts of mechanisms for measuring what people are doing, so you mostly rely on sort of the metrics in the experiment group that you're changing something in to reflect what you've done. So for example, if you have the Facebook news feed and you make the like button, you know, the actual like thumb, if you make the thumb like 50 times bigger than it is right now so it's just this huge thumb, more people might click the thumb, so you'll probably see an increase in that group of likes. However, it might also be like a terrible experience because you've got this enormous thumb in the middle of News Feed. So you probably won't have as much continuous scrolling and usage because people will be probably mad that their news feed has these huge thumbs in it. So all that data will be reflected in the experimentation framework in the company automatically.
Dan: That's really powerful. I mean, to have that level of detail automated where you can kind of follow not just the immediate implication of, like, did more people click like or not, but also, you know, the next layer of did they spend more time on the site or did they abandon because it was annoying or whatever.
Taylor: Yeah, and then you have the, like, at Facebook it was super interesting because you also had the network effects. So when my experiment group causes less likes on a certain type of content, that also causes that content to not travel as far or get as many views, right? So, like, you can have really interesting inter-group, uh, experimentation results that are super hard to actually digest. So a lot of times what, uh, Facebook will do is turn on a new feature, especially if it's sort of making really interesting and, and hard to measure interaction effects. They'll turn it on, like, just in New Zealand.
Dan: Hmm.
Taylor: So, uh, New Zealand or Argentina or there's a bunch of countries that are commonly getting, like, the weirdest Facebook features first.
Dan: So I feel like we have this relatively elaborate stereotype of a software engineer. I, let, let me air it out, and you tell me which parts are true and which parts are false. So it's someone very young, almost always male in the stereotype, um, hoodied, wired on like six Monster energy drinks, weirdly in the dark. Like, the, uh, why, why do they work in the dark? Often alone, they're, they're kind of irritable, difficult to work with, but they're freak geniuses. They type at like 200 words a minute and can solve... So what's true? What's false?
Taylor: So generally, the male-female split thing is real, and there's a pervasive problem with trying to get more women into the field that are, that's trying to be addressed in a million different ways. But yeah, like, current state of the world is, you know, plus 90% of software engineers are, are probably guys. So, you know, that's pretty accurate. I think the irritability and the sort of, like, the lack of social graces I think aligns pretty well with kind of, like, what makes you good at getting that whole context of the way that the system works into your head at once. Like, you have to be a little bit of a weirdo to be able to kind of absorb that up into your brain all at once.
Dan: Mm-hmm.
Taylor: Um, and so I think that that probably aligns a little bit with people who are a little bit pedantic and that care about the difference between this way of doing something and this other way of doing something. And I think, like, that sort of co-aligns with potentially being, um, a little irritable. The other part that I think feeds into the irritability is there's kind of a weird thing which is that all of the business rules of the way that a company's software works, anybody who works at the company knows a part of them. But the software engineer who's adding the new feature has to know about every single one pretty much when they're in the code. So when you say, like, "Oh, let's just change that button from red to blue. You know, why, why not? That'd be so much more fun. Blue is more aligned with our brand. Like, that's a much better color. I think it's a warmer color for..."
Dan: And it's so simple. I mean, it's just a button. Uh, who cares?
Taylor: It's just a color, you know? And then the software engineer goes in there and says like, "Well, you didn't think about dark mode, and you didn't think about, you know, in Arabic, it's RTL. So it's actually, it's on the wrong side. It's not going to be next to the other thing that's blue." Uh, whatever.
Dan: That's a great example.
Taylor: You know, then you dive in and say, like, "Actually, you know, a paid user, it's got this badge on it, and you didn't come up with the case of, like, what happens when it's got the badge on it." And so, like, you're taking everything that the business can do and then you're, you're encoding it in all these files, in these workflows, and then you're like, you know, just, "Why is it so hard to change that?" It's like, well, you didn't... You know, there's so much there.
Dan: And it seems like it requires so much concentration, which I assume is why working in the dark often alone fueled by Monster Energy. Like, in my brief and, and unsuccessful time learning to code in college, like, I just remember these maddening wormholes where something wasn't working and you're trying to debug the code. And then, like, three hours later, you figure out, like, you're missing one closed parenthesis or something.
Taylor: Totally.
Dan: And that was both the beauty and the terror of the job is that you knew it was solvable, but that didn't mean it was gonna be an easy process.
Taylor: Yes, I, I do think that, you know, there's certain characteristics of, you know, is it, is it like an ornery person who kind of enjoys, like, you know, I gotta figure out all these weird cases and then convey them to somebody and then kind of be a little bit pissed when they d- you know, they don't understand the complexity. Uh, so I think that that, that resonates. I think the thing that's the biggest difference, and this is also, like, the Hollywood archetype of like a hacker, like, hacking into the mainframe and they're, like, they're doing it on a laptop in front of you and there's like 10 people around them. And like, then there's an, like, the Russian guy is also hacking from the other side and, like, it's a race. Or like the solo genius off in the corner, like, creating the best algorithm that the world's ever seen. That's crazy. Like, maybe that happens. Maybe, maybe there's somebody who, who does that. But most of our work is, like, it requires so much concentration that you really can't be under the gun. You really have to get time and space mentally to, like, figure out the plan, but it kind of can't be on the spot.
Dan: Hey, folks. Dan here. We are currently looking for someone in the food world, maybe a head chef, a restaurant owner, a food scientist. As always, we're looking for people who love their work. They've been doing it a long time. And of course, they've got to be good talkers, storytellers. Do you know someone like that? Send them to us. Have them leave us a voicemail. That number is always, always in the show notes. And I'll also share it right now for those of you with perfect memory for numbers, 919-213-0456. Thanks, folks. And now back to the show.
I asked Taylor how you can prove that you're good at software engineering and how you can spot those talents when you're hiring.
Taylor: Well, it depends a lot on the... in the environment you're in and, like, the actual interview process to try to understand if someone is good and you should hire them is very hard. And I, I don't trust my own interview skills at all because it's just so hard to actually tell.
Dan: Why?
Taylor: You, you have a whole set of interpersonal skills which are important. So like, you know, can you talk on a podcast about software engineering or something? Um, and that has almost nothing to do... but it has a little bit of something to do with being able to be functional on a software team. So like, if you are good interpersonally, you can be easy to, you know, discuss bugs with and sort of bounce ideas off of, and that can be very helpful for a team, but also it's not required for sort of, like, shipping a bug fix to production very quickly and being very detail-oriented in doing that. So it's easy to sort of over pivot on, on the wrong attributes.
Dan: Shipping to production, by the way, just means taking the code changes you've been working on and pushing them into the real world, like onto the actual apps that people are using on their phones and computers, and that can be dangerous. Taylor says even code changes from good software engineers sometimes cause crashes.
Taylor: One way to tell that I think someone's a great software engineer is like, first of all, just like, "What have you done? Okay, you've been working for ten years. Tell me the ten amazing things that you've built." Which isn't sort of like the cleverest solution to this problem or whatever, it's just like, you know, you're constantly putting things out there. And the other side of that is like, okay, like, how many times have you taken down production and how did you respond to that? Um, because if you're not taking down production, you know, it's... You don't wanna do it all the time, you don't wanna be the bull in a China shop, but at the same time, like, you're always breaking stuff just because it's impossible to sort of, like, know ahead of time all of the possibilities of what the code might do.
Dan: So it's almost like bad news if someone hasn't broken things because it means they weren't working on anything of substance. Is that what you're saying?
Taylor: Yeah. I mean, I think you're not pushing enough code to production if you're not also, uh, you know, occasionally breaking production. The ideal state also as you sort of, like, get more used to deploying changes is, how can you minimize when your code does go bad? So, the real sign for me of working with someone who is awesome is like, they figured out the screen was melting before anybody told them, and they already turned it off, and they already have a fix in review. You know, the proactive, like, self-aware monitoring of sort of like the state of the world and then, uh, driving to fix it.
Dan: So, one thing I wanted to ask you about is, you know, in organizations there are natural tensions between certain roles. Like, you know, classic one is marketing and sales and, you know, the marketing people are like, "The salespeople just aren't selling the product. It's brilliant." And the salespeople are like, "Uh, b- you know, the marketing people built the wrong product," or, "It's the wrong framing and you need to work on price and you need..." blah, blah, blah. Where are the natural tensions with software engineers? Like, if you're fighting with someone, who is it likely to be?
Taylor: So in a software development team, typically you have a product manager at the center. They're the person who is kind of talking to the CEO and anybody in between them, coming up with what should the product do next. Like, what's the big feature? So for example, at Facebook when I'm doing that stupid, like, giant Like button experiment, it's like, "Oh, we wanna make UI buttons, like, 50% bigger across the website because that's gonna drive engagement," whatever. So the PM's coming with sort of like the strategy. The PM then usually works with the designer, and so there's a, a design team. Maybe they have their own structure of how they do design reviews, but they say, "Okay, cool. The Like button looks like this right now. Guess what? Five times bigger." So they come back with, like, the pixels drawn out to actually show you what that's gonna look like. They do a review with the CEO. The CEO's like, "Oh, my God, I can't wait for this huge Like button," and then it goes to an engineer. Uh, the engineer may or may not be in the room for that conversation also, but in old school work, maybe they're not involved at all. They just receive sort of like the file that says here's how big the button's gonna be. So the tension is usually between engineering and product because the product people want, want the button to be 50 times bigger and then the engineer says, "Look, we can't make it 50 times bigger. We can only make it two times bigger because there's this comment button and then there's oth- uh, you know, in Arabic actually, then this way it flows, it doesn't go this way." So there's always a sort of like back and forth about the scope that you're gonna take on between product and engineering.
Dan: But the challenges of software engineering go well beyond organizational tensions. Sometimes the enemy is the code itself, and the consequences of a screw-up can be huge. Earlier in his career, Taylor worked at a startup that developed tools that could be used by other app developers. So, let's say you were building your own app and you wanted to include one of those pop-up windows like, "Are you enjoying our app? Please rate it, blah, blah, blah." And then rather than build that feature yourself, you could just rely on Taylor's tools and snap it right in. So anyway, during this era, Taylor went home for Christmas one year and all seemed quiet, at least at first.
Taylor: Part of my life as a person who builds things on the internet is that I'm constantly being notified when my things are broken. So, I actually chaperoned a field trip the other day for my son and like, as I stepped into the school, I got a page, uh, that said my site was down. So this happens-
Dan: Ugh.
Taylor: ... all the time. I'm constantly waiting for the notification sound that I've been paged. So this service that was powering these pieces of UI in people's apps, I got paged on Christmas Eve. So I'm sitting around at my parents' house. It's a party with, you know, 50 people. It's all people I haven't seen in a million years 'cause I lived in San Francisco and I'm flying back to Chicago and catching up with everybody and, and my phone keeps dinging. So I open it up and I look at the graphs and, and basically you can see really plainly that we're basically getting, you know, five times as much traffic as we've ever gotten before, right now on Christmas Eve. But the site was kind of healthy. It was pushing through. So I was like, "Okay, you know, I'll have another, uh, Christmas cocktail and check in later." And it wasn't until the morning that I got, like, the real scary ping, which is like the site is completely unresponsive. We've got ten support emails already about the apps are down, nothing is working, you know, oh .
Dan: So Taylor starts trying to figure out what was spiking the traffic-
Taylor: Computer programs always have logs. So I open up the production logs to see what service is talking to me, and it's like not something that I recognize, it's something like roughly having to do with a race car or something, I'm not totally sure, and I keep looking and all I wanna do is get the service back up because we have tens of customers who are already pissed at me on Christmas morning and I also wanna go, like, open presents with my nephew.
Dan: Right.
Taylor: Um, and I've got a headache. It's like a situation. So I figure out who the app is that's basically destroying the servers, and I just decide to turn it off. So I shipped a little change to our production environment that just said, "Okay, if it's this app, respond with kind of, you know, just an empty thing." Um, and the goal was just like, "Let's have the site back up. Let's not deal with this until, you know, New Years or whatever." So I do that, I go back to the Christmas festivities and I just start getting a couple other pings. So I look at my phone, you know, there's an email, you know, kind of ignore it, and it isn't until I get, like, the third one that's from the same guy, but now this time it's on LinkedIn and he's like, "Hey, my app is crashing right now. Every time you open my app, it's crashing, and I think it's because of your software." So I rush back to the computer and I'm like, "Oh my god," and it turns out that he had built this companion app for a toy, a race car app toy, and so kids were getting this race car-
Dan: From Santa.
Taylor: ... and they're, from Santa or whatever on, you know, it starts on Christmas Eve 'cause some people get some early presents or whatever, then on Christmas morning it's this deluge because everybody's opening their things, and the first thing you have to do is you have to install an iPhone app to control it.
Dan: Oh. Oh, no.
Taylor: So, so you open the thing, it's like, "Oh my god, this is gonna be so sweet, can't wait to play with it. It's gonna be so fun. It's gonna be so fun when you, when you connect the Bluetooth with the app so that you can actually use the toy. That's gonna be sweet." So then you download the stupid app obviously, and then you have to, like, link up your sign in or whatever, and then it just crashes. And so the children, you know, around the world are just, like, having this awful time with this, and it's, this goes on for, like, I was barely paying attention 'cause I was trying to, you know, play with my nephew and stuff while the bad fix was out there.
Dan: It turns out, as is often the case with software, there was a compatibility issue. The app developer had installed an old version of Taylor Software, and when Taylor rolled out his quick fix, the old software didn't know what to do with it and completely crashed.
Taylor: So this is actually, like, the most embarrassing part of probab- like, anything that I've shipped I think, 'cause it's just, like, so viscerally terrible, and it was, like, such a throwaway fix that I did to also cause the really bad part, 'cause it wasn't actually crashing until I did that bad thing when I basically tried to get our servers to shed some load, uh, and just shipped that sort of, like, crappy fix. That was what actually caused the crash. So the whole app was crashing for the entire world for, like, two hours, and, um, if you look up the Amazon reviews for the race car product, I did this a couple years ago, you can actually still find the, the vitriolic, you know, "You ruined Christmas. This is the worst product I've ever bought." And it's, yeah, that's, like, obviously the software engineer who, who installed their SDK at whatever the company is, is... hopefully they aren't listening so they don't know it was me.
Dan: So, Taylor, we always end our episodes with a quick lightning round of questions. Here we go. What is a word or phrase that only someone from your profession would be likely to know, and what does it mean?
Taylor: Okay, I think a good one is tech debt.
Dan: Tech debt.
Taylor: Have you heard of tech debt?
Dan: I've heard the term, but I'm not sure I could define it.
Taylor: Okay, so it means that you wanna get this feature out, and if I wanna support all of the languages in the world, like, it's gonna take four months, but if I wanna get the feature shipped tomorrow, I have to cut corners and kind of, like, do the changes in a hacky way and maybe not test all these cases and, you know, maybe the app crashes in, in Hindi or whatever. Uh, so tech debt is kind of like when you keep working like that, you build up, you know, a bunch of broken stuff along the edges, and you need to, you know, eventually pay down the tech debt by just focusing on quality. So, like, let's actually, like, okay, we're not gonna do any new like buttons. Let's go back, make sure that the app works great in Hindi and sort of, like, resolve the tech debt.
Dan: And so does the tech debt eventually get paid off, or do you always just have a mounting pile of tech debt that never goes away?
Taylor: Uh, depends if you ask the PM. They're never gonna wanna pay down the tech debt. Just kidding. But the, uh, yeah, like the- ... the antisocial engineer is gonna wanna pay that down and fix it up because they want it to be nice and tidy and the product people are gonna wanna ship the next, you know, thing that increases revenue or whatever, um, and so it's always a tension of, "Can we go back? Can we have a quality day? Can we do a quality week?" In the big companies you try to sort of, like, build in some incentives for that, but yeah, it's a whole thing.
Dan: What's the most insulting thing you could say about a software engineer's work?
Taylor: You write spaghetti code.
Dan: Oh, what does that mean?
Taylor: Uh, that means your code is not well organized, I cannot understand it, it doesn't connect in logical ways. If you looked at, like, a nice beautiful code base, it would be arranged in sort of a, uh, like a nice flowchart. So I'm over here in News Feed, and newsfeed needs to talk to the recommendations engine and the ads engine and you have these nice clean arrows. When it's spaghetti code, it's just a mess of s*** that's all talking to each other and calling each o- you know, from crazy places and you can't really reason about where to make the change because it's just all over the place.
Dan: What's a tool specific to your profession that you really like using?
Taylor: Uh, the one right now, a- and it's, like, a little basic actually for being in the AI world, but Copilot, which is basically AI auto-complete. So you type, you know, class foo and then you wait, just wait a second, and Copilot sort of, like, understands what you wanna do and then gives you a first pass of, like, what that class might look like, and it's basically amazing. When I'm, when I'm on, like, an airplane and stuff I can barely work now 'cause it's, I don't wanna type all this stuff. I want, I want this thing to be able to figure out what I want it to do and then write it for me.
Dan: What phrase or sentence strikes fear in the heart of a software engineer?
Taylor: This site has been hacked.
Dan: Ooh. Have you seen that before?
Taylor: Uh, I have seen many sort of like bugs that you could potentially, you know, interpret as some kind of a little, little bit of a hack. But I've seen one case when I was working on... I was helping support one of my friends who had a, uh, had a crypto website and there was a longstanding bug in the code that was years old, but somebody figured out how to turn it into a full-scale hack and basically stole a ton of money from this person's users by basically taking over the screen and sort of like making it look like something else.
Dan: And there's a real profit motive there, I mean, if you can break into the crypto sites.
Taylor: Yes. And then it was... The money was instantly gone and we traced it to, you know, Turkey. It was like, it was instantly gone and not recoverable.
Dan: What is an aspect of your work that you consistently savor?
Taylor: I love to reproduce a weird bug, a bug report from a user. So it's like, uh, we had a user who wrote in that all of a sudden our software was not generating nice pictures of birds anymore.
Dan: So just to break in here, remember Taylor's current startup is one that takes prompts from customers, like show me a pileated woodpecker pecking on a tree, and the AI will spit out a polished looking video. So Taylor says their first reaction was that this bug report couldn't possibly be right. But then...
Taylor: We went one step deeper. We like, you know, asked the person for more information and she's like, "Oh, well actually, you know, if you do a pileated woodpecker or like a, you know, a female robin, like it might get that right, but it really won't get, you know, uh, a coastal warbler or like a crested whatever. You know, it... Tho- those are just off the map." And I'm like, "Wow, she really knows a lot about this." So then, you know, you take that and you try to put the inputs in the right spot to figure out if the system's really messing something up. And the bird one, it was actually very easy to repro and it's extremely pleasing to be like, holy crap, like our system's actually really bad at birds. So sort of like connecting the dots of how the software's broken and then creating a path to fixing it is, is very fun.
Dan: Because what, what does it represent for you? It's like all the sudden something that seemed kind of random and noisy is actually diagnostic of something systemic that you understand. Is that the idea?
Taylor: Yeah, it's, it's like a puzzle.
Dan: Hmm.
Taylor: So, like, every day at 5:00 PM, we get one person who emails us and says, "You know, the button's doing this. What's the deal?" And then you figure out, oh, there's actually this job that runs every day in the background and it temporarily puts pressure on the database. And thus, this other query that normally works totally great is failing and timing out for this user who happens to be in Istanbul. And you’re, like, "Isn't that cool?"
Dan: This is my very last question, I promise. This is from a listener. Uh, this is sort of a weird meta question. What question do you wish people would ask when they first hear what you do for a living?
Taylor: I think the problem is that most people don't know where to start. Like I recently moved to the Midwest from San Francisco. In San Francisco, when you meet a random person, the likelihood that they're a data engineer at whatever company is like very high, so they will know exactly what you're talking about most of the time. Here, I think people don't know what that even means. So I say like, "Oh, I have a software startup. We're building, uh, you know, an app where people can build videos and they can type in, you know, like spooky story at night and out comes a video." I think like people are like, "What?"
Dan: That seems very clear to me. I mean, you didn't use a lot of jargon in that pitch. I don't know.
Taylor: I know, but I think like the job of building it is like so weird. It's like a... I think most people, when you think of consumer software, um, I also have an, uh, photo sharing app, and I think when people see that app, they think like, well, there must be a company about it and there's probably a couple dozen people who work on it or whatever, and I'm not gonna get one of those people when I send an email to this email address certainly. And it turns out it's like just me and my co-founder getting an angry email from somebody and they didn't realize that it's like, well, there's three of us right now. And like yeah, of course I care about your bird problem.
Dan: That, that is so wild that you're like the founder and you know, world-class engineer and like tech support.
Taylor: Yeah. We're right in the weeds, but that's how you find out when everything's on fire and that you need to fix your bird model.
Dan: Taylor Hughes is a software engineer. Right now he's the co-founder and CTO at the startup Hypernatural AI. You can check it out at hypernatural.ai.
I keep thinking about the idea of tech debt, the choice you make to put off certain foundational work for the sake of short-term benefit. Taylor highlighted the natural tension that exists between product managers who want to get the new feature out there right now and software engineers who want to slow down and perfect the current system.
And obviously it's not like one side is right and the other is wrong. You've got to have a balance and that balance might well vary by what you're doing. So if you're creating video games, then holding out for code perfection is probably not a good choice, but if you're building airplanes or heart valves, we'd really like to see those perfectionists in charge.
The same tension pops up in so many different places. Film directors want that perfect lighting and the perfect scene, and producers want the movie done on time and on schedule. Or think about architects and builders. The architect wants that elegant curve in the wall, but the builder says it'll take three extra months and cost five times as much.
I don't want to exaggerate the distinction here. I mean, after all, Taylor has to operate on both sides of the line, as we heard. He has to hammer out that good enough code for today while also tracking the imperfections for a future improvement tomorrow.
Tracing mysterious errors to their source, jousting with product managers, wrestling with thickets of interconnected code, and rolling out new features without breaking the old ones. Folks, that's what it's like to be a software engineer.
A shout out to recent Apple podcast reviewers, TimTaylor379, ABCD157, and Dexistential. This episode was produced by Matt Purdy. I'm Dan Heath. See you next time.
Taylor Hughes: Yeah, let's say you're, you know, watching an episode of TV and like something really funny happens at this moment, you can share the video at the moment.
Dan: So if you just share a YouTube video with a friend, it will start at the beginning by default. But if you wanted them to start at a specific moment, you know, eight minutes and 13 seconds in, then you can use the checkbox Taylor created.
Taylor: When you press share on YouTube, it pops open a little dialog and then there's a checkbox in there that says "Share link at this time," like where the video currently is playing.
Dan: I've used that.
Taylor: Yeah, that implementation with the checkbox and the shareable URL, it's been like exactly the same since I made that in like 2011.
Dan: So Google, which of course owns YouTube, actually earned a patent for Taylor's tiny checkbox.
Taylor: The big companies are trying to just get as many patents that- as they can because it's a defensive strategy so that when a patent troll comes after you or, you know, Larry Ellison decides to come after you for something, you can throw, you know, like, well, actually you're violating my patent on this checkbox in the video share flow.
Dan: Oh, that's so interesting.
Taylor: Uh, so you basically... The product managers in the company are kind of incentivized to patent anything that they can.
Dan: Taylor doesn't earn residuals for his checkbox unfortunately, though he did get a bonus from Google. And he also got the satisfaction of creating something that many, many, many millions of people have used.
Taylor: It's fun that it's become a thing that people know about. At the time, I think, you know, in 2011 it was just a throwaway sort of piece of work, but it's just funny that that thing survived.
Dan: I'm Dan Heath and this is What It's Like To Be. In every episode, we walk in the shoes of someone from a different profession, a PR crisis manager, an ice cream truck driver, an audiobook narrator. We want to know what they do all day at work. Today we'll ask Taylor Hughes what it's like to be a software engineer. We'll talk about how one small code change on Christmas morning led to children crying around the country, who software engineers tend to argue with inside their teams, and why so many of them have irritable demeanors. Stay with us.
Taylor is now the co-founder and chief technology officer for a startup called Hypernatural AI. So customers can create shareable videos using its AI tools, and Taylor spends a lot of his day fixing code.
Taylor: So we have customers writing in with things that are broken every day. I actually broke a piece of the creation flow yesterday in the live website for like 25 minutes, and so I got 10 support emails during that time and I had to then respond to all the support emails after I fixed it. There's... Half of my time right now is sort of like dealing with stuff like that, and then we try to spend the other half thinking about like, okay, here's the next big thing we wanna launch that sort of changes across the whole flow of someone signing up into the product. We wanna sort of like make something major.
Dan: Consumer tech is constantly changing, and so is the way it's rolled out to consumers.
Taylor: The ancient philosophy of the '90s and shrink wrap software is like referred to as like waterfall style of development. So you sort of like make all these changes on your local computer and no one ever sees them, you know, until finally the team is ready and you've, like, you've put the last little, like, touch on it, and then it goes to, like, somebody else who runs QA.
Dan: QA is quality assurance. They're the people who test the software before it's finalized, and then-
Taylor: You release it to everyone in a box.
Dan: And then you have another version in four years after that.
Taylor: Yeah, exactly. And most people work now, you know, by basically trying to build all of the little pieces without breaking the current thing and kind of continuously pushing that out.
Dan: That's such a good and helpful description. You wanna keep adding the new things without breaking the old things, and there's just a natural tension there 'cause every time you poke at the system, you're just taking the risk.
Taylor: Yeah, yeah, and that's the job. The people who are really the amazing software engineers in at least the kind of product-focused, uh, world that I live in are the people who can make massive changes that solve real business problems while also not breaking everything. The whole job really is sort of like you hold the structure of what the existing thing does in your head. It's like this big set of flowing gears and arrows and stuff, and then you wanna just tweak like this one, uh, and then you ship it and make sure that like everything's still working and that your new thing is also working, and then tomorrow you do the next thing until all of a sudden you have a- a different shape at the end.
Dan: So when you roll out new features or new releases, is it easy to get feedback? I can imagine people complaining and I could also imagine we're so used to bugs that we just work around them and don't say anything about it. How do you get feedback that you can trust?
Taylor: Yeah, it totally depends on the scale and the type of company that you have. So, uh, one of my friends from a previous job just built an app that was an AI therapist, so they didn't know what the users were saying to their app because that would be an invasion of privacy.
Dan: Mm.
Taylor: So they relied 100% on sort of like, "Hey, like, please tell us if something's wrong 'cause otherwise we're not gonna know." In massively scaled consumer things like the Facebook app or YouTube.com, there's all sorts of mechanisms for measuring what people are doing, so you mostly rely on sort of the metrics in the experiment group that you're changing something in to reflect what you've done. So for example, if you have the Facebook news feed and you make the like button, you know, the actual like thumb, if you make the thumb like 50 times bigger than it is right now so it's just this huge thumb, more people might click the thumb, so you'll probably see an increase in that group of likes. However, it might also be like a terrible experience because you've got this enormous thumb in the middle of News Feed. So you probably won't have as much continuous scrolling and usage because people will be probably mad that their news feed has these huge thumbs in it. So all that data will be reflected in the experimentation framework in the company automatically.
Dan: That's really powerful. I mean, to have that level of detail automated where you can kind of follow not just the immediate implication of, like, did more people click like or not, but also, you know, the next layer of did they spend more time on the site or did they abandon because it was annoying or whatever.
Taylor: Yeah, and then you have the, like, at Facebook it was super interesting because you also had the network effects. So when my experiment group causes less likes on a certain type of content, that also causes that content to not travel as far or get as many views, right? So, like, you can have really interesting inter-group, uh, experimentation results that are super hard to actually digest. So a lot of times what, uh, Facebook will do is turn on a new feature, especially if it's sort of making really interesting and, and hard to measure interaction effects. They'll turn it on, like, just in New Zealand.
Dan: Hmm.
Taylor: So, uh, New Zealand or Argentina or there's a bunch of countries that are commonly getting, like, the weirdest Facebook features first.
Dan: So I feel like we have this relatively elaborate stereotype of a software engineer. I, let, let me air it out, and you tell me which parts are true and which parts are false. So it's someone very young, almost always male in the stereotype, um, hoodied, wired on like six Monster energy drinks, weirdly in the dark. Like, the, uh, why, why do they work in the dark? Often alone, they're, they're kind of irritable, difficult to work with, but they're freak geniuses. They type at like 200 words a minute and can solve... So what's true? What's false?
Taylor: So generally, the male-female split thing is real, and there's a pervasive problem with trying to get more women into the field that are, that's trying to be addressed in a million different ways. But yeah, like, current state of the world is, you know, plus 90% of software engineers are, are probably guys. So, you know, that's pretty accurate. I think the irritability and the sort of, like, the lack of social graces I think aligns pretty well with kind of, like, what makes you good at getting that whole context of the way that the system works into your head at once. Like, you have to be a little bit of a weirdo to be able to kind of absorb that up into your brain all at once.
Dan: Mm-hmm.
Taylor: Um, and so I think that that probably aligns a little bit with people who are a little bit pedantic and that care about the difference between this way of doing something and this other way of doing something. And I think, like, that sort of co-aligns with potentially being, um, a little irritable. The other part that I think feeds into the irritability is there's kind of a weird thing which is that all of the business rules of the way that a company's software works, anybody who works at the company knows a part of them. But the software engineer who's adding the new feature has to know about every single one pretty much when they're in the code. So when you say, like, "Oh, let's just change that button from red to blue. You know, why, why not? That'd be so much more fun. Blue is more aligned with our brand. Like, that's a much better color. I think it's a warmer color for..."
Dan: And it's so simple. I mean, it's just a button. Uh, who cares?
Taylor: It's just a color, you know? And then the software engineer goes in there and says like, "Well, you didn't think about dark mode, and you didn't think about, you know, in Arabic, it's RTL. So it's actually, it's on the wrong side. It's not going to be next to the other thing that's blue." Uh, whatever.
Dan: That's a great example.
Taylor: You know, then you dive in and say, like, "Actually, you know, a paid user, it's got this badge on it, and you didn't come up with the case of, like, what happens when it's got the badge on it." And so, like, you're taking everything that the business can do and then you're, you're encoding it in all these files, in these workflows, and then you're like, you know, just, "Why is it so hard to change that?" It's like, well, you didn't... You know, there's so much there.
Dan: And it seems like it requires so much concentration, which I assume is why working in the dark often alone fueled by Monster Energy. Like, in my brief and, and unsuccessful time learning to code in college, like, I just remember these maddening wormholes where something wasn't working and you're trying to debug the code. And then, like, three hours later, you figure out, like, you're missing one closed parenthesis or something.
Taylor: Totally.
Dan: And that was both the beauty and the terror of the job is that you knew it was solvable, but that didn't mean it was gonna be an easy process.
Taylor: Yes, I, I do think that, you know, there's certain characteristics of, you know, is it, is it like an ornery person who kind of enjoys, like, you know, I gotta figure out all these weird cases and then convey them to somebody and then kind of be a little bit pissed when they d- you know, they don't understand the complexity. Uh, so I think that that, that resonates. I think the thing that's the biggest difference, and this is also, like, the Hollywood archetype of like a hacker, like, hacking into the mainframe and they're, like, they're doing it on a laptop in front of you and there's like 10 people around them. And like, then there's an, like, the Russian guy is also hacking from the other side and, like, it's a race. Or like the solo genius off in the corner, like, creating the best algorithm that the world's ever seen. That's crazy. Like, maybe that happens. Maybe, maybe there's somebody who, who does that. But most of our work is, like, it requires so much concentration that you really can't be under the gun. You really have to get time and space mentally to, like, figure out the plan, but it kind of can't be on the spot.
Dan: Hey, folks. Dan here. We are currently looking for someone in the food world, maybe a head chef, a restaurant owner, a food scientist. As always, we're looking for people who love their work. They've been doing it a long time. And of course, they've got to be good talkers, storytellers. Do you know someone like that? Send them to us. Have them leave us a voicemail. That number is always, always in the show notes. And I'll also share it right now for those of you with perfect memory for numbers, 919-213-0456. Thanks, folks. And now back to the show.
I asked Taylor how you can prove that you're good at software engineering and how you can spot those talents when you're hiring.
Taylor: Well, it depends a lot on the... in the environment you're in and, like, the actual interview process to try to understand if someone is good and you should hire them is very hard. And I, I don't trust my own interview skills at all because it's just so hard to actually tell.
Dan: Why?
Taylor: You, you have a whole set of interpersonal skills which are important. So like, you know, can you talk on a podcast about software engineering or something? Um, and that has almost nothing to do... but it has a little bit of something to do with being able to be functional on a software team. So like, if you are good interpersonally, you can be easy to, you know, discuss bugs with and sort of bounce ideas off of, and that can be very helpful for a team, but also it's not required for sort of, like, shipping a bug fix to production very quickly and being very detail-oriented in doing that. So it's easy to sort of over pivot on, on the wrong attributes.
Dan: Shipping to production, by the way, just means taking the code changes you've been working on and pushing them into the real world, like onto the actual apps that people are using on their phones and computers, and that can be dangerous. Taylor says even code changes from good software engineers sometimes cause crashes.
Taylor: One way to tell that I think someone's a great software engineer is like, first of all, just like, "What have you done? Okay, you've been working for ten years. Tell me the ten amazing things that you've built." Which isn't sort of like the cleverest solution to this problem or whatever, it's just like, you know, you're constantly putting things out there. And the other side of that is like, okay, like, how many times have you taken down production and how did you respond to that? Um, because if you're not taking down production, you know, it's... You don't wanna do it all the time, you don't wanna be the bull in a China shop, but at the same time, like, you're always breaking stuff just because it's impossible to sort of, like, know ahead of time all of the possibilities of what the code might do.
Dan: So it's almost like bad news if someone hasn't broken things because it means they weren't working on anything of substance. Is that what you're saying?
Taylor: Yeah. I mean, I think you're not pushing enough code to production if you're not also, uh, you know, occasionally breaking production. The ideal state also as you sort of, like, get more used to deploying changes is, how can you minimize when your code does go bad? So, the real sign for me of working with someone who is awesome is like, they figured out the screen was melting before anybody told them, and they already turned it off, and they already have a fix in review. You know, the proactive, like, self-aware monitoring of sort of like the state of the world and then, uh, driving to fix it.
Dan: So, one thing I wanted to ask you about is, you know, in organizations there are natural tensions between certain roles. Like, you know, classic one is marketing and sales and, you know, the marketing people are like, "The salespeople just aren't selling the product. It's brilliant." And the salespeople are like, "Uh, b- you know, the marketing people built the wrong product," or, "It's the wrong framing and you need to work on price and you need..." blah, blah, blah. Where are the natural tensions with software engineers? Like, if you're fighting with someone, who is it likely to be?
Taylor: So in a software development team, typically you have a product manager at the center. They're the person who is kind of talking to the CEO and anybody in between them, coming up with what should the product do next. Like, what's the big feature? So for example, at Facebook when I'm doing that stupid, like, giant Like button experiment, it's like, "Oh, we wanna make UI buttons, like, 50% bigger across the website because that's gonna drive engagement," whatever. So the PM's coming with sort of like the strategy. The PM then usually works with the designer, and so there's a, a design team. Maybe they have their own structure of how they do design reviews, but they say, "Okay, cool. The Like button looks like this right now. Guess what? Five times bigger." So they come back with, like, the pixels drawn out to actually show you what that's gonna look like. They do a review with the CEO. The CEO's like, "Oh, my God, I can't wait for this huge Like button," and then it goes to an engineer. Uh, the engineer may or may not be in the room for that conversation also, but in old school work, maybe they're not involved at all. They just receive sort of like the file that says here's how big the button's gonna be. So the tension is usually between engineering and product because the product people want, want the button to be 50 times bigger and then the engineer says, "Look, we can't make it 50 times bigger. We can only make it two times bigger because there's this comment button and then there's oth- uh, you know, in Arabic actually, then this way it flows, it doesn't go this way." So there's always a sort of like back and forth about the scope that you're gonna take on between product and engineering.
Dan: But the challenges of software engineering go well beyond organizational tensions. Sometimes the enemy is the code itself, and the consequences of a screw-up can be huge. Earlier in his career, Taylor worked at a startup that developed tools that could be used by other app developers. So, let's say you were building your own app and you wanted to include one of those pop-up windows like, "Are you enjoying our app? Please rate it, blah, blah, blah." And then rather than build that feature yourself, you could just rely on Taylor's tools and snap it right in. So anyway, during this era, Taylor went home for Christmas one year and all seemed quiet, at least at first.
Taylor: Part of my life as a person who builds things on the internet is that I'm constantly being notified when my things are broken. So, I actually chaperoned a field trip the other day for my son and like, as I stepped into the school, I got a page, uh, that said my site was down. So this happens-
Dan: Ugh.
Taylor: ... all the time. I'm constantly waiting for the notification sound that I've been paged. So this service that was powering these pieces of UI in people's apps, I got paged on Christmas Eve. So I'm sitting around at my parents' house. It's a party with, you know, 50 people. It's all people I haven't seen in a million years 'cause I lived in San Francisco and I'm flying back to Chicago and catching up with everybody and, and my phone keeps dinging. So I open it up and I look at the graphs and, and basically you can see really plainly that we're basically getting, you know, five times as much traffic as we've ever gotten before, right now on Christmas Eve. But the site was kind of healthy. It was pushing through. So I was like, "Okay, you know, I'll have another, uh, Christmas cocktail and check in later." And it wasn't until the morning that I got, like, the real scary ping, which is like the site is completely unresponsive. We've got ten support emails already about the apps are down, nothing is working, you know, oh .
Dan: So Taylor starts trying to figure out what was spiking the traffic-
Taylor: Computer programs always have logs. So I open up the production logs to see what service is talking to me, and it's like not something that I recognize, it's something like roughly having to do with a race car or something, I'm not totally sure, and I keep looking and all I wanna do is get the service back up because we have tens of customers who are already pissed at me on Christmas morning and I also wanna go, like, open presents with my nephew.
Dan: Right.
Taylor: Um, and I've got a headache. It's like a situation. So I figure out who the app is that's basically destroying the servers, and I just decide to turn it off. So I shipped a little change to our production environment that just said, "Okay, if it's this app, respond with kind of, you know, just an empty thing." Um, and the goal was just like, "Let's have the site back up. Let's not deal with this until, you know, New Years or whatever." So I do that, I go back to the Christmas festivities and I just start getting a couple other pings. So I look at my phone, you know, there's an email, you know, kind of ignore it, and it isn't until I get, like, the third one that's from the same guy, but now this time it's on LinkedIn and he's like, "Hey, my app is crashing right now. Every time you open my app, it's crashing, and I think it's because of your software." So I rush back to the computer and I'm like, "Oh my god," and it turns out that he had built this companion app for a toy, a race car app toy, and so kids were getting this race car-
Dan: From Santa.
Taylor: ... and they're, from Santa or whatever on, you know, it starts on Christmas Eve 'cause some people get some early presents or whatever, then on Christmas morning it's this deluge because everybody's opening their things, and the first thing you have to do is you have to install an iPhone app to control it.
Dan: Oh. Oh, no.
Taylor: So, so you open the thing, it's like, "Oh my god, this is gonna be so sweet, can't wait to play with it. It's gonna be so fun. It's gonna be so fun when you, when you connect the Bluetooth with the app so that you can actually use the toy. That's gonna be sweet." So then you download the stupid app obviously, and then you have to, like, link up your sign in or whatever, and then it just crashes. And so the children, you know, around the world are just, like, having this awful time with this, and it's, this goes on for, like, I was barely paying attention 'cause I was trying to, you know, play with my nephew and stuff while the bad fix was out there.
Dan: It turns out, as is often the case with software, there was a compatibility issue. The app developer had installed an old version of Taylor Software, and when Taylor rolled out his quick fix, the old software didn't know what to do with it and completely crashed.
Taylor: So this is actually, like, the most embarrassing part of probab- like, anything that I've shipped I think, 'cause it's just, like, so viscerally terrible, and it was, like, such a throwaway fix that I did to also cause the really bad part, 'cause it wasn't actually crashing until I did that bad thing when I basically tried to get our servers to shed some load, uh, and just shipped that sort of, like, crappy fix. That was what actually caused the crash. So the whole app was crashing for the entire world for, like, two hours, and, um, if you look up the Amazon reviews for the race car product, I did this a couple years ago, you can actually still find the, the vitriolic, you know, "You ruined Christmas. This is the worst product I've ever bought." And it's, yeah, that's, like, obviously the software engineer who, who installed their SDK at whatever the company is, is... hopefully they aren't listening so they don't know it was me.
Dan: So, Taylor, we always end our episodes with a quick lightning round of questions. Here we go. What is a word or phrase that only someone from your profession would be likely to know, and what does it mean?
Taylor: Okay, I think a good one is tech debt.
Dan: Tech debt.
Taylor: Have you heard of tech debt?
Dan: I've heard the term, but I'm not sure I could define it.
Taylor: Okay, so it means that you wanna get this feature out, and if I wanna support all of the languages in the world, like, it's gonna take four months, but if I wanna get the feature shipped tomorrow, I have to cut corners and kind of, like, do the changes in a hacky way and maybe not test all these cases and, you know, maybe the app crashes in, in Hindi or whatever. Uh, so tech debt is kind of like when you keep working like that, you build up, you know, a bunch of broken stuff along the edges, and you need to, you know, eventually pay down the tech debt by just focusing on quality. So, like, let's actually, like, okay, we're not gonna do any new like buttons. Let's go back, make sure that the app works great in Hindi and sort of, like, resolve the tech debt.
Dan: And so does the tech debt eventually get paid off, or do you always just have a mounting pile of tech debt that never goes away?
Taylor: Uh, depends if you ask the PM. They're never gonna wanna pay down the tech debt. Just kidding. But the, uh, yeah, like the- ... the antisocial engineer is gonna wanna pay that down and fix it up because they want it to be nice and tidy and the product people are gonna wanna ship the next, you know, thing that increases revenue or whatever, um, and so it's always a tension of, "Can we go back? Can we have a quality day? Can we do a quality week?" In the big companies you try to sort of, like, build in some incentives for that, but yeah, it's a whole thing.
Dan: What's the most insulting thing you could say about a software engineer's work?
Taylor: You write spaghetti code.
Dan: Oh, what does that mean?
Taylor: Uh, that means your code is not well organized, I cannot understand it, it doesn't connect in logical ways. If you looked at, like, a nice beautiful code base, it would be arranged in sort of a, uh, like a nice flowchart. So I'm over here in News Feed, and newsfeed needs to talk to the recommendations engine and the ads engine and you have these nice clean arrows. When it's spaghetti code, it's just a mess of s*** that's all talking to each other and calling each o- you know, from crazy places and you can't really reason about where to make the change because it's just all over the place.
Dan: What's a tool specific to your profession that you really like using?
Taylor: Uh, the one right now, a- and it's, like, a little basic actually for being in the AI world, but Copilot, which is basically AI auto-complete. So you type, you know, class foo and then you wait, just wait a second, and Copilot sort of, like, understands what you wanna do and then gives you a first pass of, like, what that class might look like, and it's basically amazing. When I'm, when I'm on, like, an airplane and stuff I can barely work now 'cause it's, I don't wanna type all this stuff. I want, I want this thing to be able to figure out what I want it to do and then write it for me.
Dan: What phrase or sentence strikes fear in the heart of a software engineer?
Taylor: This site has been hacked.
Dan: Ooh. Have you seen that before?
Taylor: Uh, I have seen many sort of like bugs that you could potentially, you know, interpret as some kind of a little, little bit of a hack. But I've seen one case when I was working on... I was helping support one of my friends who had a, uh, had a crypto website and there was a longstanding bug in the code that was years old, but somebody figured out how to turn it into a full-scale hack and basically stole a ton of money from this person's users by basically taking over the screen and sort of like making it look like something else.
Dan: And there's a real profit motive there, I mean, if you can break into the crypto sites.
Taylor: Yes. And then it was... The money was instantly gone and we traced it to, you know, Turkey. It was like, it was instantly gone and not recoverable.
Dan: What is an aspect of your work that you consistently savor?
Taylor: I love to reproduce a weird bug, a bug report from a user. So it's like, uh, we had a user who wrote in that all of a sudden our software was not generating nice pictures of birds anymore.
Dan: So just to break in here, remember Taylor's current startup is one that takes prompts from customers, like show me a pileated woodpecker pecking on a tree, and the AI will spit out a polished looking video. So Taylor says their first reaction was that this bug report couldn't possibly be right. But then...
Taylor: We went one step deeper. We like, you know, asked the person for more information and she's like, "Oh, well actually, you know, if you do a pileated woodpecker or like a, you know, a female robin, like it might get that right, but it really won't get, you know, uh, a coastal warbler or like a crested whatever. You know, it... Tho- those are just off the map." And I'm like, "Wow, she really knows a lot about this." So then, you know, you take that and you try to put the inputs in the right spot to figure out if the system's really messing something up. And the bird one, it was actually very easy to repro and it's extremely pleasing to be like, holy crap, like our system's actually really bad at birds. So sort of like connecting the dots of how the software's broken and then creating a path to fixing it is, is very fun.
Dan: Because what, what does it represent for you? It's like all the sudden something that seemed kind of random and noisy is actually diagnostic of something systemic that you understand. Is that the idea?
Taylor: Yeah, it's, it's like a puzzle.
Dan: Hmm.
Taylor: So, like, every day at 5:00 PM, we get one person who emails us and says, "You know, the button's doing this. What's the deal?" And then you figure out, oh, there's actually this job that runs every day in the background and it temporarily puts pressure on the database. And thus, this other query that normally works totally great is failing and timing out for this user who happens to be in Istanbul. And you’re, like, "Isn't that cool?"
Dan: This is my very last question, I promise. This is from a listener. Uh, this is sort of a weird meta question. What question do you wish people would ask when they first hear what you do for a living?
Taylor: I think the problem is that most people don't know where to start. Like I recently moved to the Midwest from San Francisco. In San Francisco, when you meet a random person, the likelihood that they're a data engineer at whatever company is like very high, so they will know exactly what you're talking about most of the time. Here, I think people don't know what that even means. So I say like, "Oh, I have a software startup. We're building, uh, you know, an app where people can build videos and they can type in, you know, like spooky story at night and out comes a video." I think like people are like, "What?"
Dan: That seems very clear to me. I mean, you didn't use a lot of jargon in that pitch. I don't know.
Taylor: I know, but I think like the job of building it is like so weird. It's like a... I think most people, when you think of consumer software, um, I also have an, uh, photo sharing app, and I think when people see that app, they think like, well, there must be a company about it and there's probably a couple dozen people who work on it or whatever, and I'm not gonna get one of those people when I send an email to this email address certainly. And it turns out it's like just me and my co-founder getting an angry email from somebody and they didn't realize that it's like, well, there's three of us right now. And like yeah, of course I care about your bird problem.
Dan: That, that is so wild that you're like the founder and you know, world-class engineer and like tech support.
Taylor: Yeah. We're right in the weeds, but that's how you find out when everything's on fire and that you need to fix your bird model.
Dan: Taylor Hughes is a software engineer. Right now he's the co-founder and CTO at the startup Hypernatural AI. You can check it out at hypernatural.ai.
I keep thinking about the idea of tech debt, the choice you make to put off certain foundational work for the sake of short-term benefit. Taylor highlighted the natural tension that exists between product managers who want to get the new feature out there right now and software engineers who want to slow down and perfect the current system.
And obviously it's not like one side is right and the other is wrong. You've got to have a balance and that balance might well vary by what you're doing. So if you're creating video games, then holding out for code perfection is probably not a good choice, but if you're building airplanes or heart valves, we'd really like to see those perfectionists in charge.
The same tension pops up in so many different places. Film directors want that perfect lighting and the perfect scene, and producers want the movie done on time and on schedule. Or think about architects and builders. The architect wants that elegant curve in the wall, but the builder says it'll take three extra months and cost five times as much.
I don't want to exaggerate the distinction here. I mean, after all, Taylor has to operate on both sides of the line, as we heard. He has to hammer out that good enough code for today while also tracking the imperfections for a future improvement tomorrow.
Tracing mysterious errors to their source, jousting with product managers, wrestling with thickets of interconnected code, and rolling out new features without breaking the old ones. Folks, that's what it's like to be a software engineer.
A shout out to recent Apple podcast reviewers, TimTaylor379, ABCD157, and Dexistential. This episode was produced by Matt Purdy. I'm Dan Heath. See you next time.
