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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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: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.
00:29:38 ◼ ► And then I have 20 different ideas and snippets that I can draw from. And that is the accelerant. That's the thing that makes it work for me. And that's the thing that makes it super powerful.