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 usually not longer than 30 minutes, so let's get started.
00:00:10 ◼ ► So I think, you know, I remember back in the early days of my career where I would, you know, it's still fresh out of college and I'd done my computer science degree and, you know, they would talk about all these different methods for software design.
00:00:23 ◼ ► And I remember doing a class of all about writing specifications for software development, and you had like the iterative approach or you had a waterfall approach and you have all these kind of, you know, lofty and, you know, sort of very thoughtfully thought through designs for how to come up with the answer to how do you know what it is that you should build.
00:00:43 ◼ ► And here I am, you know, I guess, oh, gosh, that's that makes me feel like 20 years later. And I use essentially none of those when I was reflecting on my approach for planning what features to build and how I structure my development.
00:00:57 ◼ ► And instead, I take an approach that feels much less like it's structured and much more like it's something that is just sort of operates on happenstance and intuition.
00:01:08 ◼ ► But at the same time, I've also found an approach that I think is very effective and helpful. And for me, anyway, has been really successful and that when the times in my career when I have instead taken the more regimented thoughtful like, I'm going to sit down and plan this out, I'm going to do some, you know, prototyping and sketching out and all these types of very much more like robust processes that in many ways you probably need to do if you have more than one person like my approach that I'm about to describe.
00:01:37 ◼ ► I fully commit to is this is a terribly terrible idea for a team of more than one person. But it is an approach that I think is super effective and helpful for me.
00:01:48 ◼ ► And I think I wanted to share it just because I think it is something that it's different than the typical way to do it. And it works really well for me.
00:01:55 ◼ ► So it's like one of those like take it or leave it if it works for you. Awesome. If it doesn't just move on, just let this wash over you.
00:02:01 ◼ ► It'll have some nice metaphor and some nice graphics to it that you could paint in your mind. So enjoy that part. But you know, this is just one of those classic disclaimers. It's like works for me.
00:02:11 ◼ ► So, you know, do with that as you will. Your mileage may vary. Yes, exactly. Your mileage may vary.
00:02:17 ◼ ► All right. So it's like if you if you're in a place where you could safely close your eyes, this would be the time that you could start making a picture in your mind based on what I'm describing.
00:02:26 ◼ ► So I want you to imagine yourself like you're it's almost like you're dropped in to like a wilderness area. There's mountains, there's streams, there's valleys.
00:02:35 ◼ ► There's all kinds of things going on around you, but you've never been here before. This is us coming out of WDC where Apple has announced all of these new features, all these new things.
00:02:44 ◼ ► And they're just dotted all around this wide wilderness around us. There's all these things going on, but we haven't actually been there.
00:02:50 ◼ ► We've never seen these things. They existed only in Apple Park before this. And so that is where we start to find ourselves starting.
00:02:57 ◼ ► WDC in many ways would be like if there was like a park ranger or something at the visitor center that you go to and they show you all these pictures of these places you're going to go to.
00:03:06 ◼ ► And they talk about the valleys like, oh, you know, go to the Valley of App Intents and there's these beautiful features and waterfalls coming out of this.
00:03:14 ◼ ► You know, be careful of this. There might be a rattlesnake there, so be careful around this part. But it's the person in the visitor center who's telling you about this thing that you're about to go and experience.
00:03:24 ◼ ► But they're not taking you there. They're not holding your hand. It's not like you have a guide who will take you on this journey.
00:03:30 ◼ ► You are going to be on your own. So you have this brief opportunity in the visitor center where they'll tell you to some degree what to come. They'll show you some pictures.
00:03:39 ◼ ► After that, you're kind of on your own. And then you have this question of like, okay, well, how do I explore this place? How do I understand what is actually here?
00:03:47 ◼ ► And where am I going to find things where the picture on the brochure does not match the reality?
00:03:54 ◼ ► The picture on the brochure is this beautiful lush valley and you go around the corner there and it's just desolate and barren and it's terrible and dangerous.
00:04:03 ◼ ► You never know where those are. And believe me, many times in the beta cycle, there are many of those barren wastelands that you will find yourself in that can be very difficult and painful.
00:04:14 ◼ ► So how do you do this? And the one approach would be to sit down based on your conversations with the rangers at the visitor center.
00:04:21 ◼ ► You'd come up with a plan. You'd lay it all out. You'd sit there with a sketchbook. And you would design, based on what you've been told, is the reality, kind of where to go from here.
00:04:30 ◼ ► And there's something to be said for that. That is an approach I've taken a couple of times. I think it is very thoughtful and interesting to sit down and based on what you've been told to come up with a plan of action, to come up with something that you think.
00:04:42 ◼ ► But the difficulty with that approach, the difficulty to taking the approach of that you're just kind of relying on what you've been told about a feature that you haven't actually been to these places yourself.
00:04:51 ◼ ► You haven't actually experienced what it's like. And so you can be easily swayed by wishful thinking where a well-intentioned engineer during W3C describes a feature working in a particular way.
00:05:03 ◼ ► And you could either misunderstand what they were saying in terms of they're kind of giving you the best case scenario, but the common case scenario isn't quite as good.
00:05:11 ◼ ► Or you just completely misunderstand what they're saying. And they're saying one thing and you're reading it as the other. And that can really get you in trouble.
00:05:18 ◼ ► It's certainly gotten me in trouble many, many times. And so instead, the approach that I take is I put on a big old backpack.
00:05:27 ◼ ► My favorite hiking backpack is this big orange and black backpack with massive capacity. I load it up with as much stuff as I want because when I'm backpacking I never want to be short on space.
00:05:39 ◼ ► So I put that on and I just kind of head out randomly into the wilderness. And that's what I do. And what that looks like in practice is what my goal is, is to go down every valley, every path, every place that I can that I think there might be something interesting,
00:05:57 ◼ ► just enough to feel like I understand it. To feel like I have a sense of what it's like to have actually experienced, in the metaphorical sense, the dirt under my feet. I want to feel what it's like to try something there.
00:06:10 ◼ ► And as soon as I have that, as soon as I feel like I'm not learning anything new, I immediately turn around, run back to the visitor center and try something else.
00:06:18 ◼ ► Because my goal in this early period is just gathering information. I'm not trying to set up camp anywhere. I'm not trying to actually do anything that will have an enduring value beyond knowledge that I'm gaining.
00:06:31 ◼ ► And this is a process that I then will repeat over and over and over again. And so recently, if I wanted to get out of the metaphorical, you can open your eyes and you can think about the practical.
00:06:42 ◼ ► What this looks like practically is I have built, I don't know, I think probably 10, 15 different projects in the last week, all of which are barely working, half-baked, terrible things that you'd never want to ship,
00:06:55 ◼ ► but have let me explore an idea, have let me explore a technology, have let me try something new, let me do it in a way that is safe, in terms of having to refactor some big part of my app that will be annoying and awkward.
00:07:09 ◼ ► It's like I'm just playing around in all these different sandboxes and going down all these different paths. And at the end of everything, I'm gathering up all these bits.
00:07:16 ◼ ► And very often, I think the thing that why this has been so valuable to me is that I will inevitably find places that I didn't think would be useful, ideas for features that I didn't think of ahead of time,
00:07:29 ◼ ► that you can only find when you go down a wrong path or when you go down a path in one way thinking it's going to go, you think the path is going to veer to the left, it turns out it actually goes to the right.
00:07:38 ◼ ► And that has happened to me so many times where I'm starting to build a feature that I have in mind. I was like, "Huh, I wonder if I could make an interactive widget that does something. Great.
00:07:46 ◼ ► I build that interactive widget. It's wonderful, except it doesn't quite work right or it doesn't quite do what I think it should."
00:07:52 ◼ ► Or it's like, "Wait, actually, this would be way better if I did it this other way." And I'm gathering that information as I go.
00:07:57 ◼ ► And if you've ever gone for a walk with a toddler or a six or seven year old, like one of my favorite things when my kids were little is we'd go out for a walk in the woods
00:08:07 ◼ ► and I would always come back with my pockets just full of stuff, like stones and sticks and leaves and just anything they find along the way.
00:08:17 ◼ ► Could you hold this? Sure. I loved it. And you get back home and your pockets are just full of stuff.
00:08:22 ◼ ► And I think there's this sense, there's this almost like the toddler wants me to, it's like, "I don't know if I'll only need this later."
00:08:31 ◼ ► Right now, I'm at the bout of the transition point where I've gone down this process for a couple of weeks and I have a backpack full of all these little bits.
00:08:39 ◼ ► And now what I'm going to do is I'm going to sit down and be like, "Okay, now that I've actually been out there, now that I've actually experienced what all these different possible features are like in practice,
00:08:49 ◼ ► what do I actually want to build now?" And now I sit down and we'll do not necessarily the strict waterfall, like I'm going to make wireframes and then I'm going to write specifications or whatever.
00:08:59 ◼ ► That's definitely not me. But I will now be able to sit down and say, "What if that experience was exciting? What features did I half build and then I could show my daughter if she was excited about?
00:09:12 ◼ ► What parts of this actually seem to have legs?" Because now that I know that it exists, now that I have something tangible, I can react to it.
00:09:21 ◼ ► And it's not just a theory, it's something in reality. So that's the high-level, the backpack-driven development approach.
00:09:29 ◼ ► That's probably not something that you're going to find in any textbooks, but practically speaking, for my 20 years of doing this, it's something that I find is super helpful to try not to think too much about
00:09:43 ◼ ► that you come out of WDC or whenever you're trying to start something and you create your first branch in Git and you sit there and you immediately say, "Okay, I'm going to start working on this."
00:09:55 ◼ ► And you're starting from the place of, "I'm building production-ready code because I know where this is going." Because inherent in that is the assumption that you know where you're going and the reality is that you don't.
00:10:06 ◼ ► So instead, don't assume that you know where you're going. Don't assume that you know how to build the feature the correct way. Even just technically, I've had a number of things this week where App Intents has been a whole thing in my life.
00:10:18 ◼ ► They're very complicated, very powerful, but very complicated. And I've been finding it's like the first time I built an App Intent, I did it completely wrong, but I didn't know any better.
00:10:26 ◼ ► But the fifth time I tried to build it in a different context and I learned all these different things about this, and now when I actually go to build it for real, it'll be so much better.
00:10:36 ◼ ► Because it won't be my first attempt at it and I'm not gaining any technical debt while I'm doing this. It's all just throwaway code that if I never go, never goes anywhere, is totally fine.
00:10:47 ◼ ► That's really interesting. What you're describing, first of all, is delightful. Second of all, I think what you're describing is R&D. I think this is not necessarily something that is limited to single person teams.
00:11:03 ◼ ► I think single person teams are usually best at it, unless it takes really long term, if you're making some kind of really big bet, or doing a really big experiment, like say you want to design a car.
00:11:21 ◼ ► That's going to be something that an indie is going to have trouble doing that and you might need the resources of a big company to do something like that.
00:11:27 ◼ ► But I think for the most part, this is something that both indies and big companies can enjoy and it just comes with different mechanics and different pressures.
00:11:35 ◼ ► In the case of multi person teams, all the way up to big companies, I think it can be hard to justify the expenditure on this kind of thing.
00:11:45 ◼ ► I don't know if this is the reality, but this is also the myth of Google's 20% time. The idea is to take some portion of your work time and don't work on the official projects you're assigned to necessarily, or the stuff that you always work on.
00:12:06 ◼ ► But actually go out there and experiment and actually go out there and explore and try different things and explore new technologies or explore different ideas and feel that you have the freedom to do that.
00:12:18 ◼ ► And this is again, this is one of the things where in companies this is much easier said than done and in practice the pressures of working in a company usually prevent or at least highly discourage this kind of thing in practice, no matter what the leaders say, that's usually in practice, that doesn't really happen this way.
00:12:41 ◼ ► On the other hand, I feel like as an indie, you can also, as I often do, as we discussed last episode, if you feel the pressure that you are somehow not adequately keeping up with your main tasks, it can be really hard to ever make the time to explore or to experiment.
00:12:58 ◼ ► You know, I'm coming at this from the opposite angle right now. I have been in places like that where I've been experimenting, but I haven't been in one for some time because I've been bogged down by this giant modernization and rewrite of my ancient code base as I keep talking about.
00:13:13 ◼ ► And the problem with doing a big modernization or rewrite or refactoring is that you have almost no time to do anything new because you're spending a vast amount of effort trying to basically fix or recreate what you already had.
00:13:31 ◼ ► It's kind of the opposite of experimentation in the sense that there might be areas in which to experiment along the way, things like architecture patterns or different techniques or different styles that you're building the same components again, but you are still building the same components again at the end of the day.
00:13:49 ◼ ► So right now, all I'm doing is solving my problems that I've had for 10 years in a new way.
00:13:56 ◼ ► Oh, look, a list of episodes. Here's a list of your playlists and podcasts. I'm not covering new ground. I'm not exploring new areas, really. I have lots of ways to explore things at the lower levels.
00:14:09 ◼ ► I'm using a new database framework. I'm using a new language. I'm using a new UI framework. I'm doing all these different things, but none of those are really feature or app concept experimentation.
00:14:21 ◼ ► And I feel like that's an area that indies can have a hard time justifying that, just like big companies do, if we feel like we are behind or just barely getting enough things done on whatever "main" work is.
00:14:37 ◼ ► So whether it's the projects that make us money, the main app that we work on, and even a lot of indies, I think, have the same struggle with consulting versus their own projects, because a lot of indies start out being consultants for other people, because that can pay the bills as you're getting started and for a while afterwards.
00:14:56 ◼ ► And that can be your only business if you make it big enough. But it can be hard to justify when you're doing consulting work. Those are paid hours, and if you're doing exploration work, that's probably unpaid time for you.
00:15:08 ◼ ► And so it can be very hard to justify that even as an indie to be able to find that balance of, like, am I going to spend my time doing work that makes me money, even though it might be maybe a little bit boring to me?
00:15:19 ◼ ► Or am I going to spend some time exploring these new areas that might indirectly lead to money in the future, maybe, but probably won't lead to money this month?
00:15:30 ◼ ► And that can be a really hard struggle. And it's hard to find that balance, but I think it's, as with everything, what you need is a balance.
00:15:41 ◼ ► That you can't do only the boring work that pays 100% of the time, and you can't do only exploratory work that doesn't pay anything 100% of the time.
00:15:51 ◼ ► And it's useful to keep that in context of, like, you can't do 100% of either one. So don't feel bad doing the exploration work when it's time to do that, because otherwise you're going to go nuts.
00:16:03 ◼ ► We are brought to you this episode by Indeed. What's a game where no one wins? The waiting game. When it comes to hiring, don't wait for great talent to find you. Find them first with Indeed.
00:16:14 ◼ ► When you're hiring, you need Indeed. Indeed is the hiring platform where you can attract, interview, and hire all in one place.
00:16:22 ◼ ► Instead of spending hours on multiple job sites searching for candidates with the right skills, you can use Indeed's powerful hiring platform to help you do it all.
00:16:30 ◼ ► Indeed's powerful hiring platform streamlines hiring with tools that find you matched candidates. With Instant Match, over 80% of employers get quality candidates whose resumes on Indeed match their job description the moment they sponsor a job.
00:16:49 ◼ ► It gets you one step closer to the hire by immediately matching you with quality candidates instantly.
00:16:55 ◼ ► Even better, Indeed is the only job site where you only pay for applications that meet your must-have requirements, making it an unbelievably powerful hiring platform.
00:17:05 ◼ ► Indeed delivers four times more hires than all other job sites combined according to Talent Nest 2019.
00:17:12 ◼ ► So join more than 3 million businesses worldwide that use Indeed to hire great talent fast.
00:17:18 ◼ ► Start hiring now with a $75 sponsored job credit to upgrade your job post at Indeed.com/undertheradar.
00:17:32 ◼ ► That's Indeed spelled I-N-D-E-E-D dot com slash under the radar to support the show by saying you heard about it on this podcast.
00:17:47 ◼ ► Yeah, so I think it's very, very useful framing of the way I'm describing what I was doing and you know, very logically and accurately call it research and development.
00:17:57 ◼ ► And I think that is a great way to kind of think about it in a way that I think is illustrates, I think, how easy it is to not feel like you had time, energy or resources to do it.
00:18:08 ◼ ► That I think of when I think of research and development, I think of, you know, like these sort of big companies having a building off to the side that there's people in white coats doing, you know, these, you know, these very deep and long processes where they're doing research into some, you know, thing that never go that may or may not ever go anywhere or doing like basic science work where it's, you know, doing really fundamental analysis on something that is going to pay dividends way down the road, but doesn't have a lot of immediate value.
00:18:36 ◼ ► And I think as a developer, I would often think of it in that those, that kind of work is like, oh, I there's no way I could do that. Like that's, you know, that there was research and development projects that go on and on for years and years before they see any fruit.
00:18:47 ◼ ► And I think because of that, it's easy to sort of discount it and what you're saying, whereas the sense of it's easy to think of it is this work that I can afford to do because it's not actually moving directly towards the goal.
00:19:02 ◼ ► Right. It's not the actual working on the main feature branch of my app, building the feature that's going to be released in September. That's the actual thing that I'm trying to get to.
00:19:12 ◼ ► That is the thing that will ultimately bring income to my business and allow me to be sustainable and all of those those things.
00:19:17 ◼ ► And so it's easy to think, well, I need to get working on that right away. I need to build build something there.
00:19:23 ◼ ► But it's easy, I think, then to be missing out on the fact that that is well and true, but only if you're building towards the right thing that you want to.
00:19:32 ◼ ► It's like so much of this work that I do. I mean, there's that old term. It's like, oh, we're doing knowledge work. It's like, sure.
00:19:38 ◼ ► That's a you know, I'm talking about knowledge in a very different concept. But like so much of my work is about acquiring knowledge and understanding about how to do things.
00:19:47 ◼ ► And it is the knowledge that I gained through the research phase that allows me to build better versions of the thing that I'm ultimately trying to do.
00:19:56 ◼ ► And I think it's important to then recognize that these are two different phases, that these are different things and timebox them.
00:20:03 ◼ ► And like the way that my sort of summer is going is I have a natural break or I'll be going on a short holiday and coming up shortly.
00:20:11 ◼ ► And so it's like in my mind, it's like I have until then to do all my exploration, to do all my R&D. That's like that's my R&D budget that I can spend.
00:20:18 ◼ ► And then when I get back from that, then I have to do the actual work. That's when I actually need to make my iOS 17 branch and actually get really into the work that I need to do to actually ship something this September.
00:20:31 ◼ ► But if I hadn't spent this time, if I hadn't sort of had a research and development budget, and I think about if a week ago I'd started building features, I would have built really bad features.
00:20:46 ◼ ► It's I think just the simple way of looking at it. Like I know so much more now than I did then.
00:20:50 ◼ ► And if I'd been actually trying to do like production quality code from the beginning, I would never have been as quick and have learned as much as I have in the last week, not having that at the back of my mind.
00:21:06 ◼ ► That because I'm building throwaway code that I don't expect to go anywhere. That I'm cutting every corner I know how to cut.
00:21:11 ◼ ► That it's all hard coded values. Nothing's for real. Nothing's coming from a database. It's all smoke and mirrors, but it's useful smoke and mirrors.
00:21:20 ◼ ► It means that I've learned so much that now I can write better code. And that is such a tension that I think I would struggle with for years and like, "Oh, I feel like I'm wasting time."
00:21:29 ◼ ► But it's like for me anyway, I've found that it dramatically increases my speed and quality going forward if I've done a phase like this. And so like it pays for itself out.
00:21:41 ◼ ► And obviously if you, everyone's going to have a different ratio for that, that maybe you're just one of these magical unicorn coders who can write awesome code the first time without, you know, without having to write the wrong version four times first.
00:21:55 ◼ ► Like if that's you, awesome. But like that is not me. I have to write the wrong version many times before I actually will get there.
00:22:01 ◼ ► And this is something that I often will find kind of strange. Like recently I was having to pull some code out of WatchSmith, which is one of my oldest Swift projects.
00:22:10 ◼ ► That it was the first app that I ever wrote completely in Swift. And there's some code in there that I needed for a prototype I was building.
00:22:18 ◼ ► And it was like, what was I thinking? Like the way that I was using Swift, it's not even like, "Oh, this is old Swift idioms." It's just like, I didn't understand Swift. I didn't understand what it or what was happening.
00:22:29 ◼ ► And so as a result, like the code is weird and awkward and brittle and has all these issues and problems to it. And it's like, yeah, no, I would kind of wish that I had not done this as a production, you know, the production code that is shipping somewhere in the world right now.
00:22:42 ◼ ► Because when I look at it, it makes me real nervous for all the weird issues and edge cases that are going to spring up at some point.
00:22:49 ◼ ► And they probably have caused me pain and suffering since, but it's just such a dangerous place to be if you just don't really understand what it is you're doing, if it's not like the second or third time you've done it.
00:22:59 ◼ ► So it's like, I can just say from my experience, it is so valuable to give yourself that R&D budget, to give yourself the time to learn and improve, to gain knowledge, to reduce uncertainty. And then when you get to the actual work, it just flows.
00:23:14 ◼ ► It's not like it's going to flow in this perfect laminar waterfall, but it's going to be something where I have way fewer unknowns that I'm going to run into. There was an issue that I ran into yesterday where there's this weird app intent behavior that was just causing me so much suffering.
00:23:31 ◼ ► And then I got to this place where I worked it out. And it was so much easier to work out because the project where I was running it into had two files of code, and I could easily play with it and juggle it around. And I wasn't trying to diagnose this bug in the midst of this massive project.
00:23:47 ◼ ► It's definitely something that can pay so many dividends down the road that it pays for itself, but you have to give yourself the space to do it in order for it to pay you at all.
00:24:02 ◼ ► Yeah, that makes a lot of sense because every time I have looked back at my old stuff, too, I have the same problem. This week I was working in Overcast's regular Objective-C codebase that's ten years old. First of all, trying to write Objective-C now after not writing any of it in probably six months?
00:24:23 ◼ ► Oh, I was terrible at it. I kept making stupid mistakes and not putting the @ symbol in front of my string literals and forgetting my semicolons and not knowing what to do with braces around the if statements and everything. I was messing up everything.
00:24:35 ◼ ► And not putting the asterisk on my type names that are pointers. Oh my god, it was like newbie hour. But then I was looking through all my code, like, "Oh my god, why did I do it this way?"
00:24:48 ◼ ► I would do this so differently now, but that's just the nature of when time moves on, you get better, hopefully. And so when you look back at your old code, it's always going to look like crap.
00:25:00 ◼ ► And that, I think, favors the experimentation notion, as you were saying, because if you write something one way, if you try it, or if you have it the first way you did something, if you permit yourself to experiment and do it differently again, throw it away. Start over.
00:25:17 ◼ ► This, obviously, is something you have to be very careful with, because throwing away working code and doing rewrites can really be a massive time sink and can often be a terrible idea.
00:25:30 ◼ ► And yes, I've read the old Joltun software post, thank you. But also, doing a rewrite never is also the wrong idea.
00:25:41 ◼ ► Because on a long enough time scale, old code and old ideas and old ways of doing things hold you back. And believe me, I feel that more than anyone right now.
00:25:50 ◼ ► So I think you do have to allow yourself this experimentation time. You have to allow yourself time to rewrite things, time to consider different ideas, time to consider different features.
00:26:01 ◼ ► Even on the more experimental backpack gathering side, some of those random features or random ideas or random concepts that you try, some of those become killer features of your app, or become killer apps on their own.
00:26:15 ◼ ► And you're the master of this. Because you basically have built your entire career on trying lots of ideas and keeping the most open mind possible on what might become a product and not being afraid to let something become a product when it does.
00:26:36 ◼ ► Yeah, because I think on that side of things, it is so easy to prejudge the viability of an idea or of a feature ahead of time. To say, "Oh, that will never work," or "No one will care about that," or whatever that might be.
00:26:51 ◼ ► You can so easily prejudge something and think you know how it's going to go. But that cynicism is ultimately just so caustic to your ability to make productive, awesome apps.
00:27:06 ◼ ► Because you don't know what's going to be successful or interesting or technically complicated until you've actually tried it, until you've actually explored these things.
00:27:16 ◼ ► And think to your point, so many of the features as I'm designing WidgetSpit especially, I look at it and I can come up with a way that I think it would be used.
00:27:25 ◼ ► And then the next question I ask myself is, if I wanted to make this as flexible and as a sandbox for people to use and play with, what different choices would I make?
00:27:39 ◼ ► And what would I explore a bit what that would look like? Because so often that, rather than having this preconceived idea at the beginning that I'm building towards,
00:27:50 ◼ ► if instead I try and build towards a very wide and varied and dynamic solution to it, you can end up in a place where it's like, "Oh wow, this is actually way better," or "Oh wow, I've now created the ability for a user to do something that I didn't even imagine when I first started."
00:28:07 ◼ ► I mean, it's like, that makes me think of WidgetSmith. WidgetSmith didn't ship with photo widgets, like single photo widgets when it first launched. That didn't exist.
00:28:15 ◼ ► It is now like 85% of the widgets that have been created in WidgetSmith are single photo widgets. And the only reason that I was able to get into that situation is that I ended up, because I shipped photo album widgets,
00:28:28 ◼ ► which was a totally different kind of concept and technically very different and all these things. And the version of photo widgets I have now is something that I kind of hobbled together quickly because
00:28:38 ◼ ► clearly I had just enough of the feature in there that it became clear that it was a viable thing. But so often I feel like maybe just sort of to wrap this up is the thought of,
00:28:47 ◼ ► "My ability to be good at what I do is so benefited by all of the code that I've written in the past. And I keep it all these throwaway projects that I write, I keep."
00:28:59 ◼ ► The code in there isn't something that I want to ship any production. It's not production grade code, but it's production grade ideas. And it's production grade concepts and snippets and tiny bits of code that I can reuse and copy paste from
00:29:13 ◼ ► and then adapt and actually fill in all my error handling and actually fill in all of the bits and pieces that I need to in order to make it work. But it's like having this massive library that I can draw from of ideas and snippets of technical solutions.
00:29:27 ◼ ► That's what makes me powerful. That's why I can be faster in the future. And so I need to give myself the space to build up that library to not just explore one idea, but to explore 10, 20.