Under the Radar

108: Punch-List Mode


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

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

00:00:09   started. So today I thought it would be a fun topic for us to talk about finishing up

00:00:17   a project, or doing that last 1% that definitely doesn't take 1% of the time you spend on a

00:00:24   project. Like, the energy and the effort and the willpower it takes to just get over that

00:00:30   last little bit is definitely massively disproportionate for launching a software product. And you

00:00:37   get better at it the more you do it, which I think is something hopefully that I can

00:00:40   say that is -- I found in my own experience and is hopefully encouraging, if you're coming

00:00:45   to development fairly -- if you're fairly new to this, that it's totally normal for

00:00:52   that last little bit of a project, where it's almost done, but isn't quite done, isn't quite

00:00:57   released, to feel like it takes forever. And part of it, I think, in a weird way is the

00:01:03   term "software release" is very aptly named, because software isn't so much finished as

00:01:08   it is slowly tugged out of our hand, and eventually we just release our grip and it flies out

00:01:14   into the world. It is never this thing where -- at least I've never had the experience

00:01:19   where I feel like I have created this perfectly formed thing that I am now presenting out

00:01:26   into the world. It's like, at some point, you just have to say, "This is good enough.

00:01:30   I'm going to put this out, and I will fix all the bugs or the issues or the problems

00:01:35   later." And I think we've talked many times in episodes previous about the importance

00:01:39   of getting something out into the world, because you can get feedback, you can validate the

00:01:44   idea, make sure that you're actually building something people want, or not missing whole

00:01:49   aspects of the problem domain that you're trying to solve that you're just unaware of

00:01:54   because you're stuck in your own little world. But more importantly, I think what I was going

00:01:58   to be interested in to focus on for today is some of the little aspects of doing that,

00:02:02   of the things that you have to do in that last 1%. And the first thing that I think

00:02:08   is worth talking about is deadlines. This is especially complicated, I think, being

00:02:14   -- if you're doing this project by yourself or just one or two other people, and this

00:02:19   isn't something where you have an externally imposed deadline. It's not that you're doing

00:02:24   consulting for a client and the client has said, "By this date, you need to have done

00:02:29   this or you won't get paid or there'll be some kind of penalty." If there's an external

00:02:34   deadline, that sort of takes care of itself. But if you don't have one of those -- and

00:02:40   what I've found for myself is that if I don't have some kind of deadline in mind, and maybe

00:02:47   it's slightly squishy, but it shouldn't be so squishy that it's not a deadline. It still

00:02:51   should have some weight behind it. I find it very hard to really get there because there's

00:02:57   something -- I think it's Parkinson's Law. It's one of those management laws where it's

00:03:03   like work will expand to fill the time allotted to it, basically. So if you give yourself

00:03:09   another month, you will find a month's worth of work to fill that with. And if you give

00:03:12   yourself another two months, it'll fill indefinitely. And if you don't have a deadline, you will

00:03:16   just keep filling with work forever. It's this never-ending, inflating balloon. And

00:03:21   so you have to at some point put a line on it and say, "I'm going to get it done by here."

00:03:27   Something that I found really helpful with this is to start to try and talk to other

00:03:35   outside people about your launch. So whether this be someone in the press, with friends,

00:03:40   whoever it is, and start talking around a date. I have December 12th as the date that

00:03:45   I'm going to launch Workouts++ 2.0. That's something that I've started to socialize and

00:03:51   talk about to different people. And now that that's a thing in the world, it changes it

00:03:57   from this vague amorphous thing to something that I have this personal ownership of making

00:04:02   happen. And if I didn't have that, I feel like I would just keep working on this app

00:04:06   forever, which is not good for anybody. It's far better to draw a line, cut what I need

00:04:12   to cut, narrow it down so that I can get it out there, and then start iterating on the

00:04:17   version that's out in the world rather than just getting stuck without a deadline, without

00:04:22   any sense of end in mind.

00:04:24   - Yeah, I mean, I have found that most of my releases have basically been, I've basically

00:04:32   been working all month or year or six months or whatever, working for a very long span

00:04:39   on a kind of unending list of features that like, everything is like, oh, it would be

00:04:47   nice if I had time, I can do this. And very few of the features are actually required.

00:04:53   And so the amount of time that I'm working on these releases is pretty open-ended. And

00:04:59   without any kind of external deadline imposing on me, like the release of a new version of

00:05:03   iOS or a new Apple hardware or something like that, they would just go on forever. And usually

00:05:08   when I do finally release something, it is planned almost no time in advance, and one

00:05:15   day I just kind of, I'm like, you know what, I'm just, I'm done. I just want this to be

00:05:19   out there. I'm tired of it not being released, so I'm just going to release it like tomorrow

00:05:24   or something like that. Just a kind of arbitrary decision of, okay, I just need to get this

00:05:29   out there. Enough is enough. But a lot of times that takes me a long time to get to.

00:05:35   - Do you think that kind of slightly arbitrariness to it works in your favor, or is it problematic?

00:05:44   It seems like it could go both ways, that in some ways it's helpful because you're not

00:05:49   creating this sort of, any internal stress about something. You're just kind of working,

00:05:53   working, and at some point you're just like, you know, this is good, and just ship it.

00:05:58   Is that, do you find that to be helpful, or is that problematic?

00:06:02   - It's one of the many ways that I think and work that are probably not ideal, but that

00:06:09   also I probably will never change about myself. So I just have to basically take the good

00:06:15   and the bad that comes with it. I think that there's a lot of things that are bad about

00:06:20   this kind of capricious or rash decision making. Sometimes it's not a good time to release

00:06:25   that thing, it turns out, which I find out later. Or sometimes it would have benefited

00:06:29   from a stronger and more considered marketing push maybe. But the reality is that I also

00:06:37   then am rarely in the position where I have to wait forever. I'm rarely in the position

00:06:43   of designing myself into such a corner or having such a huge list of what needs to be

00:06:49   done before the release that it never comes out. Like, no one's ever waiting years for

00:06:55   an overcast update. The way I work ensures that something will get released on a fairly

00:07:02   regular interval, and I will never know until it's actually released what features will

00:07:07   end up making it before that deadline comes or not. The self-imposed arbitrary deadline

00:07:12   that was declared two days ago.

00:07:14   >>

00:07:34   When I start to work on anything big, the overall quality of the app drops somewhat

00:07:45   precipitously, and then it'll gradually work its way back up to good again over the

00:07:52   course of time. For me, I find it's important to have something in mind that I know how

00:07:59   much time do I have to keep breaking things before I have to switch things around to just

00:08:06   fixing things. And that might just be the way that I develop. That I tend to take everything

00:08:14   apart and then put it back together again rather than fixing things in a way that is

00:08:21   probably a bit more elegant or straightforward, where if something isn't done, it could

00:08:26   just be left out. I know you hear about this a lot with web development type of things,

00:08:34   where everything that's in your master branch is always ready for production, and nothing

00:08:39   that touches that should ever not be ready for that, which is the opposite of what I

00:08:44   do. I just have things go from great, horribly broken, back to great, back to horribly broken

00:08:51   for me. So I need some sense of endpoint that I'm aiming at in order to get things turned

00:08:59   around and fixed. Otherwise, I'd find myself in a lot of trouble if I was like, "You

00:09:03   need to release this in two days." No, I need a week to put it all back together again.

00:09:09   That might just be the way that I work.

00:09:12   Yeah, I do the exact same thing. Basically, when I decide enough is enough, I need to

00:09:21   release this, that just becomes my number one to-do item, is just let's close all

00:09:25   this back up again. Let's fix what's broken. If too much is broken and I can't do that

00:09:29   quickly then okay, I won't release it yet. But usually, the things that I break horribly

00:09:35   are the first things that I fix during a development cycle for release. And then everything after

00:09:42   that is either minor polish items, which are easy to basically knock them all out and clean

00:09:48   it up in one or two days at the end once you decide you're done, or additional features

00:09:52   that aren't really necessary or that are more self-contained so that if I have to

00:09:57   disable an entire feature for release and just ship it later, I can do that fairly easily

00:10:02   with preprocessor macro definitions or commenting out some things or things like that. But that

00:10:09   doesn't usually come to that for me for whatever reason. Usually, whatever I make,

00:10:14   I ship soon afterwards because I've gotten pretty good at the mad rush at the end to

00:10:20   just polish all the rough edges and fix the remaining bugs of what I have and then just

00:10:24   ship what I have. But it's more of a mode switch for me to stop making new stuff at

00:10:33   that point and to just only focus on making what I have releasable.

00:10:38   - Yeah, and I think it sounds like there's a similarity that I have where as I'm developing,

00:10:45   I tend to have a very high level feature list of the things that I'm trying to accomplish

00:10:52   in an update or in a release. And then at a certain point, I switch from that kind of

00:11:00   a to-do list to what I call a punch list, which I think is a term from construction

00:11:07   for when you're finishing up a house. But you switch to this different mode where the

00:11:16   only things that are on your list are things that need to be fixed. You're no longer creating

00:11:22   anything. All you're doing is fixing things that are broken. And so it changes the nature

00:11:29   of it because that list, hopefully anyway, by necessity, will shrink to zero over time.

00:11:37   Whereas your feature list or your idea list or your more creative list can grow indefinitely

00:11:44   and probably should grow indefinitely in some ways. It's great when you can come up with

00:11:50   new ideas for your app, when you can come up with... It's awesome that when you start

00:11:54   using something for a while, then you're like, "Hey, what if it did this? What if it did

00:11:57   that?" Those are awesome. But I have to force myself to start... Right now, I have two lists

00:12:03   in my to-do list manager. I have one for the punch list for Workouts++ 2.0, and then I

00:12:09   have the everything else list. And any idea or feature, anything that I have that's an

00:12:17   idea for Workouts++ at this point, that isn't actively fixing a problem in the app right

00:12:22   now, goes onto the second list and won't be looked at until I get this release out. The

00:12:27   only thing that's on my list now is all these broken items, anything that needs to be dealt

00:12:32   with. And I tend to get into a nice cycle with those where I'll sit down, I'll try and

00:12:39   knock out three or four of those. I'll do either an internal beta or maybe send it out

00:12:47   to a few people, go through the app, see if anything's broken, and repeat. And it tends

00:12:53   to, in a good way, narrow in nicely where... When I first switch over from feature to punch

00:13:01   list, maybe I have 40 items on my punch list. Lots of things are a little broken. And then

00:13:08   I do a cycle through, now there's 20 things. And now there's 10 things. Now there's five

00:13:14   things. Now there's three things. I'm just gonna have to live with those in a ship. That

00:13:19   pattern seems to work pretty well for me. And it's important, I think, more importantly,

00:13:24   rather than how you do that, is having that mindset switch where at the end, you have

00:13:30   to have the discipline to say, "I'm not gonna add any more features at this point." Now

00:13:36   it's just fixing stuff. Because if you don't draw that line at some point, it just expands

00:13:42   forever. But having that mindset switch to, "Is it broken, or is it an enhancement?" And

00:13:48   if it's an enhancement, it goes in the next bucket. And it's important, I think, to have

00:13:52   that other bucket. I would drive myself crazy if I didn't have a place that I knew I was

00:13:57   going to look at that idea in the future, because I want to build it. I want to do that.

00:14:03   But it's like, I need to have a place to say, "You will look at that," in my case, "On December

00:14:09   13th, you can look at that feature. You can look at that idea and work out if it's a good

00:14:14   idea. But for right now, if it isn't broken, then it's not gonna get fixed." Speaking of

00:14:20   knowing when things are broken, our sponsor this week is Pingdom. You can monitor your

00:14:24   websites and servers. Start today at pingdom.com/relayfm. You will get a 14-day free trial. And when

00:14:31   you enter offer code radar, check out you got 30% off your first invoice. Pingdom is

00:14:36   focused on making the web faster and more reliable for everybody by offering powerful

00:14:40   and easy to use monitoring tools and services. For example, you can monitor the availability

00:14:45   and performance of your server, database, or website by using more than 70 global test

00:14:50   servers that emulate visits to your site, checking its availability as often as once

00:14:53   every minute. Websites are so sophisticated and potentially complicated these days, and

00:14:59   very often include several different dependencies such as contact forms, e-commerce checkouts,

00:15:04   logins, search, so much more. And Pingdom makes it possible to monitor the availability

00:15:08   and performance of all of these key interactions people have with your site. Because stuff

00:15:12   breaks on the internet all the time. Every month, they detect 13 million outages at Pingdom.

00:15:17   That is more than 400,000 outages a day. So whether you have a small site or you're managing

00:15:22   a complete infrastructure, it is very important to monitor its availability and performance.

00:15:27   And Pingdom is great. I have used Pingdom since long before they were a sponsor. I used

00:15:31   them all the way back at Tumblr, and I assumed they set up Instapaper. I set up Pingdom immediately.

00:15:37   Then I went and I set up Overcatch. I set up Pingdom there. It is wonderful. I've used

00:15:42   it all this time because it is great. I love knowing when stuff is slowing down or broken

00:15:48   or down. It is very, very useful to know. Because you want to know before all your customers

00:15:53   or your audience finds out. You want to know that first you can go fix it before too many

00:15:57   people see it. So all you do is give Pingdom a URL to monitor. If you want any kind of

00:16:01   custom conditions or logins, you can do that too, but you don't need to. They take care

00:16:06   of the rest. You are immediately notified whatever means you want. SMS, push notification,

00:16:11   email, and you can fix the error before too many people see it. Check it out today. Pingdom.com/RelayFM

00:16:17   for a 14-day free trial. And use code RADAR at checkout to get 30% off your first invoice.

00:16:23   Thank you to Pingdom for supporting this show and RelayFM.

00:16:26   So as a recording, you just released Forecast, your MP3 encoder, metadata manager, chapter

00:16:36   maker tool to the world finally. And I know this has been a long time coming. I don't

00:16:42   know exactly when you started working on this tool, but it seems like it was forever ago.

00:16:47   And I was curious if you had any thoughts about what got you through that last 1% to

00:16:52   finally actually ship it, put it out in the world, and start that next phase of its lifespan.

00:16:59   I wanted to release Forecast for a while. I had waited in part for the MP3 patents to

00:17:07   expire, the last of which expired this past spring. So I could have released it really

00:17:11   any time after that safely. And I intended to. But then basically throughout the summer

00:17:20   and fall, Overcast was basically on fire. Between iOS 11 and drag and drop and then

00:17:28   the iPhone 10, Overcast has been consuming almost all of my development time. I have

00:17:35   touched Forecast very little in the last year, just because Overcast just was needier than

00:17:41   I expected. And so what finally pushed me to release this, I mean I've been using

00:17:46   this both myself and in a small private beta with some of our friends who are also podcasters

00:17:52   for like two years. And so I knew the functionality of it worked. The app still had a bunch of

00:18:00   rough edges. And it still does, because it's a Mac app and I am terrible at making Mac

00:18:04   apps and I'm very, very new to it. AppKit is very little like UIKit. It's very different.

00:18:13   And there's still a lot of legacy to be aware of, a lot of rough edges, a lot of things

00:18:19   you have to consider, a lot of functionality that simply just doesn't work. And iOS has

00:18:26   a lot of this too, but I know what it is on iOS. I've been there for so long that I

00:18:29   have a lot of experience there. On the Mac, it's all new to me. It's all unfamiliar.

00:18:34   And the amount of available help on the Mac is way smaller. You can't just like do a

00:18:40   web search for some problem you're having and get a thousand Stack Overflow results

00:18:44   about the answers. No, like for Mac problems you're lucky to get one. You might even get,

00:18:50   you might get two, maybe, but you're probably only going to get zero or one answer to what

00:18:54   you're looking for. And it might be on some ancient mailing list that's impossible to

00:18:58   skim or find. So Mac development is very slow going. So part of why I haven't released

00:19:05   it yet is because it wasn't, the app wasn't very pretty or polished and so I was afraid

00:19:13   to release it because I was afraid that people would judge it on these superficial but still

00:19:19   important qualities that I'm just not very good on the Mac yet and I might never be.

00:19:24   So that was part of it. But our conversation last week was a pretty big motivator for me

00:19:29   to go into let's just release this mode because you know last week we basically, you know,

00:19:36   I talked with you about how it, how I decided basically that it should be free because it

00:19:42   has benefits to me beyond just money. Like it benefits overcast, it benefits podcasts

00:19:50   as a whole. You know, it saves people time and it can generate a lot of goodwill for

00:19:55   a podcast. So I figured like based on that rationale, if it's going to be free, then

00:20:02   I don't, I have a lot less to worry about. I can pull out a lot of like weird license

00:20:06   checking code and I don't have to worry about like in app purchases or the Mac app store

00:20:10   or anything like that. Or building some kind of storefront for the website and then supporting

00:20:14   paid like the number of things you have to do and worry about and manage if it's free

00:20:20   drops down tremendously. And then also I figured like, well, I want to start accruing those

00:20:25   benefits now. All those benefits are going to have to overcast and to podcasting everything.

00:20:31   Why keep this private any longer? Like this is probably good enough to release for free

00:20:34   right now. And so I basically went into, you know, punch list mode as you said, like I

00:20:41   fixed the few remaining bugs I cleaned up. I disabled some experimental stuff that I

00:20:45   decided was a dead end. I polished up some of the rough edges and I released it. Now

00:20:54   the process of releasing a Mac app when you've mostly not released a Mac app before, I did

00:20:59   release Quitter before, so I have one Mac app that doesn't even have a window really.

00:21:04   Oh no, it does. I guess the preference is window. But yeah, like it's one very small

00:21:08   Mac app that lives in the menu bar and does very little. So that was a little bit easier.

00:21:13   But when you release apps outside of the Mac app store, and I don't want to get too much

00:21:16   into that, but once I decided that this was not going to be paid, the argument to be in

00:21:24   the Mac app store basically evaporated because the complexity of doing that and maintaining

00:21:30   a different version that was sandboxed versus not sandboxed, it was not worth it. And maybe

00:21:37   down the road it will be, but right now it's not. But when you're not in the Mac app store,

00:21:45   you basically have to build iTunes Connect from scratch for yourself. I think us iOS

00:21:50   developers have, we take a lot of things for granted. Things like updates. Like how does

00:21:59   your app update itself if it's not in an app store? And so what Mac apps do is they have

00:22:03   this framework called Sparkle usually that is like the auto- updating framework that

00:22:08   everyone has seen the windows of, but maybe you don't know what it's called. But almost

00:22:13   all apps use this on the Mac. But you have to then have an RSS feed on your server that

00:22:18   tells the app installations like what version is available. You have to have a signature

00:22:24   workflow on it to sign your updates to make sure that it's coming from you. And then you

00:22:29   have to have some kind of way to manage these builds and validate them. And so before when

00:22:34   I was just doing the forecast beta and for Quitter, I just have a couple of local shell

00:22:38   scripts that do all this. And it's pretty crappy, but it's pretty basic needs on those.

00:22:44   For forecast, it's an overcast product. So I decided it should be part of the overcast

00:22:48   website and that I wanted some kind of web management panel to do these things. So basically

00:22:58   yesterday I built all of this. I basically built myself a crappy, small, limited version

00:23:03   of iTunes Connect that I upload a build, it reads the plist, it pulls out the keys for

00:23:10   like build number and version number and everything and it sticks it all in the database and I

00:23:15   can edit the release notes, which is also good because then I can provide a version

00:23:18   history on the website very, very easily because it's all in the database. So I edit the release

00:23:22   notes for it, be able to publish it or have it not be published yet. Next I'm going to

00:23:28   create a beta channel, which I haven't done yet, but basically just not even to the level

00:23:34   of sophistication iTunes Connect had, just like a granularity of like, is this version

00:23:37   on the beta train or not? And then have a separate feed for that. Then it's all on the

00:23:42   overcast site and then it runs through your overcast CDN, so I don't have to worry about

00:23:45   like download, you know, overloads or overages. So it was a lot of work to build all that,

00:23:54   and this is like, it's one of those things like the first time you make a Mac app, you

00:23:57   learn all this crazy stuff. I mean, just like, you know, I guess similarly the first time

00:24:00   somebody makes an iOS app and you learn about like all the provisioning stuff that you have

00:24:05   to do and certificates and everything else. So I guess it isn't that different of an amount

00:24:09   of work, but you know, certainly the first time you build all this, it's a lot and this

00:24:14   is all even easier because it's free. Like if it was actually paid and I had my own storefront

00:24:21   on my website, I'd have to build that and manage that, and that's not a small thing

00:24:25   either. So there's a lot that you have to do in the Mac world that you don't have to

00:24:30   do in iOS, at least if you don't do the app store. And it's kind of made me appreciate

00:24:34   like, oh, this is why people still use the app store. Like not everyone uses it, and

00:24:39   a lot of big developers don't because they have the resources not to. But certainly if

00:24:44   you are a small developer and you just want to put something up, charge a few bucks for

00:24:49   it or whatever, the app store is way easier than doing it yourself. It's not even close.

00:24:54   I guess they get that 30% for a reason. So ultimately it was a ton of work, almost none

00:25:00   of which was the forecast app itself. Like almost all of it was putting together the

00:25:05   infrastructure and making a page for it on the site, writing what's on the page, taking

00:25:10   a screenshot, putting that on the page. It's all this work that we have when we release

00:25:17   a new app, especially if it's the first app for a certain platform that we've released.

00:25:22   There's so much work to do. It's like that last 1%, as you said, the last 1% is ridiculous

00:25:28   when it's like your very first Mac app that you've ever made. Like you make this happen

00:25:32   somehow. It's so much work. And it's nowhere near polished or done, but it's close enough,

00:25:38   it's functional. And so I just shipped it.

00:25:40   And I think, too, there's a more general point that I hear you saying. It's important to

00:25:46   remember, too, that there may be a lot of things that you have to do before you, even

00:25:52   when you finally get to the point that you let go and say, "Yep, this is good enough.

00:25:56   I'm going to put this in the store." Like there is still, like, the work is not done

00:26:00   at that point. Like the work may be done in Xcode. Like you may have finally uploaded

00:26:06   your binary to iTunes Connect or, in your case, like Overcast Connect. But then you

00:26:14   have all this other stuff that you have to do. Like are you going to do any kind of frequently

00:26:17   asked questions? Or do you have to build a website for it? Are you the thing? Like there's

00:26:22   any kind of marketing materials, even just the iTunes Connect kind of screenshotting

00:26:26   and all that kind of stuff. Like if you have a localized set of screenshots, it takes a

00:26:31   good day for whenever I need to update my screenshots, even when I automate a lot of

00:26:36   it. Like just because I think Pedometer++ is localized into 10 languages or something

00:26:43   like that. And so if I have multiple five screenshots times 10 languages times multiple

00:26:51   devices, like it just goes crazy. And it's important, I think, to keep that in mind,

00:26:56   too, that if you have set a deadline and you have communicated that, that you need to leave

00:27:01   buffer in your workflow so that you have time to do all this stuff that has nothing to do

00:27:09   with finishing the app, that you finally got your punch list down to good enough, you're

00:27:14   done, you still have a bunch of other stuff that you're going to have to do. And so just

00:27:18   like leaving enough buffer in your schedule to actually do that is important. Like I know

00:27:23   I've gotten caught out for iOS updates where it's like I feel like I'm working towards

00:27:29   making it so that as soon as the gold master version of Xcode comes out and as soon as

00:27:33   iTunes Connect opens up, I'm ready to go. And then I've forgotten that I'm like, I'm

00:27:38   going to need a whole new set of screenshots. And so rather than submitting right that moment,

00:27:42   I'm submitting like a day later. And so that's just entirely poor planning on my part.

00:27:47   Yeah, screenshots are my Achilles' heel. They always take me, like I always forget that

00:27:51   I have to do them. And then the very last minute I'm like, oh crap, I need to make forty

00:27:55   screenshots. This is bad. And then, you know, then I have to figure out some way to try

00:27:59   to automate some of it. I know there's tools out there to help with this, but I've never

00:28:02   bothered to set one up. And so it's it's that's a big deal. This is one of the reasons why

00:28:08   I haven't made a preview videos yet. I probably should make videos just to try them out, but

00:28:13   I haven't yet in part because that's a massive undertaking to add to this, like to add like

00:28:21   the production of an entire video to the list of things you have to do every time your UI

00:28:26   changes. That's or every time a new device comes out. That's a that's a large amount

00:28:31   of work. And so, you know, it has to be pretty compelling. And I just I haven't had the time

00:28:36   to do it yet. But, you know, now, you know, forecast is out. You know, it's mostly stable.

00:28:42   You know, I don't think I need to do a whole lot of work on it release wise. Overcast is

00:28:46   pretty stable. So I'm back in a good place now. But man, that last one percent on both

00:28:51   of those things was was killer. Yeah. And I think the thing that's fun is like now you're

00:28:55   in the place that is, at least if anything, if you're anything like me is the best part,

00:28:59   right? Now you can look at your big long feature list and you're like the reward for battling

00:29:04   through that last one percent is that you now have the opportunity to look at your like

00:29:08   fun feature list and, you know, decide what's fun to work on next. And like that's in a

00:29:14   weird way. It's like as an engineer, like the best reward for for for lots of hard work

00:29:18   is more hard work. But at least it's like the fun work that I enjoy doing rather than

00:29:23   the hard like the the grunt work that I don't enjoy doing as much. Exactly. All right. We're

00:29:29   out of time this week. Thanks for listening, everybody. And we'll talk to you next week.

00:29:32   Bye.

00:29:33   Bye.

00:29:34   [ Silence ]