Under the Radar

69: Features You Don't Want


00:00:00   Welcome to Under the Radar, a show about independent iOS app development. I'm Mark Orment.

00:00:04   And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.

00:00:09   So today we wanted to discuss what I'm kind of coining as speculative development or speculative

00:00:17   design. And this is coming out of an experience I had this week when I was doing some work

00:00:22   on my audiobooks app, where I was doing and had been kind of struggling through a lot

00:00:29   of the updates that I'm doing. I'm kind of doing this big sweeping overhaul of the app.

00:00:33   And specifically I was struggling with some of the changes that I was, like the changes

00:00:37   I was making was causing me to make a bunch of updates into the iPad version of the app.

00:00:43   And at a certain point I had this realization that I've never used the iPad app for this

00:00:49   app, ever. I've used the iPhone app fairly extensively in most of my testing. It's something

00:00:54   that I use on a semi-regular basis. But just for me and the way that I use the app, the

00:00:59   iPad version had never been used. And it had kind of this realization as a result that

00:01:06   I was kind of building this thing in a way that I really had no idea how it would best

00:01:10   be used. And in this particular case I decided what I really should do is I was just going

00:01:16   to make the iPad version of the app be essentially a blown up version of the iPhone app. That

00:01:23   is, which is awkward and tricky and I think it makes it a good topic to talk through today

00:01:28   because on the one hand I am ending up with an app that is structured and works in a way

00:01:35   that I know works really well on the iPhone. And the code for that is much simpler now.

00:01:40   There's not all of these, like if iPhone do this, if iPad do that. The app is more reliable

00:01:46   probably as a result. But it isn't as optimized for these particular users and these particular

00:01:51   use cases. But in some ways it's probably, when I was guessing people who used iPads

00:02:00   would like, it may not actually even be what they would like. And so you have this strange

00:02:04   tension between speculative like making up these features and making up a layout and

00:02:09   guessing a design for something that I don't actually have a strong opinion on when it's

00:02:15   like in theory that might be better, but in practice maybe it's worse. And I don't actually

00:02:20   know which one of those is better in this particular case, but I know that I am enjoying

00:02:25   working on the app a whole lot more now that I have just given up on the concept of trying

00:02:31   to make this mythical iPad version that I'm kind of projecting would be great for somebody.

00:02:37   And instead just saying, "You know what? I know how to make a really good iPhone version

00:02:41   and if you make that bigger it may not be as ideal, but it will work well enough." And

00:02:47   I'm not speculating. I know what works. I know how to structure things. I know how the

00:02:52   layout and the flow should work. And ultimately that's probably better, but it is a weird

00:02:58   tension and something that I think is awkward, especially when you are the developer and

00:03:04   designer of an application that you have to kind of, at a certain point you're always

00:03:10   probably doing a little bit of projection, a little bit of speculative development about

00:03:14   there are features in the app that you may not necessarily use yourself, but that some

00:03:21   of your users do use. But I think it's a really interesting area to be cautious of because

00:03:29   the more we do that, and there's a whole bunch of other areas that I'll probably get into

00:03:33   later in the show where we kind of have to do the speculative development, but every

00:03:38   time I think I'm starting to, as I look back on my development for the last few months,

00:03:42   I'm starting to see areas where I've been doing this kind of speculative development,

00:03:47   and in a lot of cases I end up regretting the work that I do because it's just guessing,

00:03:53   and it's never going to be my best work because it doesn't have the thoughtfulness that it

00:03:57   could have otherwise.

00:03:58   Yeah, I mean, I've faced this problem a lot with user feature requests. This goes a lot

00:04:05   into it. In the case of bigger things like your iPad app, your iPad version of audio

00:04:12   books, I would imagine you have the data to show that not a lot of people use it on iPads,

00:04:18   right?

00:04:19   It's certainly a minority. I think the number's about 18 percent or something like that of

00:04:23   users use the iPad.

00:04:25   That's actually higher than I would have guessed. I believe that's higher than Overcast,

00:04:28   but I think analytics here help, and again, you don't need massive detailed analytics.

00:04:35   You can just do a simple thing like what you do, just like reporting back to a server,

00:04:38   like am I running on an iPad or an iPad, what OS version, stuff like that. You can learn

00:04:41   a lot just from that.

00:04:45   If a very tiny portion of your customer base is using something or something that you expect

00:04:50   only a tiny customer base to use if you haven't released it yet, that makes it a pretty easy

00:04:54   decision to be like, "You know what? If I don't really want it and not a lot of people

00:04:59   would use it, and it's at all any work to do or maintain, then it's a pretty easy decision

00:05:07   to say, 'You know what? No thanks. That's probably not worth doing.'"

00:05:11   The tricky part is when one of those things isn't true. For instance, if something's making

00:05:17   it easier, like if not a lot of people would use it and it's a lot of work, then don't

00:05:21   do it. But if it would make some people really happy and it's almost no work and it's not

00:05:28   going to have much of an ongoing maintenance cost, that's a trickier question.

00:05:32   In Overcast I have my alert icon badge number toggle where you can have the app display

00:05:41   its red icon badge with the number of unplayed episodes you have. This is something that

00:05:45   I really don't like. I don't even think anybody should ask for this. But after 1.0 was launched,

00:05:51   it was one of the top requested features because the people who do want it really, really want

00:05:57   it.

00:06:01   I was already tracking which episodes are, or how many episodes are unplayed in other

00:06:06   parts of the API. To show that red number badge above the app icon is like two lines

00:06:12   of code. I figured, "You know what? I can put this checkbox in my nitpicky details screen

00:06:17   with a funny caption and I can have this satisfy the people who really, really want it."

00:06:24   Ongoing, it's really not that much work. It's those two lines of code. There's almost no

00:06:30   complexity to it. It doesn't really interfere with anything else about the app. I don't

00:06:33   really ever need to change it unless I change the definition of what an unplayed episode

00:06:37   is, which could happen, but it's unlikely.

00:06:41   So overall, that's a pretty easy thing to say, "You know what? People do want this even

00:06:46   though I don't and there's enough of them that it matters. I'll give it to them. It's

00:06:52   not that much work."

00:06:53   But then I have another example of a toggle in Overcast called Play Next by Priority. This

00:07:00   has caused me lots of headaches in 3.0, most of which are still not resolved. This is a

00:07:08   preference where basically Overcast playlists have a notion of priority podcasts. You can

00:07:13   set certain podcasts to be ranked higher than others when new episodes come in.

00:07:18   The question is, if you're playing something from the middle of a list and the episode

00:07:24   ends, what should play next? In my concept of Overcast playlists, no matter what your

00:07:29   priorities are, whatever's listed next in the playlist should play next. I released

00:07:35   one point out of this way and I didn't even consider any other possibilities. To me, that's

00:07:39   obviously how it should work.

00:07:41   But I got tons of confused people and people who requested this enhancement. A lot of people

00:07:48   expected that even if you're playing something in the middle of the list, when it ends, the

00:07:53   highest priority unplayed item in the list should play, which means usually the top item

00:07:58   in the list should play. Although you can reorder my list, which makes it more complicated.

00:08:02   But it is generally, and I did a Twitter poll a while, like years ago, like a year ago when

00:08:08   I implemented this feature, and basically people couldn't agree on what the right behavior

00:08:13   was and there were tons of people on both sides. Some people said, "Yeah, just play

00:08:16   the next thing in the list, logically." And just as many people said, "The highest priority

00:08:21   thing should play next."

00:08:23   So I had to add this option and what this does is make anything complicated that depends

00:08:31   on trying to figure out what plays next. Because I have a basic function that tells you that

00:08:37   off of the object, but it became a problem when I added two features in 3.0. The widget,

00:08:44   which shows the next two next items and the play next feature that moves things around

00:08:52   playlist on demand in order to play things next. This completely breaks with the play

00:08:59   next by priority setting on. Because the widget checks and it says, "Alright, what item comes

00:09:06   after this one?" And then it fetches that and then it says, "What item comes after this

00:09:09   one?" And I need to now modify the API because the second item, the next next item, might

00:09:20   be the current item.

00:09:25   And people keep sending me, I have a couple of Twitter screenshots of like, so now it's

00:09:30   like, "Oh, I'm showing ATP and then next is showing this, but then after that it's showing

00:09:33   ATP again." Because it's like looping around because of the certain order of items. The

00:09:37   other thing is, if you're in a prioritized playlist and you go down and pick something

00:09:44   and you say play next, do I change the priorities of the playlist to make that work? Like, no,

00:09:52   that would be terrible, right? But then do I temporarily suspend play by priority? It

00:09:59   messes up everything. And so ultimately I think what I'm going to have to do is, I can

00:10:07   handle the widget, I can just make the API more complicated so it keeps track of like,

00:10:12   well if these two were already played, what's next? Which is annoying, but I can do that

00:10:17   fairly easily. But the play next functionality actually kind of doesn't make sense with play

00:10:25   next priority enabled. It kind of breaks in a lot of ways in a lot of conditions that

00:10:30   people might be using. So my inclination is just to disable play next completely if you

00:10:35   use that setting. Which most people don't, but the few passionate people do. Because

00:10:40   I can't think of a way to make that make sense. So it's like, all this complexity that I now

00:10:46   have to deal with because a year ago or whatever, I added this play next priority option because

00:10:51   I thought it wouldn't be that much work. I thought, oh, this is just really changing one

00:10:56   function. The function that says what comes next after this item. And I thought that would

00:10:59   be a really easy change that wouldn't affect a lot of things going forward and that would

00:11:03   be easy to support, but it turns out it really wasn't over time. So now I'm questioning whether

00:11:08   I should ever have added that option in the first place and it's causing lots of problems

00:11:11   because I did. So this kind of like, oh well, you know, it'll be easy. That often seems

00:11:19   true at first, but then down the road you see it wasn't easy to support this thing that

00:11:24   you thought was no big deal. Which brings you back to the original question of whether

00:11:28   you should have added it in the first place.

00:11:30   - Yeah, and I think too, it gets to this, it's this awkward balance you find too when

00:11:37   you add something. If you add a feature, taking it away is more--

00:11:43   - Unpopular.

00:11:44   - It's very unpopular, exactly. It is something that you will have a stronger reaction to,

00:11:50   I think, than never having implemented it in the first place. Because if that was an

00:11:54   important feature for somebody, if that was a vital thing that they were passionate about,

00:11:58   they absolutely need this feature and you don't have it, they'll just go somewhere else.

00:12:04   But if you give them a feature and it's this kind of this feature that's on the edge, it's

00:12:10   not an essential feature. It's not a core to your vision for the app. It's something

00:12:14   that you're adding because you think you should. And there might be some good reasons for that,

00:12:20   but in general, you're doing it because you think you should, not because you really want

00:12:23   to. At a certain point, you may have to take it away or scale it back or do things that

00:12:33   will ultimately be problematic for the application. And I think the examples you're giving are

00:12:37   very feature-driven, but at the same thing, I've been thinking a lot recently too about

00:12:42   what do you do with some of these iOS apps are getting so complicated in terms of the

00:12:47   number of possible extension points that we can add to them.

00:12:52   For example, iMessage apps is one that I've been thinking about recently where I have

00:12:58   never used an iMessage app personally other than to test the iMessage apps that I shipped

00:13:05   on day one of iOS 10. I've never used one in actual practice. I use iMessage all the

00:13:11   time. I use it to constantly text and interact with people, but I've never used an iMessage

00:13:18   app. And so I think about these apps that I added that I've never used them, and in

00:13:24   some ways, are other people using them? If they are, am I really serving their needs

00:13:29   or benefiting them? And at some point, part of me kind of almost wants to back them out

00:13:36   of the app, but doing that would be really awkward. Or similarly, you could have a similar

00:13:42   problem with things like supporting another platform, like the Apple Watch or the Apple

00:13:46   TV. I added a couple of my apps several years ago now where I added an Apple Watch app that

00:13:55   it turns out, for example, I added an Apple Watch app for my feed reading app, Feed Wrangler.

00:14:03   I don't think people use it very much, but it allowed you to read a plain text version

00:14:12   of each of your RSS items or something like that. I didn't know how people were going

00:14:17   to use Apple Watches. Maybe that would be kind of cool, but in actual practice, using

00:14:21   an Apple Watch, the last thing you really want to do is sit there with the crown scrolling

00:14:26   through a few thousand words of text. In retrospect, it doesn't make sense, but it's also kind

00:14:33   of this awkward position I find myself in now. That doesn't make sense. I had this

00:14:37   feature that I invented in this speculative way that I kind of want to take away, but

00:14:44   if there's a couple of people who are using it and find it really cool, that feels harsh.

00:14:49   So I think it is a good reminder for me to, in general, I need to be a bit more circumspect

00:14:56   with this. I need to think about these kind of features that if it isn't something that

00:15:01   I use myself, the best software I've ever written is the software that I use myself

00:15:08   on a daily basis. It comes from a place of actual need that I have, and then I'm solving

00:15:16   that need, and then I'm discovering that other customers also have that need. The degree

00:15:21   to which I can focus my development on those paths, on those behaviors, and on those features,

00:15:28   the quality of that software and that experience goes up. The degree to which I move away from

00:15:33   that and my apps start to become a bit speculative, and I'm just throwing things in and saying,

00:15:40   "Hey, what might work? What if someone did this? What if someone wanted to do that?"

00:15:45   And the more I do that, I think the worse my software becomes, probably, and the worse,

00:15:49   the more I regret it in the future when now I have to maintain all these features because

00:15:53   I feel bad about pulling them out.

00:15:55   Yeah, and I'll tell you one thing from experience recently. In Overcast 3, I also rewrote the

00:16:01   whole watch app to go from WatchKit 1, literally, to WatchOS 3, and in the process, I removed

00:16:07   a lot of features that nobody used. And I had analytics on that to see only something

00:16:12   like, I forget what the percentage, it was like a handful of percent points of people

00:16:16   use the watch app at all, and among those, it was like a handful of percentage points

00:16:22   of those used anything that was in the force touch menu. I had a few things in there. And

00:16:27   so I took it out because in the new version, I'm like, "You know, I'm rebooting the whole

00:16:30   thing from scratch. Do I really need to rebuild the screen that 3% of 3% of the users use?

00:16:37   Probably not, but that handful of users who use it, I've heard from all of them in the

00:16:42   meantime. They are very, very upset, and it does. It's like, I feel bad now. I feel like

00:16:48   I should add that back in, but that'll make the app a little bit bulkier and take more

00:16:53   time away from anything else. It's always tricky. Never add any features.

00:16:57   We are brought to you this week by Linode. Go to linode.com/radar. To learn more, sign

00:17:03   up and take advantage of a $20 promotional credit or use promo code radar2017 at checkout.

00:17:10   Linode gives you fast, powerful web hosting. You can set it up in just seconds, and they've

00:17:15   easy to understand tools to let you choose your resources and Linux distro, giving you

00:17:19   the power and flexibility that you need. Linode plans now start at just $5 a month for a Linux

00:17:25   server with one gig of RAM in the Linode cloud. That's an amazing price. Linode servers offer

00:17:30   industry-leading performance with native SSD storage, Intel E5 processors, and access to

00:17:36   a 40 gigabit network. I'll tell you what. These just sound like numbers. I've used a

00:17:41   lot of web hosts. One of the many reasons that Linode is my favorite web host is that

00:17:46   their networking is incredibly fast. The access that you have, especially inbound access,

00:17:52   it is incredible. My crawl servers that have a lot of inbound traffic and everything, it's

00:17:58   just crazy. Of course, outbound, they have tons of bandwidth there too. But inbound,

00:18:02   I believe you have higher limits. It's just as quickly as your server can accept data,

00:18:08   you can get it. It's amazing. They have an API. You can set up things quickly. You can

00:18:12   develop custom applications or automation, super simple scaling. You can scale things

00:18:16   in just a couple of clicks. I've done that a lot of times. It's wonderful. All Linode's

00:18:20   pricing tiers also feature hourly billing with a monthly cap on all plans so you know

00:18:24   what is the most you will spend in a month, and lots of other add-on services like backups,

00:18:28   node balancers. Linode's a great service. I highly suggest you check them out. I've

00:18:32   been running my stuff there for years now. I've been slowly moving everything that was

00:18:36   not on Linode onto Linode, and it's just wonderful. Highly recommended. Go to linode.com/radar.

00:18:44   To learn more, sign up and take advantage of a $20 credit or use the promo code radar2017

00:18:50   at checkout. Thank you very much to Linode for supporting this show.

00:18:54   So I think we've probably fairly effectively talked about some of the reasons why you probably

00:18:58   shouldn't add these kind of speculative features, these kind of things that are beyond the core

00:19:04   central vision you have for the app. But I think there are probably, it's worth doing

00:19:09   a little bit of the devil's advocate on the other side for some of the reasons why you

00:19:13   maybe might want to. And when I was thinking about this this morning, the main things that

00:19:19   came to mind for me is that, A, you expand the potential market for your application

00:19:27   to be larger than people who are just like you in terms of your preferences or the way

00:19:32   you think about this particular application or the way that you approach this particular

00:19:37   problem. And that's certainly better. Obviously it's great if the way that your vision for

00:19:41   the application is the same as it is for lots of people. That's great, but you can potentially

00:19:47   expand your market. If someone in your example of the "I like to be stressed" badge on my

00:19:55   overcast, if that was an essential feature and that was a thing that was keeping somebody

00:20:00   from using the app, and just adding it, like you said, isn't a huge thing, maybe it's worth

00:20:07   expanding that market that little bit. And even though that's a feature you would never

00:20:10   use yourself, you get that benefit of potentially expanding the market. Another example of something

00:20:16   that comes to mind is that you potentially are opening yourself up for other marketing

00:20:22   or promotion opportunities with Apple, especially around things like adding an iMessage app,

00:20:28   adding a watch app, adding an Apple TV app, adding an iPad app. The degree to which you

00:20:32   kind of embrace the new stuff can often have benefits, especially in that first wave of

00:20:40   things.

00:20:41   Although that's something to be a little careful of, though, because you make a watch app,

00:20:46   say, and Apple might feature you for a week, and then you're supporting a watch app for

00:20:50   the next three years.

00:20:52   Sure. And so there is definitely a balance to be struck there between over-weighting

00:21:00   the importance of that kind of marketing. But it is certainly something to keep in mind,

00:21:04   and it has a potential benefit. But I think I'm with you in that. Once I finished talking

00:21:08   about the benefits, I was going to talk about some of the costs. And I think one of the

00:21:11   biggest costs is overvaluing the potential upside, where because there is a definite

00:21:22   upside, it's easy to be like, "Oh, I should definitely do it. Doing this will make the

00:21:26   app better." Or maybe, "I will get this attention." Even if you know for sure that you're going

00:21:31   to be featured in the App Store, you have some great confidence, or you've been in contact

00:21:37   with someone at Apple, or whatever it is. Even if you're absolutely certain, the awkward

00:21:41   thing that you might run into is, like you said, you get featured for a week, but then

00:21:47   you support it for years. And that's a tricky balance.

00:21:53   And then the last benefit that I could think of was just in terms of reducing your support

00:21:57   requests. By the nature of a lot of these kind of features, there are things that people

00:22:01   keep asking for. And so there is always going to be a certain weight on your support load

00:22:08   of people asking for this. And until you add it, that will be the case. But in aggregate,

00:22:16   I think as I've developed apps and had to support them for longer and longer, I think

00:22:21   this is something where I'm starting to develop a bit of an immunity or resistance to these

00:22:30   types of features. And I think in general, it's something that I'm going to be trying

00:22:34   to resist as much as I can. It is crazy with this particular app that I'm working on,

00:22:40   Audiobooks, because it's eight years old. And we talked about in our episode about dealing

00:22:43   with old code, there's all kinds of technical challenges. But there's also a lot of feature

00:22:49   load, and features that I added years ago that I'm now still having to deal with and

00:22:56   maintain. And I think there's a lesson to be found in, especially as an independent

00:23:03   developer, as a smaller developer, that I think we're typically best served when we're

00:23:09   able to focus down to the things that we really enjoy. Because guessing at solutions are never

00:23:17   going to be as good as actual solutions. Like guessing how someone might want to use this

00:23:23   feature based on the email you got, someone asking for it, is never going to be as useful

00:23:27   as the feature that you build because you love this thing, and it's what motivated you

00:23:32   to build the app in the first place. And I think, at least I find for myself, that motivation

00:23:38   is a very important thing. I'm doing this update to Audiobooks mostly because I feel

00:23:42   like I have to, because I haven't done one in about a year, and that's not good. And

00:23:47   a big part of why I think I am resistant to getting into this codebase, and why it took

00:23:52   a lot of girding my loins and "Let's do this" to do, is because the app had gotten

00:24:00   so divergent and had all these little extension points and differences between things that

00:24:06   made it more intimidating and it made it less fun. And as much as I do my job because it's

00:24:13   my job, because I'm independent, I have the flexibility to just kind of benignly let

00:24:20   things be neglected for longer and longer. There's no boss yelling at me in quite the

00:24:24   same way. And the product suffers as a result. And I think ultimately the products will be

00:24:31   better the more that I think it's fun to work on them. And so this is one area where

00:24:37   I'm starting to think, "You know what? I need to scale that back." And in this case,

00:24:40   it meant that I'm going to take the iPad version and make it very, very similar to

00:24:46   the iPhone version. And other than a few places where there's popovers rather than modal popups,

00:24:52   the apps are now identical. And I feel so much better about that. I feel so much...

00:24:57   It's like this great relief is off my shoulders because I'm not building this app that I'm

00:25:01   just guessing at. I'm just building an app that I know works really well, and is now

00:25:05   slightly worse for some of the users. But I think overall, they'll be a lot happier

00:25:10   with the fact that the app is going to be updated on a regular basis because I think

00:25:14   it's fun now. Because it's interesting, and I'm actually tackling interesting problems

00:25:18   that I've wanted to tackle for a while, but I didn't feel like I could because I had

00:25:22   all this other baggage and all this other load that I had to deal with as well.

00:25:26   - Yeah, I mean, I think as indies we have to always be conscientious of our limits,

00:25:35   as individuals or as very, very small teams. I think we have to recognize we can't do

00:25:41   everything. We won't want to do everything. So both in capacity, we don't have the bandwidth

00:25:51   to actively maintain and update and build lots of features and stuff that we don't

00:25:57   want to build or that we won't use, or that we won't be able to test necessarily. In

00:26:04   our informal testing protocols, this is why we should have unit tests, but we don't.

00:26:08   Also, if it's not something that we're going to use ever, a lot of untested bugs

00:26:13   could slip through, like in my Play Next by Priority thing where basically I don't think

00:26:19   any of my beta testers use that option. I don't use it, and so all these bugs slip

00:26:23   through into 3.0 features that I just never even considered because I don't use a feature.

00:26:28   It's kind of this edge case thing that I didn't think would interfere with anything,

00:26:31   but it does. So part of being an indie is having to step back and say, "You know what?

00:26:36   I can't do a whole kitchen sink set of features here. I just can't do that," and

00:26:41   maintain it to a decent level of quality. So you kind of have to just do what you think

00:26:47   is best for the app and what you can manage and what you can maintain over time responsibly.

00:26:53   And then secondly, part of the advantage of being an indie is as long as the business

00:26:59   is doing okay, you can choose. As you said, there's no boss. You can choose what to

00:27:05   work on. It's your app. You can choose what features it has. You're never going

00:27:10   to get everybody to use your app, so as long as you can get enough people to keep yourself

00:27:14   in business, then you can make the app you want and you don't have to listen to everybody's

00:27:20   requests. And that's something that I have been telling myself a lot recently as I deal

00:27:25   with bugs with options I never use.

00:27:27   Yeah, and honestly, it's a relief. It's a weird thing, and I think I talked to you

00:27:35   about it. I remember when I first had this realization that I was going to just drop

00:27:39   the iPad version that I had built and just switch to it being based on the iPhone layout

00:27:44   and flow. I was genuinely happy and relieved, and it felt good in a way that a lot of decisions

00:27:52   don't give you those feelings. But it was a great encouragement to me that I was excited

00:28:00   about working on this app in a way that I hadn't been before because of this choice

00:28:04   that I'd made. It's kind of fun to feel empowered to do that. I didn't have to go

00:28:12   before a committee. I didn't have to convince anybody else of doing that. I decided that

00:28:16   this would be better for me and, as a result, better for the app, and just went with it.

00:28:24   That is one of the rare gifts we get by being our own boss, and it is something that I think

00:28:31   is important to take advantage of. A lot of being independent is rough, but this is one

00:28:36   area where if you find an opportunity to do something that you think will make you enjoy

00:28:41   working on the app more and will avoid these kind of headaches where you feel like, "Why

00:28:46   am I even building this? I don't like this feature in the first place." That's a great

00:28:50   opportunity to say, "You know what? I'm not going to. I'm going to take this feature

00:28:55   out or I'm going to change this in a way that I think will make me more excited to

00:28:59   work on the app." There's nothing more soul-crushing than working on a bug that you don't even

00:29:03   want the feature to exist in the first place. Embracing it can be a really powerful thing

00:29:12   to motivate you to do better work, and any opportunity we have to do that is definitely

00:29:16   worthwhile.

00:29:17   >> WESLEY CHUNG: And with that, we're out of time. Thanks, everybody, for listening,

00:29:20   and we'll talk to you next week.

00:29:21   >> DERK WALKER-GRIEGER. Bye.