00:00:05 ◼ ► And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.
00:00:10 ◼ ► So we occasionally have a little bit of a lull in newsworthy topics or relevant topics that we haven't already covered.
00:00:16 ◼ ► This is one of those weeks where we decided to ask the listeners for basically some Q&A questions.
00:00:21 ◼ ► We did this once before and it was, I kept thinking it was recent, but it was back in 2016, so it wasn't that recent.
00:00:27 ◼ ► It was almost two years ago. We're going to go through, kind of have like a miscellaneous day, and let's see how it turns out.
00:00:35 ◼ ► I think we're going to leave, like I'll have a link in the show notes to the tweet that Marco sent out to ask for questions.
00:00:41 ◼ ► If you respond there, between now and next week we're going to take a look at the questions.
00:00:45 ◼ ► And if there's a lot of more great questions, we might do another round next week as well.
00:00:54 ◼ ► So the first question comes from Hakon Bogan, who asks, "Will React Native be the way forward for iOS development?"
00:01:07 ◼ ► The way I feel about things like React Native, and this is with the giant caveat that I have used almost none of these types of systems.
00:01:18 ◼ ► But it's really hard for anything that is not the official platform API, and the official platform way to build things, to really ever get like massive amounts of traction.
00:01:36 ◼ ► Like I would say, one case where a third party thing has totally taken over a platform is jQuery taking over JavaScript.
00:01:43 ◼ ► Like if you search the web for how to do something in JavaScript, 95% of the answers you're going to see are really how to do it in jQuery.
00:01:54 ◼ ► With iOS, it isn't that simple. You know, with iOS, even great ideas from third parties about how applications should be built, or what kind of frameworks or libraries they should be built on, are really hard to get traction.
00:02:06 ◼ ► Because iOS development is really big, and also Apple has a pretty strong first party point of view, and they keep moving it forward, and everyone's already using it and invested in it.
00:02:16 ◼ ► So it's really hard for anything like React or any other kind of alternative interface framework or method of programming to really take off unless Apple actually does something like that themselves, as the official first party API.
00:02:37 ◼ ► Like there are situations where they come into play, where if you are a company who needs to have a cross-platform application,
00:02:47 ◼ ► where tying directly to the native libraries directly is inconvenient for some reason. And usually what you hear is, "Well, we want to have an Android app and an iOS app, and we want to have some amount of more commonality between the two."
00:03:05 ◼ ► So if you move up into a library like this, you get the advantage of being a bit more portable in that way. Or you can certainly get into benefits around...
00:03:17 ◼ ► I know with a lot of React, it's a different way of programming, where it's more event-driven, I believe.
00:03:22 ◼ ► And you can think about your application in a different way, which certainly could be useful. It's certainly not diminishing that.
00:03:29 ◼ ► But I always struggle with these types of things because... Like in your example of jQuery, I think is a great one, where JavaScript isn't something where there is a platform owner who is intentionally and specifically driving things forward.
00:03:52 ◼ ► There isn't this single point of direction. In general, the community agreed that jQuery was a great baseline and adopted it as a result.
00:04:04 ◼ ► But what I struggle with with something like any of these types of things is, it means that I'm now dependent in two levels to the further direction from application.
00:04:17 ◼ ► Because every year, Apple is going to change the platform in some way, as we expect. And they're going to be pushing it in a certain direction.
00:04:25 ◼ ► And then now, I'm currently reliant on it. I'm under no illusions that I'm free from this, that I'm developing off of my own and not dependent on anyone else. I'm dependent on Apple.
00:04:37 ◼ ► But that one's unavoidable. If I also then time myself to be dependent on, in this case, React. So Apple makes a change. I have to then wait for React to make that change, and then I can start making my changes.
00:04:49 ◼ ► Or Apple pushes things in a different direction, and then suddenly I have to wait for these dominoes to fall before I can really make changes.
00:04:59 ◼ ► And that just always makes me nervous. Or if React just stops being worked on, and suddenly I'm in kind of a dead-end platform that I can't, for whatever reason, I can't update my application.
00:05:10 ◼ ► Or there's some weird toolchain problem, and suddenly I can't do these things. If Apple stops updating iOS, well, the platform is probably dead.
00:05:19 ◼ ► It's no longer a useful or interesting thing. But there are plenty of reasons why a third-party thing might not continue to be worked on and not be as viable.
00:05:28 ◼ ► And so for me, I find the risk of putting my codebase in this kind of tenuous place to not pay off the potential benefits, even though those potential benefits are real and tangible things.
00:05:39 ◼ ► It's never gotten to a place that it seems like it made sense to do, unless you have really compelling, specific reasons otherwise.
00:05:47 ◼ ► Alright, our next question comes from Rick Allen, who asked, "What is your approach to writing reusable and maintainable code? Had you decided whether something needs refactoring?"
00:05:58 ◼ ► He says he tends to write very focused code on the problem at hand, and sometimes ends up having duplicate code.
00:06:05 ◼ ► This is something for me that I try very hard to never copy and paste two files from one project into another, for instance.
00:06:16 ◼ ► Like I was just yesterday, I had a need for writing out a WAV file for a utility I'm writing on the Mac. Don't worry, it's nothing exciting.
00:06:27 ◼ ► And I already had WAV writing code for SideTrack, the private app that I use to sync up Double Ender podcast tracks.
00:06:39 ◼ ► And the needs were going to be very slightly different between the two. And I thought, you know, I could just copy this over, I could, you know, I could copy it over and modify it, but then I have two different files that are similar, but you know, not, but it's two different representations of the same function in two different files in two different projects that are almost the same.
00:06:59 ◼ ► And I was like, well then what if I find a bug in one and I fix it in that one, and I don't remember to fix it in the other one, like that's kind of, you know, inefficient and potentially bug prone for the future.
00:07:09 ◼ ► So what I usually do for reusable or reused code is just basically try to make a private library that I can then add as a Git submodule to both projects.
00:07:22 ◼ ► And so I host it on GitHub, I have its own separate project for these private libraries. I don't have a large number of these, I have maybe like five or six of them.
00:07:30 ◼ ► But you know, things like my iOS utilities library, some extra things on top of the iOS utilities that aren't really ready for public consumption but that I use as kind of like my private utilities.
00:07:42 ◼ ► My audio engine and different parts of my audio engine and different functions for audio engines, those are kind of all separated into a library, and so I'm able to share that code.
00:07:52 ◼ ► And my idea basically is like, if it's one library that I'm sharing as a Git submodule in all the projects that use it, then I, you know, any bug fixing in one benefits all of them.
00:08:06 ◼ ► And it's worth the slight overhead to make the code reusable and generalized to some degree.
00:08:12 ◼ ► It's worth that overhead to have that shared bug fixing and shared labor potential of doing that.
00:08:18 ◼ ► As for refactoring, I'm not a big refactorer. I still think that refactoring is largely a construct, it's largely a euphemism for rewriting in practice a lot.
00:08:32 ◼ ► I know that isn't officially what it means, but in practice I think refactoring often means I really just want to rewrite this because I'm a programmer and all programmers always want to rewrite everything that they come across.
00:08:43 ◼ ► But I know rewriting is a bad thing, so I'm gonna call it refactoring, even though I'm putting in enough work and making enough changes that I'm basically rewriting it.
00:08:53 ◼ ► So I have never found a good balance between refactoring and rewriting, and I'm not sure anyone else has either, but regardless I'm sure Casey will yell at us for this if he didn't yell at us already for the first answer about RxSwift.
00:09:07 ◼ ► But I don't really do refactoring. I will occasionally do a rewrite, but very occasionally, only when it's really necessary.
00:09:14 ◼ ► In some ways it's a funny thing to weight into, but I, as a general rule, don't worry too much about duplication between projects.
00:09:28 ◼ ► I don't have any shared libraries that I use between my various products, even though many of them have similar attributes to them.
00:09:38 ◼ ► Obviously a lot of them deal with, for example, the health framework. A lot of my apps read and write data from the health framework.
00:09:45 ◼ ► What I tend to do for my focus is around, I try and, in order to make my code very maintainable and very focused, I have certain patterns that I use across multiple applications.
00:09:59 ◼ ► In terms of the way that I structure my requests to health, for example, are very similar across apps. But in my experience, trying to make something work across multiple uses more often than not tends to make it more cumbersome to use.
00:10:20 ◼ ► Which often in a weird way makes it harder to maintain. Because you have the benefit in the sense of there's always the concept of, "Well, I find a bug, I can fix it, and then it's fixed for everybody."
00:10:33 ◼ ► Which is a great promise, but in practice I often found, when I used to do that kind of thing more specifically, is that also it creates another room for a new bug in all the dependent applications.
00:10:46 ◼ ► That they may have been relying on what you are now considering to be a bug from one application I'm working on. It reads the data, it gets it back, and it's like, "Oh, the way that it was doing it now is different."
00:11:02 ◼ ► "Oh, maybe this is a bug." I make a change. And I'm actually breaking other things, because these dependencies are much harder to remember about and plan for in that way, at least in my experience. You get a benefit in theory of having this cascading bug fix, but you also have the downside of the cascading uncertainty about what this change is going to do to anything that depends on it.
00:11:27 ◼ ► And so what I tend to do is try and write, I try and have similar patterns across my apps, but they're very focused on the problems and the things that they're trying to do.
00:11:37 ◼ ► And so I can build and learn from the past experience without necessarily needing to reuse that code specifically. And I found that works reasonably well.
00:11:48 ◼ ► I think on the refactoring side of things, I'm very much like you. If it isn't broken, I don't tend to go back in and change it. I find that it's far more likely that I'm going to introduce problems than that I'm actually going to solve things.
00:12:03 ◼ ► And I think refactoring's place probably comes in more into play when you get into a larger team organization than the situations where I have found refactoring to be a actually productive thing, is where you're trying to create and force uniformity across a code base, where it is written by five or six different people, that sometimes you might need to go back and refactor something, or rewrite it or change it,
00:12:32 ◼ ► to make it more in line with a broader code base. That is certainly something that I found productive, just from a uniformity perspective, but still, it's something that is very rare and very rarely actually useful, that I'd rather typically spend that time making the product, adding a new feature, making the product better, making it faster, doing those types of work,
00:12:54 ◼ ► than doing something that is primarily beneficial, ostensibly, for me, the developer. I'd rather put the focus on external things that customers are actually going to see and experience and feel.
00:13:06 ◼ ► Colin Weir asks, "What are some types of apps you could build that would help teach you some core concepts beyond just the typical Hello World example?" So, for instance, building a notes app would teach you X, Y, and Z.
00:13:18 ◼ ► So I think for this, I mean, this is a great question, if you're trying to learn and you're trying to learn something beyond Hello World, the number one answer really is try to build something that you are really motivated to make happen, that is also practical to achieve with your level of skill and time.
00:13:35 ◼ ► So, if you want to make the next AAA video game and you've never programmed before, this might be a problem for you, but you can do things that are more achievable. That being said, any real-world useful app that you pick to try to tackle,
00:13:51 ◼ ► first of all, if you're motivated to do it, that'll get you through the grind of learning. So that's how I think almost all programmers learn, is basically they want something to exist, so they kind of plow through until they make it exist.
00:14:02 ◼ ► But almost everything you pick besides Hello World is going to teach you a lot of different things, just by necessity. So, for instance, if you are trying to write a game, for instance, which is a lot of times people get into it when they're younger,
00:14:16 ◼ ► mostly because they want to create games first, and it's often people's first programs, like something in a basic little game, and making a game teaches you all sorts of crazy stuff.
00:14:25 ◼ ► You learn lots of things about 3D or 2D graphics, geometry, linear algebra, possibly if you're at those levels you might be learning about physics, even basic ballistic-type games, you're going to be dealing with physics on some level.
00:14:38 ◼ ► You're going to be dealing with textures and lighting and colors and menus and music and level design and trying to make things fun and difficulty curves.
00:14:48 ◼ ► Anything you do beyond Hello World I think will teach you different things. I would also say another major category of this would be dealing with user data.
00:14:58 ◼ ► Doing something where people are entering data where you are basically taking responsibility for it, which means that you have to care about things like data integrity, backups, restore.
00:15:11 ◼ ► You might at some point have to deal with sync, and then sync you have to deal with privacy. Any problem area you pick will naturally sprawl into tons of different areas.
00:15:26 ◼ ► There isn't one particular type of app that you should do after you learn the basics of Hello World. I would say just do the one you're motivated to. So much will just naturally flow from that, that as soon as you get to step one, steps two through five are going to become obvious to you.
00:15:45 ◼ ► Like, "Oh, now that I have this, now I should really add this, this, and this." And then the same way you learn how to do the first part, you can learn how to do the rest, just one by one.
00:15:54 ◼ ► Yeah, and I think too, there's something to be said for, it's like build something that actually does something. I think in some ways is inherent in this question is that doing these contrived examples that you often end up with in a programming book or something like that.
00:16:14 ◼ ► In my experience, it's far more interesting, I learn much more when I try and solve a real problem that I have in my life, that somebody I know would use, even if it's not an app that you expect to ship or make money from or any of those types of things.
00:16:27 ◼ ► But it's something that is practical, that you're solving an actual problem, you're not inventing a problem and then inventing a solution, I think is helpful.
00:16:36 ◼ ► Something I'd also say that is really useful is to think about what types of frameworks or areas of development you are most interested in and build an app to get used to doing that.
00:16:49 ◼ ► I've learned some of my best learning to buy just sort of like pick a framework that I don't have a lot of experience with and I just try and make some app that uses it.
00:16:59 ◼ ► And sometimes, for example, I've never shipped a photos app, but I've built and played with the photos frameworks just because I'm curious about how they work.
00:17:08 ◼ ► And there's something nice about sort of building an application that is focused on one framework or one area of iOS that lets you kind of, you can drill in and get deeper more quickly into a problem rather than trying to do something that touches on lots of different technologies and sort of integrates them.
00:17:28 ◼ ► That's a really interesting problem and honestly that's probably where down the road as you get more experience, that's where most of your sort of the value that you're going to be able to provide in your products is going to come from combining interesting technologies together.
00:17:43 ◼ ► But when you're learning, I find it's great to just focus on one technology and sort of dive into it and get good at it and kind of have that experience and you're able to get to something useful much more quickly that way.
00:17:56 ◼ ► Mike and Steven ask, "Who is sponsoring this episode?" Well, Mike and Steven, this episode is brought to you by Linode.
00:18:03 ◼ ► With Linode, you'll have access to a suite of powerful hosting options with prices starting at just $5 a month.
00:18:08 ◼ ► You can be up and running with your own virtual server in the Linode cloud in under a minute.
00:18:19 ◼ ► And I've been using Linode myself for, gee, something like eight years or maybe even more than that now.
00:18:24 ◼ ► It's been a long time. I've dealt with their support here and there and it's been wonderful.
00:18:35 ◼ ► I've probably been with at least 15 or 20 web hosts by now in my career and the control panels are usually awful.
00:18:46 ◼ ► There's lots of things you can do without filing a support ticket to try and wait for them to do it for you.
00:18:55 ◼ ► You can resize disk images. You can shut down the server, resize the disk, and it boots up and it just has more space.
00:19:02 ◼ ► You don't have to repartition. You don't lose any data. It's remarkable how good all this stuff is.
00:19:07 ◼ ► And of course they have lots of other wonderful features that won't even fit in this ad read.
00:19:20 ◼ ► And they also now offer high memory plans that prioritize RAM over the other resources if you need that.
00:19:28 ◼ ► So our listeners can sign up at linode.com/radar to support us and get $20 towards any Linode plan.
00:19:40 ◼ ► So go to linode.com/radar to learn more, sign up and take advantage of that $20 credit,
00:19:52 ◼ ► Chris Stirner asks, "Any tips to mastering the art of packing for conferences or travel trips like _DavidSmith?"
00:20:02 ◼ ► This is in reference to the recent discussion on ATP we had last week or the week before about packing cubes and backpacks.
00:20:12 ◼ ► Like whenever we travel and you're there, you have basically like a handbag-sized backpack,
00:20:39 ◼ ► So you can fit, like, in the space that a 17-inch MacBook Pro would not fit, you fit like a week's worth of everything you need.
00:20:58 ◼ ► And I think, first, it's probably the best place to start, I think, is if someone wants to pack light,
00:21:05 ◼ ► And first, it's just to say, there is something just delightful when you're traveling to have less things with you.
00:21:33 ◼ ► And so, minimizing the amount of stuff that I take on when I'm traveling or when I'm doing trips is just useful in that way.
00:21:40 ◼ ► And so, once you get used to it, it's really kind of hard to go back to the world where you pack lots of stuff,
00:21:50 ◼ ► Once you can wrap your head around, well, I don't actually need nearly as much stuff as I think I do when I go on trips,
00:22:01 ◼ ► And I think, for me, the technique and the approach I take is coming from a backpacking background.
00:22:21 ◼ ► where you are literally taking everything that you will have with you for the entire trip,
00:22:25 ◼ ► putting it on your back, and then carrying it for 10 miles a day, 20 miles a day, whatever it is you're doing,
00:22:32 ◼ ► you very quickly start to wonder, "Do I really need this? Is this really something that I want to carry with me up this mountain?"
00:22:47 ◼ ► is something that I started doing that I think is a really just good discipline in general for packing
00:22:57 ◼ ► take all of the things that you didn't actually need or wear or you brought with you just in case,
00:23:07 ◼ ► And you start to very quickly see trends if you do this over a course of a couple of trips.
00:23:13 ◼ ► You'll start to see that, "Man, I always bring three pairs of jeans, and I only end up wearing two.
00:23:19 ◼ ► Why am I bringing the third pair?" Or, "I always feel like I'm going to need this thing, and I never actually do."
00:23:29 ◼ ► "Well, I'm going to have everything I could ever possibly ever need, and I'm going to cover all my bases,
00:23:40 ◼ ► But that preparedness is coming at the expense of having to then carry this with you everywhere you go,
00:23:54 ◼ ► almost everything you could ever need can be purchased with a credit card at very short notice.
00:23:59 ◼ ► That's just life. If you're in the United States, there's probably always going to be a Target or a Walmart
00:24:09 ◼ ► And in general, that really actually happens. If you are thoughtful about what it is that you're going to take with you,
00:24:14 ◼ ► you don't need nearly as much as you think. And so on the first side, it's like, reduce what you're going to bring.
00:24:19 ◼ ► In terms of actually packing it into a small case, the biggest thing I find there is to just pack,
00:24:31 ◼ ► It's sort of like, I think it's Parkinson's Law, or one of these software development overarching laws,
00:24:41 ◼ ► which is, work expands to fill the time allocated. So if your boss gives you two weeks to finish something,
00:24:47 ◼ ► it'll take two weeks. If your boss gave you the same amount of work and said you had to do it in a week and a half,
00:24:52 ◼ ► somehow magically you could do it in a week and a half. Everything tends to expand to fill the space available.
00:24:59 ◼ ► And so when you're packing, give yourself a smaller bag and you will naturally find your way to make it work.
00:25:07 ◼ ► And that's just something that I think is useful. I have a nice backpack that is good for this kind of thing,
00:25:14 ◼ ► it's very space efficient, it doesn't have a lot of wasted space inside of it, but by limiting myself to that,
00:25:23 ◼ ► you are forced to make more specific choices. In some ways I love and I hate when I have to take a big Czech suitcase
00:25:30 ◼ ► because I'm bringing something else with me that I can't fit into a smaller bag. It's great insofar as it's like,
00:25:37 ◼ ► "Now I don't have to make these choices." But it's bad in the sense that I end up bringing way more stuff than I actually need,
00:25:42 ◼ ► and it ends up just being a big waste of effort. So that's the approach I take. Packing cubes are awesome,
00:25:50 ◼ ► I really like them. I know they're somewhat controversial, some people love them, some people don't.
00:25:54 ◼ ► I've found that they are just very useful for just organizing the things that you have. Almost every suitcase is just one big cavern,
00:26:03 ◼ ► and then tends to have a bunch of small pockets on the sides. Most people love having little pockets in the backpack
00:26:11 ◼ ► that they use on a day-to-day basis because it's useful to organize and partition your stuff, and to be able to remember
00:26:16 ◼ ► where something is, and to be able to take one thing out without having to mess up everything else.
00:26:21 ◼ ► Packing cubes are great for that. If you just need a fresh pair of socks, you can just take the sock cube out,
00:26:29 ◼ ► and you don't need to rustle through all your nice shirts and mess everything up in order to do that.
00:26:37 ◼ ► I highly recommend packing cubes. Otherwise, that's the approach I take. If you go down this road, then apparently everyone thinks it's really weird,
00:26:46 ◼ ► and pokes fun at you about it, but you're the last laugh because you're not tired from carrying around heavy suitcases.
00:26:53 ◼ ► When we poke fun at you, it's more out of just amazement. How did he do that? How did you fit everything you have?
00:27:07 ◼ ► The thing that's funny is I think people often imagine things need to take more space than they actually do, or you can get away with having less stuff.
00:27:18 ◼ ► It's not that I'm taking less stuff to take less stuff. The point is not to have a very small backpack.
00:27:26 ◼ ► It's not to have the things that I need, but it's to bring only the essentials and to bring only the things that I need.
00:27:34 ◼ ► It seems impossible until you try. Like I said, I think the best place to start for anyone who wants to pack less is to, every time you don't use something on a trip,
00:27:49 ◼ ► Then the next time you're packing, maybe you'll be slightly more reluctant to take it with you. Ten years of doing that, and pretty quickly you take a lot less stuff.
00:27:58 ◼ ► To bring this back around to software development a little bit, just to tie it up, a similar experience I had that I think is also a worthwhile thing to think through is,
00:28:07 ◼ ► for years I always brought a big 15-inch laptop with me everywhere I went, because I was like, "Oh, what if on the road a server's going to go down?"
00:28:22 ◼ ► More recently, I've even gotten to the point where I realized I can set up my phone to do 99% of the things that I would ever need to do on an emergency basis.
00:28:46 ◼ ► I'm sure I can find a Mac somewhere for this incredibly unlikely event that I've never actually happened in 10 years of being a professional developer.
00:28:56 ◼ ► I don't think this is really going to happen, and if it did, my source code is available to me when I'm traveling through various means,
00:29:09 ◼ ► In the same way, scale down the things that you are thinking that you're taking with you, and just be thoughtful about it.
00:29:16 ◼ ► Actually do it, and reboot a machine from your phone to actually prove to yourself that you can do it before you rely on doing that.
00:29:26 ◼ ► I love that you've reached the point where a laptop that can fit in your jacket pocket is too big.
00:29:33 ◼ ► It's too big. Way too big. It's so much bigger than an iPhone. If you see iPhones, they're so, so, so small.