0:00:00Welcome to Under the Radar, the show about independent iOS app development.
0:00:04I'm Marco Arment.
0:00:05And I'm David Smith.
0:00:06Under the Radar is never longer than 30 minutes, so let's get started.
0:00:10So we decided to ask our audience on Twitter a little bit ago what we should talk about
0:00:14this week, because you know, in the summertime there's not a whole lot of news that happens
0:00:17in the tech world usually.
0:00:19And so we decided this week to do something a little bit different.
0:00:22We're going to have kind of like a lightning round of listener Q&A and basically pick a
0:00:27lot of the tweet responses that we got and try to answer them in, you know, because like
0:00:32a lot of these things are not things that we can talk about for a whole episode.
0:00:35We just don't have enough to say on these issues to fill a half hour, but we might have
0:00:39enough to say on them to fill a few minutes.
0:00:41So we're going to basically pick as many, just see how many we can get through in a
0:00:44half hour and see what happens from that.
0:00:47So Dave, you want to get started?
0:00:49Sure.
0:00:50So the first question that I was going to answer is I got a question from Jordy Bruin,
0:00:56who asked about project setup when you are first starting new things.
0:01:00And as somebody who starts a lot of new things a lot, I have a lot of experience with this.
0:01:06And I've done a lot of different things.
0:01:08I think where I'm going to take his question, with a lot of these, you could be asking a
0:01:13different question than we're actually going to answer.
0:01:15And if that's the case, sorry, but that's the way this is just necessarily going to
0:01:19work.
0:01:20So I'm imagining sort of like when you hit new project, how do you actually set up that
0:01:25initial Xcode project before you start coding?
0:01:27And I've done a lot of things over the years.
0:01:29I've tried all the different templates.
0:01:31Like when you go into Xcode and it has, you know, would you like this to be a tab application?
0:01:35Would you like it to be a master detail view?
0:01:39There's all kinds of things that you can do.
0:01:40You don't want to set it up for core data or not or all of these other sort of templates
0:01:45into this stuff.
0:01:47I've tried all of those in the past.
0:01:48I've always found that at a certain point it starts to get really messy if I go check
0:01:53too many of those boxes.
0:01:55And so at this point I would say what I do is I just do the smallest one possible.
0:01:59So I do a single view application.
0:02:01I don't check any of the core data.
0:02:05Even though I use core data, I'll go in and add all of those things later.
0:02:10And I find that works a lot better.
0:02:11So sometimes I'll make a throwaway project to see how the template would have set something
0:02:16up.
0:02:17So if I'm curious if they've changed their core data stack or the way they recommend
0:02:19it or I'll look at it, but when it's as empty of a project as it can be and I'll go into
0:02:26my app delegate, I'll instantiate my root view controller, and I'll present it.
0:02:32And I find that doing it that way, what I love is I know every part of the application
0:02:37from the absolute, from the bottom up, is something that I understand and something
0:02:41I know is working.
0:02:42And so I don't have any of these weird surprises that I find if I set it up using one of the
0:02:47Xcode templates.
0:02:48Cool.
0:02:49Yeah, that's pretty, I have nothing to add to that because I start a new project every
0:02:52three years.
0:02:53So it takes a long time.
0:02:55I always forget what I've done last time and I just kind of wing it and kind of plow through.
0:03:00Your way sounds a lot better than my way.
0:03:01There you go.
0:03:02All right, our next topic comes to us from Sjoerd Janssen, who asks, "How do you know
0:03:07when an update is finished and can't be polished anymore?"
0:03:10I'm struggling with that with myself now.
0:03:12So this happens to every developer I know where you have an update or even your 1.0
0:03:18to your app and you could just keep making it better and adding a little thing here or
0:03:22there.
0:03:23Oh, you know, I could throw in one more thing.
0:03:24I could throw in one more feature.
0:03:25I could make this thing a little bit better.
0:03:26I could redesign this one screen or this one element.
0:03:28And when do you actually just say, all right, enough is enough, I have to ship it?
0:03:32And for me, I've kind of gone through different parts of this myself in my own experience.
0:03:37I've kind of gone a different end of the spectrum here.
0:03:40But ultimately, I think it's better to err on the side of more frequent updates rather
0:03:45than fewer larger updates.
0:03:48You know, we actually talked a little bit about this a while ago about marketing where
0:03:53you can hold back a bunch of features to release all at once as a marketing strategy to try
0:03:59to make one major update that will be newsworthy enough for maybe some blogs to cover.
0:04:04But in practice, that's not most updates.
0:04:06And the value of that itself is also kind of questionable.
0:04:10It varies as to whether that's even worth doing, whether it actually works that way
0:04:13or not.
0:04:14But in general, I err now on the side of just release things as they get done.
0:04:19And that tends to work better for me.
0:04:22How about you?
0:04:23Yeah, I would agree that in general, the thing that I've learned most after doing lots of
0:04:29updates is that the things that I think are important or interesting are very often not
0:04:33the things that are important and interesting to my users.
0:04:38And so the sooner that I can get it in front of people and get their reactions to it, the
0:04:43better.
0:04:44The number of times I've like, I mean, I know this, I understand exactly that phase that
0:04:48he's talking about.
0:04:49Sort of you're like, "Oh, what if I did this?
0:04:50What if I did that?
0:04:51What if I did this?"
0:04:52And you can keep doing that forever.
0:04:54Like there is no, you will never reach a point where you're like, "Done.
0:04:58This is perfect.
0:04:59Ship it."
0:05:00You have to always be sort of forcing yourself to cut it off.
0:05:04And I think the more disciplined you can be to bite off small things, get them good and
0:05:09solid, ship them and get reactions, the better your app will be much more quickly.
0:05:14And sometimes when you avoid, probably more importantly, you avoid the situation where
0:05:19you go down this rabbit hole, you build this like crazy new thing that no one uses or isn't
0:05:24important to the app or actually makes the app worse because you're doing it in a way
0:05:29that people aren't actually using your application for.
0:05:33Exactly.
0:05:34So the next one I wanted to react to is a question we got from Rob Farney who asked
0:05:41essentially about the way we do UI layouts.
0:05:43So do we code them?
0:05:44Do we use Interface Builder or do we use a combination or libraries and auto layout and
0:05:49all those kinds of things?
0:05:51And so I think I have a slightly strange view on this, at least compared to a lot of people.
0:05:57I've never really met someone else who does it the way that I do it, but this just works
0:06:00for the way my brain is.
0:06:01So I do all of my layout in code for the most part.
0:06:05I'll have a few Interface Builder files.
0:06:07Usually those are for things like setting screens or kind of one-off views that aren't
0:06:12dynamic or interesting.
0:06:13They're just kind of like a little corner of the application that I don't want to do
0:06:18in code, but usually I'll just write them in code.
0:06:20I do all my layout in code as well.
0:06:25I don't use auto layout.
0:06:26I instead do dynamic and interesting layout things, but I do it all in layout subviews
0:06:34or equivalent methods in either the view controller or the view, depending on what it is.
0:06:38So every time a view's frame updates, I'll go through and update the frames of all of
0:06:44its subviews appropriately, which is essentially what auto layout does.
0:06:48But I do it in a way that for me I can understand, that I can write clearer declarative code
0:06:57that says I want this to be at this percentage of this thing, and I could do that in auto
0:07:02layout and maybe I would get some benefits.
0:07:03But every time I've gone down that road of taking my layout and putting it into something
0:07:09else, whether that's Interface Builder, whether it's auto layout, whenever there's some kind
0:07:12of magic that's happening somewhere else, in my experience it comes back to bite me
0:07:19eventually.
0:07:20There's going to be weird edge cases or problems or things that just mean that I would rather
0:07:26just do it in code.
0:07:27It's not for everybody.
0:07:28You have to kind of be good at imagining a layout in your brain without seeing it in
0:07:36front of you.
0:07:37So if you can't do that, then this approach doesn't work, but that's what I do.
0:07:41And a random pro tip for any kind of UI layout things is that every UI view has a layer,
0:07:47and every layer can have a border width.
0:07:49And so one of the biggest tools I ever use for fixing and debugging problems with my
0:07:56layouts is taking whatever UI view I'm working with and I say view.layer.border width equals
0:08:021, which just adds a little black line around it, which makes it incredibly easy to see
0:08:07where things are actually laid out on your screen.
0:08:10>> Black?
0:08:11That's so boring.
0:08:12You should be using FOF, the bright pink ugly color that nobody ever uses in reality, so
0:08:16you always know that's what you're looking for.
0:08:18>> It's true.
0:08:19But then I would need two lines of code rather than just one.
0:08:21>> That's true.
0:08:22All right.
0:08:23Yeah, I actually have a pretty similar answer to that question where I do occasionally use
0:08:28interface builder for something, but it's rare.
0:08:32I prefer to do things in code.
0:08:34Now I actually do use auto layout more than just like a view will layout sub views kind
0:08:38of thing where I will use constraints and constraint language, but I do it through the
0:08:45library that I have open source called compact constraint and it's basically a kind of shortcut
0:08:51CSS looking kind of language for declaring constraints manually.
0:08:56And I use a combination of that along with the, what's it called, the visual format language,
0:09:01the kind of ASCII language of constraints.
0:09:03>> Like the ASCII art thing?
0:09:04I don't know what it's called.
0:09:05>> Yeah, I believe it's the, I think it's called visual format language.
0:09:08>> Okay.
0:09:09>> I use a combination of those two things.
0:09:11So basically my layouts end up, you know, there is a code, there is a function somewhere,
0:09:16maybe it is view will layout sub views or awake from nip or whatever.
0:09:20There's a view somewhere in my code there is a section where for every view I have listed
0:09:26like here's all the constraints for when you create this view.
0:09:29And it looks kind of like CSS and it makes it very easy to see what's going on and to
0:09:34change what's going on.
0:09:35And one of the reasons I do it this way and one of the things I don't really care for
0:09:39about using Interface Builder is when you're using Interface Builder to do things, it's
0:09:44often difficult to at a glance see what are all of the rules and all of the property changes
0:09:51from default that I'm applying to this object.
0:09:54You know, with Interface Builder a lot of times these things are buried in check boxes
0:09:57somewhere or like little value changes deep down somewhere that like you might miss if
0:10:01you're glancing at the file.
0:10:04Whereas if you do the layout and customization of properties all in code, you can see it
0:10:08all right there.
0:10:09You can see everything you're doing to this view or to this window or whatever the case
0:10:13may be and it makes it a lot easier to find and fix problems and a lot easier to figure
0:10:17out like oh what's going on here, like why is this thing bold or whatever.
0:10:20You can see it all in one place and that's something that you can just never get really
0:10:24in Interface Builder.
0:10:26All right, my next question comes from William Robinson asking failure, putting an app out
0:10:33and nobody caring/downloading.
0:10:35So basically what happens if your app just doesn't go anywhere?
0:10:38This is heartbreaking.
0:10:40It happens though, it happens to everybody.
0:10:42You know, ultimately what if it starts going somewhere and then stops and then you know
0:10:46eventually sales reach negligible levels.
0:10:49This has happened to a number of my apps because again this happens to everybody and you know
0:10:53one of the clearest ones was Bugshot where it just kind of shot up, you know made a couple
0:10:58thousand dollars in the first few months and then just kind of went down to nothing and
0:11:01was making like a dollar a day for a while at best.
0:11:05And you know that's, when that happens you kind of have to face reality and it's a little
0:11:10hard to judge like okay well if I put a lot more effort into like a 2.0 maybe I can like
0:11:17save this or rescue this.
0:11:19Usually that's not the right move.
0:11:21Usually you can't save or rescue it.
0:11:23Usually the market is telling you something.
0:11:24The market is telling you either, you know either we don't need this or we are satisfied
0:11:30by other solutions to this problem enough that yours isn't necessary.
0:11:35And you know you could change things about it like you know you could change the price
0:11:40maybe you could you know again you could release a 2.0 but usually if something has failed
0:11:44in the marketplace enough that you need to face this reality, chances are any of those
0:11:49changes you would make to it would not be enough to turn what is clearly a failure into
0:11:54a success.
0:11:56You might eke a little bit more time out of it, a little bit more money out of it maybe
0:12:00but probably not.
0:12:01Chances are you know recognize your, recognize failures early enough and then just move on
0:12:07if you can.
0:12:08That's usually a better use of the time than like you know shoving more time and effort
0:12:13into an app that has already failed in the market.
0:12:16Yes and I've failed a lot.
0:12:20Like the experiences you're describing is something that I've experienced many times.
0:12:23I've launched a lot of apps and I've had many of them that go out and either have the thing
0:12:29you describe with Bugshot where it's like it goes up and then just like falls flat or
0:12:33even I've just had it never go anywhere.
0:12:36Like you just never know and the biggest thing I suppose is to understand that it is not
0:12:44like the ultimate, the ultimate product that I am building throughout my career is myself.
0:12:53Like what I want is to at the end of the sort of have each project of everything of each
0:12:58thing that I build make me a better developer, make me more able to make better and more
0:13:03awesome you know products and things down the road.
0:13:07Because tastes will change, platforms will change, like all of those things are always
0:13:12going to be very, you know evolve over time and no one product is going to last forever.
0:13:17You know my business has been based on products in the past that now do kind of terrible but
0:13:23that was fine.
0:13:24They had their moment and sometimes you know you never are going to know exactly what's
0:13:27going to happen.
0:13:28And so whenever you have failures I think the most constructive way to look at it is
0:13:31to say what can I learn from this?
0:13:35How can this experience make me a better developer?
0:13:38And then take that experience and just pour it into your next thing.
0:13:43Because as long as you are getting better each time then you're being successful.
0:13:48Like you are meeting the core goal and while that's nice when it's you know you hit on
0:13:52a product that is successful and really just takes off and like that's awesome you know
0:13:57I'm just really not diminishing that.
0:14:00But making sure that you always keep it respected that like the individual product is not you.
0:14:04You know you trying to have some distance from what you create is really helpful and
0:14:08keeping the focus on what can I learn and now let's go work on the next thing and not
0:14:13get too stuck on it.
0:14:14All right we are sponsored this week by Braintree.
0:14:18Learn more at BraintreePayments.com/Radar.
0:14:21Why make payment integration more difficult than it has to be?
0:14:24Braintree's powerful full stack payment platform allows you to accept nearly any type of payment
0:14:29from any device with just one integration.
0:14:32It's flexible to your system's needs and supports most programming languages.
0:14:36Whether you're using Java, God I hope not you have my sympathy, Java, Ruby or Python
0:14:41you always have a range of server side and client side SDKs available.
0:14:45The Braintree code supports Android, iOS and JavaScript clients and it takes just 10 lines
0:14:50of code to implement.
0:14:52Braintree makes payments and your job a whole lot easier.
0:14:54Learn more at BraintreePayments.com/Radar.
0:14:58Thanks a lot to Braintree for sponsoring our show.
0:15:00Okay so the next question I wanted to address is from Hip Tomcat and he's asking about
0:15:07architectural patterns like MVVM, MVC, coordinators.
0:15:10I've had a few kind of questions about this like the all of these things do kind of I
0:15:16don't I don't go and maybe my answer will probably point out that I don't go down the
0:15:21road of paying too much attention to a lot of these things like there's a lot of things
0:15:25that I keep hearing about where people are talking about like new patterns or sometimes
0:15:28there are new structures or approaches to apps or like and I see that and I look at
0:15:34it and I the thing that I always worry about whenever I see people who get really wrapped
0:15:39around patterns and this goes back to like back in my old Java days where the like design
0:15:46patterns thing was a big like there was like a big fad where it was that was the whole
0:15:50thing everything had to be a factory or an observer.
0:15:54And the important thing I always try and keep in mind and get him and like when I get this
0:15:58kind of people ask me this kind of question is making sure that you're writing code that
0:16:03a you can understand and not that you understand like at a vague level how it works but you
0:16:09can under you understand why it's structured the way it is like the worst implementations
0:16:14of it whenever was back when I used to do consulting read come in to a project and try
0:16:20to try and work out how they're doing something and you kind of clearly get the sense that
0:16:24they're using a design pattern because they feel like they should but they don't really
0:16:29understand what that design patterns intent or purpose was and so it's just a mess.
0:16:35So if you're ever going to use a pattern you have it should be this thing that's like well
0:16:39I you know this is the best way to do it I completely understand the trade-offs on both
0:16:43sides of this and for me and the way that I think about this problem this will work
0:16:47really well and if one of these approaches works great that having view models or coordinators
0:16:53or whatever it is like that that fits with the way your brain works then awesome that's
0:16:58great but definitely never feel like you have to go down the road of adopting some pattern
0:17:03because it's sort of hip and trendy because the nature of hip and trendy is that it will
0:17:07change and it isn't necessarily changing because we've somehow like had this breakthrough discovery
0:17:13and now it's like turned the world of software development over time like there's an element
0:17:18of it that is just trendy and so find what works for you and make sure that you can if
0:17:23you can understand your code and it's understandable you're gonna have far fewer bugs then the
0:17:28thing where it's like oh well theoretically if I use this thing and I completely abstract
0:17:31all of my logic away down the road it'll make it easier and I'll have great encapsulation
0:17:36and my bugs will go down because I can you know test all my interfaces and that's great
0:17:40that's probably true at a certain point but the actual like developer sitting at the keyboard
0:17:45has to understand what's going on and if you can do that then great like for me most of
0:17:50my architectural patterns in my apps are structured around like singletons and managers I guess
0:17:55I call them that's the way most of my apps all my app logic is kind of broken up into
0:18:00you know I have a whole bunch of singletons that handle a bunch of different like have
0:18:05a particular domain so like I have a singleton that handles all my stuff with health and
0:18:09dealing with health kit or dealing with core data or doing networking and for me that works
0:18:15like I can I know we're all like all the problems with that like there's certainly issues with
0:18:19singletons and coupling and like I understand those downsides but for me it works great
0:18:24and I understand it and I know how not to do it wrong and so that's what I do and I
0:18:29try not to be too distracted whenever there's like some hip new thing that's come out and
0:18:33you know it's like you have the problem of you see a talk say at a conference or something
0:18:37or blog post and someone's like hey we did this thing and it worked great for us and
0:18:42you immediately can try and extend that to say like hey they did this cool thing and
0:18:47it will work great for me when if you really you have to have a much more deep understanding
0:18:52of what that thing is and what its benefits are before you can ever make that kind of
0:18:56a judgment.
0:18:57Yeah I pretty much agree with everything you said I also develop with a lot of singletons
0:19:02and things I also don't use a lot of design patterns or at least like I never read the
0:19:07Gang of Four book and so maybe I'm using them without even realizing I'm using them but
0:19:12I never really got into that side of software architecture of like really obsessing over
0:19:18that kind of thing because in the scale that I'm typically working at with you know a one
0:19:23person team that kind of stuff tends not to matter as much as it would maybe on a larger
0:19:29team and I'm working on pretty simple things and also like you know I just tend to follow
0:19:33the conventions of the system I'm in so like I'm very familiar with the way Apple does
0:19:37things with the cocoa API's and the way they're structured and kind of the patterns that they
0:19:41encourage and that they use themselves and I try to structure the rest of my app that
0:19:45way to kind of mesh well and kind of mimic the structure of the cocoa API's beyond that
0:19:52I don't really do any kind of other fancy structure.
0:19:55Alright next I wanted to bring up a question from Luke Allen who's asking about the viability
0:20:00and landscape for new indie developers to break into the iOS and Mac marketplace in
0:20:052016.
0:20:06Now this is obviously a big and kind of broad and kind of squishy feelings question so it's
0:20:11a little hard to answer like you know can new indies break in now?
0:20:15To me I think all you have to do to answer this question is to take a look at your phone
0:20:20home screen and what apps are on it today and then think back or if you have old screenshots
0:20:26even better look back at what your home screen looked like three years ago and how many of
0:20:31the apps that you're using today were out three years ago?
0:20:35I bet it's not that many you know ruling out like Apple's built in apps or anything which
0:20:40even they have changed quite a bit but the fact is that yes this is a large and saturated
0:20:46and old market however there's always churn in every software market there's always room
0:20:52for something new and it isn't always easy to break in but there's always a spot somewhere
0:20:58in the market like you know simple things like that you think would be very very crowded
0:21:02like notes and weather apps like you know we bring up these examples a lot.
0:21:06I mean there's always a market for a new notes or weather app if you can do something a little
0:21:11bit differently some people will like yours some people won't and that's okay there's
0:21:16room it's a very very big market lots of people use it not everybody wants the same things
0:21:21out of every app and a lot of times people just kind of get tired of what they're using
0:21:24and just want to look at something new so there's always room it is getting harder to
0:21:29find that room and there's more people vying for it however there is always room for new
0:21:34things to bring into the market.
0:21:36Yes and I think the key thing when you're if I was if I was a new indie trying to like
0:21:42sort of if I decided one day that that was what I wanted to do I want to be an independent
0:21:46software developer I would be very careful about a like my check my motivations make
0:21:54sure I'm doing it for the right reasons and like understand how terrible of a job it is
0:21:58and not just sort of get which I can say a bit jokingly but quite honestly as well like
0:22:05it is not the it is it is not like a glamorous lifestyle being an indie software developer
0:22:11that there's only some upsides of being your own boss and being able to work on things
0:22:15that you think are cool but there's a lot of really not so great things some things
0:22:20that you give up from working for a corporate job or in a consulting job so you know you
0:22:25there's definitely some trade-offs make sure you're doing for the right reason and then
0:22:28making sure that you're having realistic expectations about what you are hoping to accomplish you
0:22:36know is it that your goal is to have in you know just have a side income from your bit
0:22:41from your indie work is going to be your entire income and understand that those different
0:22:47levels are going to require different amounts different amounts of time and luck and effort
0:22:54and be careful about what you're going after you know like sort of like you said like some
0:22:58apps there's a natural trendiness to them and so it makes sense to get into something
0:23:05and you know be someone that somewhere there's a lot is a lot of churn like a weather app
0:23:10is and they sort of comes to mind as something where there's a there's this natural like
0:23:14I don't know everyone just thinks of something differently and so you can have a unique take
0:23:18on something and that has has an opportunity to be successful and I'd also say be really
0:23:24careful about taking on projects that are very complicated to start with like you either
0:23:32need to be have some if you have some like really deep and interesting new approach to
0:23:37something like I think of someone like Chris Lissio with all of his audio processing stuff
0:23:42that he does like he has made a business of making software because of a really specific
0:23:52skill set that he has that he really is good at audio processing and so he can make a business
0:23:57because not a lot of people can do that and so if you have a skill like that like run
0:24:00with that if you have some background knowledge or some domain expertise like go for that
0:24:04and pursue it but if you don't don't get sucked into the trap of trying to like build this
0:24:10grand big very like it's just like this existing thing but like way bigger and more complicated
0:24:15and better yeah that never works like that's gonna really come back to bite you especially
0:24:19if it's just involved like oh it's gonna have data syncing and it's gonna have all this
0:24:21other stuff and like that would be something I'd stay away from and especially to start
0:24:25with like start simple start with something you enjoy something that if you made the app
0:24:30that no one downloaded it but you had it and could use it every day that you would be happy
0:24:34and that's probably a good place to start all right the next question I wanted to address
0:24:39is from Phil Curry who's asking about unit testing for the one-man shop is it worthwhile
0:24:45and if so where to start so unit testing is a I would say is an academic topic for me
0:24:53as it is something that I have never done so I can speak to it only in the theoretical
0:25:00rather than in the practical experience type unit testing is something that well I have
0:25:06used it in the past like in different projects but not never by Mandy work and I would say
0:25:12unit testing in my experience is useful for one of two reasons it's either useful because
0:25:20the cost of messing something up is very high so if you know if you're someone who's writing
0:25:29software that you know is used to control a plane is flying through the air you need
0:25:36some unit testing like you need some serious you know quality assurance kind of process
0:25:40because if you mess up that really like like genuinely bad things can happen not just like
0:25:46bad things like my server went down for a few hours like you know life and death kind
0:25:50of situation so if you're if you're in a situation where the cost of having him having a bug
0:25:55having a mistake is truly you know significant absolutely and the other situation where in
0:26:02my experience unit testing is helpful is I know like there are some developers I've worked
0:26:07with over the years for whom like developer unit testing is the way they think of development
0:26:12that they create you know sort of like the test driven development approach of saying
0:26:15like here's this problem I'm going to code a test that will you know be will pass once
0:26:23I've solved that problem and then they go and solve the problem and it's just like a
0:26:28construct that is helpful for the development process and if that's helpful for you then
0:26:32like you're probably you know if you're that kind of person like I'm not that person I
0:26:36like maintaining unit tests is one of the things that it like destroys my soul more
0:26:41than anything else in development because I feel like I'm building the app twice and
0:26:47I hate that feeling I what I value most in my development is being fast and efficient
0:26:53and not doing a lot of ceremony around the development like I just want to get into X
0:26:59code I want to you know write the codes and ship them and unit testing feels like I'm
0:27:03building two apps and one of them no one will ever see so that's my approach to unit testing
0:27:08yeah I'm pretty much the same I think if I had to write unit tests for everything I did
0:27:13I would stop programming. Alright one very last thing very quick thing here from Pete
0:27:20who asked things you now know that you wish you could have told your younger developer
0:27:23selves when just starting out so we only have time for maybe one each so my one is going
0:27:28to be that your actions in your app that you do to your customers are way more important
0:27:34in a competitive landscape than what your competitors are doing so like if you if your
0:27:40app already has people using it it is yours you like they are yours to lose people don't
0:27:46usually flee to other apps because of some competitors feature that attracted them over
0:27:51there they flee to other apps because your app is sucking in some way you're neglecting
0:27:55something you're not addressing something you're not fixing something you're being too
0:27:58slow to to adapt something new whatever the case may be your customers usually yours to
0:28:03lose and so what you do is way more important than what your competitors do. Absolutely
0:28:09I think my best advice that I would give my younger self is that nobody has it all together
0:28:17and this is most I guess to address this sort of like the imposter syndrome kind of a problem
0:28:22that early on in my career I struggled with a lot and I still do in some ways but it's
0:28:28so easy to look at someone else's output and judge just like judge the output not the process
0:28:35that it took for them to get there because it's easy to look at the output and say wow
0:28:39look at all like this is perfect it's like you know as though it was somehow like born
0:28:43like it was birthed magically into the world with just this perfect process that was effortless
0:28:47and without problem it's like when the reality is we all make mistakes we all have like the
0:28:53development process is often messy and uncomfortable and we have lots of failures some of those
0:28:58are public some of those are private but everyone nobody has it all together we're all just
0:29:03kind of like fumbling our way through and the more I was able to wrap my head around
0:29:09that and be comfortable with that reality I the more honestly that I was just able to
0:29:14make better software because I was less worried about comparing myself to this impossible
0:29:19standard that I imagined other people were living up to and just did my best and that
0:29:27really worked out a lot better.
0:29:29Well said.
0:29:30All right thank you very much for listening everybody not bad eight topics in 30 minutes
0:29:34not bad at all.
0:29:35It's pretty good.
0:29:36Yeah all right and we will talk to you next week.
0:29:38Bye.
0:29:38Bye.