0:00:00Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment.
0:00:06And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.
0:00:10So today's episode is going to follow, I guess, a story of a very kind of up and down experience
0:00:19I've been having over the last, unfortunately, couple of months in terms of some changes
0:00:24I've been trying to make in Podometer++. And you may, if you're a long time listener of
0:00:28the show, you may remember that back in October 4th, we even did a whole episode where I was
0:00:33talking about how complicated it is to implement step counting and diving into that. And that
0:00:39particular episode was motivated because at the time I was in the middle of making a big
0:00:47sort of fundamental rewrite, essentially, of the way that the step counting system in
0:00:52Podometer++ works. Which, given that it's a step counter, the step counting system is
0:00:58pretty fundamental to the app and for it to be useful. And so it was a change that I didn't
0:01:05take lightly. And it was a change that was motivated because when iOS 12 sort of came
0:01:10out, I started getting these sporadic reports that Podometer++ was undercounting steps compared
0:01:18to the health app or compared to other apps or in general that was undercounting. And
0:01:23at the time I went and did my kind of investigation, I started looking around, and as best I could
0:01:28at the time, my initial investigation found that I was seeing lots of undercounting if
0:01:35I was requesting step samples from Core Motion in the past. So I can ask for up to a week's
0:01:40worth of data, and when I was asking for data from like four or five days ago, I was getting
0:01:45undercounted values. And so my initial thought was like, "Oh no, they've changed the way
0:01:49that this is working. Old day's data is now going to be undercounted." And so there's
0:01:55no way that I can realistically use Core Motion for this anymore. I need to switch to health.
0:02:00Switching to health was really complicated and deals with a whole host of problems because
0:02:05the health API is not nearly as sort of performant as the Core Motion API. Sometimes it just
0:02:15hangs indefinitely. It doesn't get the data right away. It often has these like 15, 20
0:02:20minute delays from when you take a step before it would show up. And so I had to build this
0:02:25really sort of crazy complicated system to kind of manage that and work through it. And
0:02:33after probably honestly several weeks, maybe a month's work, I think I got to a place that
0:02:36I was like, "Oh, maybe this works." But then I kind of got stuck. And this is, I think,
0:02:43the core topic for today was I ended up in this place where I was afraid of releasing
0:02:49this change because I was sort of scared of making a change, messing everything up, somehow
0:02:56missing some case in my testing, and fundamentally breaking the app for everybody. Because most
0:03:02of the changes I make for a particular update, they may be a new feature, they may be a sort
0:03:08of little tweak somewhere, but it's unlikely that they're going to fundamentally break
0:03:12the app for every one of my users in a way that I can't easily recover from. And that
0:03:18was the case for this kind of a fundamental rewriting of the way that I'm acquiring the
0:03:23data that is key to the app. And I was stuck. And I think that is an interesting state to
0:03:29find in and for us to talk about because I feel like often we are going to find ourselves
0:03:33in a situation where we are making a change. And this change could be, you know, it could
0:03:39be breaking no matter how much testing you do, no matter how robust your system is, there's
0:03:43always going to be things that potentially could come up. And sometimes this can be paralyzing.
0:03:48And that's where I found myself. And I was sort of stuck for probably a month, sort of
0:03:53like ostensibly testing this, but mostly just kind of pushing it down the road because I
0:03:59was scared of what releasing it would actually be like. No matter how much I tested it, no
0:04:04matter how sort of much I walked around with five phones in my pocket, like going on long
0:04:09walks and then checking the data and doing all this kind of stuff, I could never feel
0:04:13confident enough that I wanted to release it. And I think that fear is kind of a tricky
0:04:18thing, because it pushed me into a place that I just wasn't being productive. I wasn't doing
0:04:21useful things. And honestly, like, I mean, I think and while I will continue down this
0:04:25road for other reasons, it's like, this is part of why I like stuck like, let me it's
0:04:29like, maybe let's think about making a parameter plus plus for Android, let's go and get an
0:04:33Android phone. Let's like trial like crazy, like extreme versions of work avoidance. Just
0:04:39because the word I could never feel confident enough. And that paralysis, I think is just
0:04:45like it is inevitable with whenever in time you make a big change. And I think it's just
0:04:49something we have to kind of work through to not let it get you stuck like it did get
0:04:53me stuck.
0:04:54I've faced a lot of these like, you know, big change potentials over the years, and
0:05:00I never I never become comfortable with it. Like it never becomes easy. And I, I will
0:05:07tackle them eventually, like, you know, and like, I'm currently facing a couple now, like
0:05:10I one that I'm facing with overcast in like the near term is when I when I do complete
0:05:18my transition to airplay to what I really have to do is basically rewrite and, you know,
0:05:24throw out a good chunk of my audio engine and and start it over with a different API
0:05:29and a whole different approach. And that is really, really intimidating to do. And it's
0:05:36going to be a lot of work. I've already you know, I'm still laying foundation work,
0:05:39so I haven't actually started throwing away the audio engine yet. So but that comes next
0:05:43like that that is going to be the next step like that. I'm probably going to be starting
0:05:46in the next month or two. And it's it's incredibly intimidating because basically,
0:05:51like, you know, I did all this code up in a very similar sort of like I did all this
0:05:55all this code and did this approach up to this point so far. But now in order to move
0:06:00it forward into what it needs next for the market or whatever, it needs to totally change
0:06:07needs to be something totally different. And so I'm facing, you know, a complete rewrite
0:06:11of core components of the app. And that's going to be really, really hard.
0:06:15And I think the weirdest thing I find too is it's like, it's hard because the apps are
0:06:22doing well. Like in this weird list before I found it's like as the app does better and
0:06:28has a bigger audience like the stakes increase in such a way that like if it breaks, it's
0:06:33one thing if it like when an app is new and young and if you break something, it's like
0:06:38maybe it'll affect a few hundred people or a few thousand. But as that number gets bigger
0:06:42and bigger and becomes more significant as like the way you make your living, like the
0:06:46stakes for shipping in a change like that just kind of get it becomes so scary to me
0:06:52the thought of like, I'm glad that iTunes Connect or App Store Connect now has the feature
0:06:58where you can roll out changes over seven days, which I think makes me slightly confident,
0:07:03but it is weird where like the stakes get so high and you're just like, I just I hope
0:07:07it works.
0:07:08Yeah, I mean, that's my problem too. It's like, you know, there's the you know, the
0:07:13old saying like if it isn't broken, don't fix it. Like, yeah, there's a there's a lot
0:07:19of inertia behind just keeping things going when they're working well. Like it's really,
0:07:23really hard to to take a risk like that. You know, not only is it hard to justify the time
0:07:29to do something like this sometimes, which we've talked about before, but it's also just
0:07:33like it's a risk. Like like I have this audio engine that's being used by all these people
0:07:36and it's working fine. And I wrote I wrote most of the core components in 2014, I think,
0:07:42or 2013. And but it's been fine. It's been totally fine. And so like I I don't want to
0:07:48touch a lot of this stuff. It's almost like like some of the the programmers that I respect
0:07:55the most in a field I will never ever, ever feel comfortable working in our programmers
0:08:00who work on financial software. So, you know, what is code that deals with people's money,
0:08:05whether it's banking or whatever that to me is very intimidating because if you screw up,
0:08:11you could have massive consequences for you know, you could have legal issues. You definitely
0:08:17would have accounting issues like you could lose your company a ridiculous amount of money
0:08:21or you could lose people a ridiculous amount of money like so like anything that works
0:08:25with money, you know, like people make fun of the banking industry for having all this
0:08:28old like Fortran code. But there's a reason why because nobody wants to touch it because
0:08:32it works. And if you touch it and if you touch it wrong, you have a big problem on your hands.
0:08:37So that's kind of how I feel like with a lot of my, you know, like my like foundational
0:08:41audio code. It's like, you know, it's not quite to that level of penalty if I screw
0:08:46up but it certainly has a lot of that stress of like this is working. It's really important
0:08:52to my app. It's working fine. And so, you know, even though I'm faced with wanting
0:08:58to rewrite a lot of it to get these to get you know, new technology, new features, etcetera.
0:09:04That's really scary because I know it's not going to be perfect. It's and it's so
0:09:08foundational to the app. I know I'm going to introduce bugs. And so for a while, you
0:09:12know, for like the first month or two after I release it, it's probably going to be
0:09:16worse in some respects for some group of people because I, you know, no matter how big I make
0:09:22the beta, there's going to be bugs that get out, you know, that, you know, that we
0:09:25didn't catch during the beta. And so like I just I know I'm going to be messing things
0:09:29up for somebody and that's a really hard thing to to take on. And, you know, it ultimately,
0:09:35you know, in the long run, it's probably for the better to know like, okay, well, I'm
0:09:39it's going to be worse, but I'm laying a better foundation for the future. But it's
0:09:45hard to tackle that now when the part that will be most immediate after release is the
0:09:51worst part before I get to that nice future.
0:09:55Yeah. And it is funny. I think that as I've become more mature of a developer, I have
0:10:01much more of a confidence that it will break than I used to. Oh, yeah, it always breaks.
0:10:07Yeah. And it's like there's a it's like there's maybe a younger, more naive version
0:10:11of myself who would just be like, eh, seems to work. Let's ship it. And then like, as
0:10:16a result, I've shipped in the past, like horrific breaking bugs that like destroyed
0:10:21people's data and like did awful things. I think it because I didn't take it seriously
0:10:26enough. And like, that's one of those tricky things, these types of situations where, like,
0:10:31there is a good lesson in this kind of change that like being like really cognizant of the
0:10:38scope and the scale of the change and what the likely downsides are. And like that, it's
0:10:44sort of like the if you if you ever, you know, it's like if you're as soon as you stop
0:10:47feeling that kind of that nervousness about something, it probably means that you're
0:10:51becoming reckless, like having just in general in life, like, whenever something stops being
0:10:56nervous, it's because you've become reckless. And like, it's good to have a little bit
0:11:00of fear. It's good to have a little bit of a apprehension about when you make a big
0:11:05change about when you're doing something like this, that, like, you're being aware
0:11:09that yes, this is, you know, like, this could be bad. I need to have a big beta, I need
0:11:13to do all like do any kind of quality assurance that I can I need to test it. I need to do
0:11:19code review, even for even if only for yourself, like something that I've started to do a
0:11:22lot more is I'll end up like, you know, I do a diff in invert and get from my, you know,
0:11:28from like, whatever the like, the last good version is to the new version, I'll just
0:11:31go through all the all the diffs to make sure that they all like seem reasonable in isolation
0:11:35after like a couple of days of not working on the project. You know, just trying to try
0:11:40and catch like the weird like, why am I doing that? That seems really weird. Like, there's
0:11:44all these things that we can do, but it's motivated in a weird way, because I've made
0:11:49the mistake enough. And now that I know I'm like that I have, like 100% confidence that
0:11:54something is going to go wrong. And that confidence is like good, but can also make you get stuck.
0:12:02And like the the stuck part, I think is the thing that is ultimately like is where it
0:12:06becomes problematic, because the reality is and this is like, it's easy for me to say
0:12:10in retrospect for my own situation. But is the like, the the, like the app is not getting
0:12:17any better for me to sort of getting stuck. Like either the change is worth doing or the
0:12:23change is not worth doing. And after we after our break, I'll have a bit of a turns out
0:12:28crazy turn of events for this particular situation. But the ethic if the change is worth making,
0:12:34then it's worth it. We will do our best to make it right and to clean everything up.
0:12:40But at a certain point, like don't get stuck. And I think that is the best advice that I
0:12:44can give to myself and probably to anyone listening to this is, yes, it's kind of scary.
0:12:49And yes, it's going to break and it's going to cause problems. But like either you have
0:12:54to move forward or not. And if you if you're not going to move forward, like what are you
0:12:58doing, you're just going to be spinning your wheels forever, which isn't is a disservice
0:13:03to yourself, you know, to your business and to your customers.
0:13:07We are brought to you this week by Linode. Linode gives you access to a suite of powerful
0:13:12hosting options and their prices start at just $5 a month. You can be up and running
0:13:16with your own virtual server in the Linode cloud in under a minute. Whether you're just
0:13:21getting started with your first server or deploying a huge complex system Linode is
0:13:26the choice for you. They are for the fastest hardware, the fastest network and the best
0:13:31customer support backing it all up if you need help. It has never been easier to launch
0:13:36a Linode cloud server and Linode guarantees 99.9% uptime for server availability. Once
0:13:43your server is up, they intend to keep it that way. They have all sorts of wonderful
0:13:47other additional features beyond straight hosting. They have things like block storage,
0:13:51load balancing, manage beta or manage backups. It's wonderful. I've been using Linode now
0:13:56for I think about eight or nine years, some ridiculous amount of time because they're
0:14:00just great. And I have slowly moved everything I host over to Linode because they're just
0:14:05better than most hosts I've used. They're better than all hosts I've used honestly.
0:14:09Like the control panel is nice and easy to use. The pricing is incredible. It's such
0:14:14a good value. The performance is great. I'm a very happy Linode customer and I have been
0:14:18for a very long time. So it's great whether you want to host a web app or do something
0:14:24more specialized like maybe you want to run a mail server or run a VPN or run Docker containers
0:14:30or private Git servers. Whatever it is, you can host it at Linode. And they're hiring
0:14:34right now. If you want to maybe work there, go to linode.com/careers. Anyway, Linode has
0:14:39fantastic pricing options available. Plans start at one gig of RAM for just $5 a month.
0:14:45And they have wonderful plans that go up from there if you have higher needs than that.
0:14:48Listeners of this show, go to linode.com/radar to support us and that'll get you $20 towards
0:14:54any Linode plan. So on the $5 a month plan, that could be four months for free. And with
0:14:58a seven day money back guarantee, there's nothing to lose. So go to linode.com/radar
0:15:03to learn more, sign up and take advantage of that $20 credit or use promo code radar2018
0:15:09at checkout. Thank you so much to Linode for supporting this show and Relay FM.
0:15:14So if you listened to last week's show, you may remember a little anecdote I told where
0:15:20I had to make sure that I didn't learn the wrong lesson from finding an old monitor buried
0:15:26in a box of old cords in my garage. That the lesson I shouldn't take from that is...
0:15:31What was the right lesson to learn?
0:15:34The right lesson is that sometimes hoarding technology will be useful, but hoarding technology
0:15:40in general is probably not good for you. There's a tremendous selection bias and if you focus
0:15:46on that selection bias, you'll have problems. So I have to do the same thing for this story
0:15:52I'm about to tell about not learning the wrong lesson from the way this situation with Podometer
0:15:59++ ended up playing out. Because I ended up, like I said, I got stuck, I got paralyzed,
0:16:06and this went on for months. Without exaggeration, probably at least two or three months. I've
0:16:11been stuck in this place where I have this code that I think kind of works, I've tested
0:16:15it as best I can, it seems to work, but I'm so stuck, I don't want to ship it. And all
0:16:20this time, people, users out in the real world, which is sometimes hard to keep in my mind,
0:16:26are having this trouble. People are getting undercounted steps, and this is bad, and it's
0:16:30kind of getting increasingly worse and problematic. And at one point, and this happened just last
0:16:36week, I got an email to our support from someone who said they're having this undercounting
0:16:42bug, and they said something in their email that totally changed and reframed what I thought
0:16:49the actual problem was. Because they mentioned that the today widget was showing the correct
0:16:57number, but the main app was showing the undercounting number. Which is one of those little things
0:17:05where you never know when there's going to be a little clue that just completely reframes
0:17:10the problem for you. Because suddenly, this issue that I thought was old data being underreported
0:17:16turns out couldn't be the case, A, because this is happening on today's data. Like, the
0:17:21today widget is strictly showing today's date, or today's step counts. And so, it's something
0:17:28else, and the way that I query the data between the today widget and the main app is slightly
0:17:35different. Because the today widget only has a concept of today, it doesn't have to store
0:17:40data and deal with all the crazy timezone issues and all the stuff that I had to deal
0:17:45with before for the main app, which has a concept of history. The today widget just
0:17:49asks Core Motion for the steps from midnight to today, or till now. So it just does one
0:17:55query, whereas the main app had done the thing where, I don't know if you remember from episode
0:17:59143, where I dived into this, I query the data every 15 minutes, so I get these 15-minute
0:18:04chunks of data, and it adds them all up for today. But the today widget doesn't do that,
0:18:10it just asks for all of them. And so, when he said that, it was one of those, like, "Huh,
0:18:15that's really weird." I go back to Core Motion, I go back to investigating, and it turns out
0:18:20that the behavior that I was observing, where old data was being undercounted, was I was
0:18:27seeing the wrong thing there. What was actually happening is data was always being undercounted,
0:18:33but not all the time. It could happen on any day at any time, and Core Motion was just
0:18:38kind of unpredictable with this, because I started asking for data in different time
0:18:43buckets. I started asking for data in, rather than 15 minutes, into hour buckets, or two-hour
0:18:48buckets, or six-hour buckets, or the whole day. And I noticed that, depending on how
0:18:53I asked for the data, I got wildly different numbers back. And so the actual bug, and this
0:18:59is an issue that was introduced in Core Motion in iOS 12, is that when you ask for data in
0:19:07short chunks, you are more likely to expose yourself to a bug that seems like Core Motion
0:19:13has a greater than or equals to, that should be a greater than or less than or equal to.
0:19:18Like, there's some kind of boundary condition issue where it isn't correctly counting steps
0:19:23that happen across the interval that you're asking for. So if I was asking for steps from
0:19:294pm to 5pm and then from 5pm to 6pm, if you happened to be walking right at 5pm, like
0:19:36the way it accounted for those steps meant that they sometimes got sort of fallen off
0:19:39and they didn't show up in either bucket. Turns out, that's the problem. That bug,
0:19:47totally easier to fix, because it's way, like, I can stick with Core Motion, I don't
0:19:53have to deal with all the craziness with health, and mostly, the bug goes away if you ask for
0:19:58it in hour-long chunks. It doesn't completely go away, but it seems like 80-90% of the bug
0:20:03just disappears, and I can deal with that. All I really need to do is account for the
0:20:08two time zones, like Nepal and Northern Australia, where they have weird half-hour or quarter-hour
0:20:14time zones, but that's a vanishingly small percentage of my users. Everyone else, they
0:20:20won't even notice a difference if I switch to hour buckets rather than quarter-hour buckets.
0:20:25And then I can very easily just ask for the whole data for the whole day, and if the numbers
0:20:29are slightly different than, like, if I am getting undercounting at the hour level, which
0:20:34seems pretty rare, if I am, I can take the difference and I can reapply it to the steps
0:20:39that I saw to make sure that the two numbers match up. Like, super easy, it was about a
0:20:43day's work to fix, and that's the fix that I submitted to the App Store yesterday. So
0:20:48I need to not learn the lesson that my paralysis and my fear at not shipping the update previously
0:20:55for the last two months, hurting my customers for all this time and all this problematic
0:20:58thing, meant that I ultimately found the correct solution, and instead I need to learn, you
0:21:04know, have the lesson that being stuck is problematic and is not good, and I shouldn't
0:21:08just wait around for this magic-like customer support query with this super clue that magically
0:21:15solves my problem for me, because I suspect that is a fairly rare circumstance and not
0:21:20something that is going to happen all the time.
0:21:22- Wow, that, I can't believe that all that was the result of just this crazy little bug
0:21:31in the framework instead of, like, some fundamental need.
0:21:34- Yeah, no, me neither.
0:21:36- Yeah, I can imagine. Oh, wow, yeah, so I, one thing that I also want to talk about is,
0:21:43like, maybe, like, some of these large changes and rewrites and things that maybe are not
0:21:49worth doing, you know, and it's always hard to tell, you know, when something is new in
0:21:55your mind, like, when the concept of, you know, oh, I'm going to rewrite the whole app
0:22:00in HealthKit or whatever, I'm going to rewrite my whole audio engine to be AirPlay 2 compatible.
0:22:05Sometimes it's hard to see past, like, 'cause in that moment, you are very excited about
0:22:09that idea, and so you start, like, oh, man, wouldn't it be great, you're thinking of all
0:22:12the positive things, wouldn't it be awesome if I rewrote this thing with this, you know,
0:22:17if I did X, Y, or Z, that's this massive job, because then it'll be justified by having
0:22:22benefits X, Y, Z, and it's hard at that time to see, like, is this going to be worth, like,
0:22:30a six-month slog or something, like, some massive amount of time, you know, having a
0:22:34period where there's going to be more bugs and it's going to be less stable and you're
0:22:37going to have problems to deal with that you otherwise wouldn't have, and it's hard to,
0:22:45in that period of, like, early project optimism, it's hard to really see and to make a good
0:22:50judgment of, like, is this really ever worth doing or not, or is it worth doing now or
0:22:57not, and one of the areas that I've been, like, toying with in my head for, ah, about
0:23:03a year is I would, theoretically, I would love to redo the entire user data model in
0:23:11Overcast to be where everything about your user data is stored in iCloud and that Overcast
0:23:19servers know nothing about anybody and that all they're doing is, like, crawling the feeds
0:23:23and sending push notifications, like, whenever, like, things are new, like, this feed is new,
0:23:29go and it would, like, notify everybody, you should go check this feed because it's new
0:23:32and you deal with your user stuff on your side, and this is a fantasy in part because
0:23:37I don't want people's data as much as possible, like, I'm trying to get rid of people's data
0:23:41if I can, and in part because it would make running the servers dramatically simpler and
0:23:46not only way cheaper, but, like, way fewer problems and way fewer liabilities, like,
0:23:52if I ever got hacked, there would be nothing really to see, if the, you know, if certain
0:23:57servers go down, you know, it wouldn't be, it wouldn't impact the app that much if, you
0:24:02know, if, you know, I could run a lot fewer servers, like, way, way fewer servers and
0:24:07have, you know, a way simpler server-side code base, so, like, this is a wonderful fantasy.
0:24:13The reality of it is that that would require rewriting massive portions of my app and then
0:24:21I would, and massive portions of the backend that currently, like, achieve certain functionality
0:24:26by having user data, I have to move that into the app into client-side logic and certain
0:24:31functionality would just no longer be available because I don't have, I wouldn't have, like,
0:24:35the, you know, combined user data on the server, so you wouldn't have things like recommendations
0:24:39be very easy, and then, and then I would have all these, like, all this, like, new code
0:24:45to write, all these bugs to fix, I'd have to deal with sync, which is really hard, and
0:24:50I already have sync working, so it's like, once you have it working, don't touch it,
0:24:54but you know, it's like, that's, that'd be really hard, and then I would have all this
0:24:58lost time to get this in the system. Meanwhile, my users in reality would not care at all.
0:25:04This would benefit most users, zero. Like, some people would care about the additional
0:25:10privacy, but most people are very happy with the current level of privacy I offer, and
0:25:14so it, like, most people wouldn't care. It would just be, like, a theoretical benefit
0:25:18to me long-term, like, I, you know, my server-side would be much simpler and cheaper to run,
0:25:21but like, the reality is, like, that would be a massive undertaking, and I'd have to
0:25:26rewrite so much of the app in order to achieve a benefit that, if I think about it only,
0:25:33like, optimistically, academically, it sounds great, but in practice, like, man, all that
0:25:38bug potential, all that work, all that rewriting, sometimes these big, ambitious ideas aren't
0:25:44worth doing, and I think that's one of those things that, like, it'll probably never be
0:25:48worth doing that, because it's just such a massive undertaking for a benefit that most
0:25:53of the users don't care about.
0:25:54>>
0:26:01Yeah, and I think it's so easy, and to jump to wanting to do it, because I think in the
0:26:03moment, it is easy to see the, to see the benefit, especially the benefit for you, and
0:26:10I think that is, like, of all the things that I'm kind of trying to take from this experience
0:26:15for myself, and I think it would apply to what you're talking about, is the, like, the
0:26:19blessing and the curse of being independent and not having, not being told what to do
0:26:25means that we can do anything, which is great, in the sense that it gives us flexibility,
0:26:31it gives us the opportunity to be creative, like, there's lots of really cool things that
0:26:35go into that, but it also means that we can be our own worst enemy and be making changes
0:26:41and doing work that is ultimately not in line with the broader context of our users, or
0:26:48we can be solving the wrong problem or the wrong problem at the wrong level, because
0:26:53it's, like, we only have our own perspective, and I think that's the thing that is probably
0:26:59best for us to, like, the broader advice is just to try and keep a broader perspective
0:27:05about any time we have to make a change in our application.
0:27:08Who is this going to impact?
0:27:10What are the benefits?
0:27:11What are the benefits to me?
0:27:12What are the benefits to our customers?
0:27:15And try and ask more people about this situation, about the change.
0:27:20Is it worthwhile?
0:27:21Like, talk to people that you know who can give you good advice, whether that be your
0:27:25users, whether it can be other developers, friends, but family, whatever it is.
0:27:29But I think in this situation, like, I kind of wish that I had, like, in previous jobs
0:27:36where I've worked, there likely would have been somebody who, as soon as I found my first,
0:27:42like, solution that I thought, like, "Oh, it seems like this is the problem," it would
0:27:46have been like, "Are you sure that's the only problem?
0:27:50Could there be more problems?"
0:27:51Right.
0:27:52Like, and then if I'd spent just, like, whatever it was two months ago, if I'd spent one more
0:27:56day or one more hour or had a slightly different testing regime to work out what the problem
0:28:02was, like, rather than being stuck in my kind of, like, very focused, like, you know, sort
0:28:08of, I had a very fixed sort of concept of what the problem was.
0:28:12If I had a different perspective, if I had a broader mind, like, mind about what I was
0:28:16trying to look for, like, rather than just being like, "Huh, in my current system, when
0:28:19does the data go bad?"
0:28:20Versus like, "What if I try a different approach to this problem?"
0:28:25Like, having that broader perspective is probably good.
0:28:27And in, like, in the case of what you're describing of, like, there could be these really cool
0:28:31architectural benefits that would be so great for you.
0:28:34But if they don't benefit our customers, or they don't make, or like, they're not really
0:28:40moving the product forward, then they probably aren't worth doing.
0:28:44Yeah.
0:28:45And this can apply to lots of different areas.
0:28:46I mean, one area that we probably should save for another episode is, like, you also might
0:28:51have a similar kind of, you know, potential for change in your business model.
0:28:58Yeah.
0:28:59You know, like, that's, you know, we've been talking about code this whole time and, you
0:29:02know, architectural considerations, but there's also, like, you could want to change your
0:29:05entire business model up, and that comes with some of the same risks and thoughts and everything.
0:29:10Obviously, you know, some stuff is different, but that's probably safe for a different episode.
0:29:13Sure.
0:29:14There's a whole lot of fear associated with that for sure, though.
0:29:16Oh, yeah.
0:29:17And that's with good reason.
0:29:18Yeah.
0:29:19We will get to that another time.
0:29:20But today, we are out of time.
0:29:21Thank you so much for listening, everybody, and we'll talk to you next week.
0:29:24Thanks.
0:29:25Bye.
0:29:26And if you happen to work on the Core Motion team, bug number 46606259 could use some love.
0:29:31(laughs)