Under the Radar

39: Lightning Round 1


00:00:00   Welcome to Under the Radar, the show about independent iOS app development.

00:00:04   I'm Marco Arment.

00:00:05   And I'm David Smith.

00:00:06   Under the Radar is never longer than 30 minutes, so let's get started.

00:00:10   So we decided to ask our audience on Twitter a little bit ago what we should talk about

00:00:14   this week, because you know, in the summertime there's not a whole lot of news that happens

00:00:17   in the tech world usually.

00:00:19   And so we decided this week to do something a little bit different.

00:00:22   We're going to have kind of like a lightning round of listener Q&A and basically pick a

00:00:27   lot of the tweet responses that we got and try to answer them in, you know, because like

00:00:32   a lot of these things are not things that we can talk about for a whole episode.

00:00:35   We just don't have enough to say on these issues to fill a half hour, but we might have

00:00:39   enough to say on them to fill a few minutes.

00:00:41   So we're going to basically pick as many, just see how many we can get through in a

00:00:44   half hour and see what happens from that.

00:00:47   So Dave, you want to get started?

00:00:49   Sure.

00:00:50   So the first question that I was going to answer is I got a question from Jordy Bruin,

00:00:56   who asked about project setup when you are first starting new things.

00:01:00   And as somebody who starts a lot of new things a lot, I have a lot of experience with this.

00:01:06   And I've done a lot of different things.

00:01:08   I think where I'm going to take his question, with a lot of these, you could be asking a

00:01:13   different question than we're actually going to answer.

00:01:15   And if that's the case, sorry, but that's the way this is just necessarily going to

00:01:19   work.

00:01:20   So I'm imagining sort of like when you hit new project, how do you actually set up that

00:01:25   initial Xcode project before you start coding?

00:01:27   And I've done a lot of things over the years.

00:01:29   I've tried all the different templates.

00:01:31   Like when you go into Xcode and it has, you know, would you like this to be a tab application?

00:01:35   Would you like it to be a master detail view?

00:01:39   There's all kinds of things that you can do.

00:01:40   You don't want to set it up for core data or not or all of these other sort of templates

00:01:45   into this stuff.

00:01:47   I've tried all of those in the past.

00:01:48   I've always found that at a certain point it starts to get really messy if I go check

00:01:53   too many of those boxes.

00:01:55   And so at this point I would say what I do is I just do the smallest one possible.

00:01:59   So I do a single view application.

00:02:01   I don't check any of the core data.

00:02:05   Even though I use core data, I'll go in and add all of those things later.

00:02:10   And I find that works a lot better.

00:02:11   So sometimes I'll make a throwaway project to see how the template would have set something

00:02:16   up.

00:02:17   So if I'm curious if they've changed their core data stack or the way they recommend

00:02:19   it or I'll look at it, but when it's as empty of a project as it can be and I'll go into

00:02:26   my app delegate, I'll instantiate my root view controller, and I'll present it.

00:02:32   And I find that doing it that way, what I love is I know every part of the application

00:02:37   from the absolute, from the bottom up, is something that I understand and something

00:02:41   I know is working.

00:02:42   And so I don't have any of these weird surprises that I find if I set it up using one of the

00:02:47   Xcode templates.

00:02:48   Cool.

00:02:49   Yeah, that's pretty, I have nothing to add to that because I start a new project every

00:02:52   three years.

00:02:53   So it takes a long time.

00:02:55   I always forget what I've done last time and I just kind of wing it and kind of plow through.

00:03:00   Your way sounds a lot better than my way.

00:03:01   There you go.

00:03:02   All right, our next topic comes to us from Sjoerd Janssen, who asks, "How do you know

00:03:07   when an update is finished and can't be polished anymore?"

00:03:10   I'm struggling with that with myself now.

00:03:12   So this happens to every developer I know where you have an update or even your 1.0

00:03:18   to your app and you could just keep making it better and adding a little thing here or

00:03:22   there.

00:03:23   Oh, you know, I could throw in one more thing.

00:03:24   I could throw in one more feature.

00:03:25   I could make this thing a little bit better.

00:03:26   I could redesign this one screen or this one element.

00:03:28   And when do you actually just say, all right, enough is enough, I have to ship it?

00:03:32   And for me, I've kind of gone through different parts of this myself in my own experience.

00:03:37   I've kind of gone a different end of the spectrum here.

00:03:40   But ultimately, I think it's better to err on the side of more frequent updates rather

00:03:45   than fewer larger updates.

00:03:48   You know, we actually talked a little bit about this a while ago about marketing where

00:03:53   you can hold back a bunch of features to release all at once as a marketing strategy to try

00:03:59   to make one major update that will be newsworthy enough for maybe some blogs to cover.

00:04:04   But in practice, that's not most updates.

00:04:06   And the value of that itself is also kind of questionable.

00:04:10   It varies as to whether that's even worth doing, whether it actually works that way

00:04:13   or not.

00:04:14   But in general, I err now on the side of just release things as they get done.

00:04:19   And that tends to work better for me.

00:04:22   How about you?

00:04:23   Yeah, I would agree that in general, the thing that I've learned most after doing lots of

00:04:29   updates is that the things that I think are important or interesting are very often not

00:04:33   the things that are important and interesting to my users.

00:04:38   And so the sooner that I can get it in front of people and get their reactions to it, the

00:04:43   better.

00:04:44   The number of times I've like, I mean, I know this, I understand exactly that phase that

00:04:48   he's talking about.

00:04:49   Sort of you're like, "Oh, what if I did this?

00:04:50   What if I did that?

00:04:51   What if I did this?"

00:04:52   And you can keep doing that forever.

00:04:54   Like there is no, you will never reach a point where you're like, "Done.

00:04:58   This is perfect.

00:04:59   Ship it."

00:05:00   You have to always be sort of forcing yourself to cut it off.

00:05:04   And I think the more disciplined you can be to bite off small things, get them good and

00:05:09   solid, ship them and get reactions, the better your app will be much more quickly.

00:05:14   And sometimes when you avoid, probably more importantly, you avoid the situation where

00:05:19   you go down this rabbit hole, you build this like crazy new thing that no one uses or isn't

00:05:24   important to the app or actually makes the app worse because you're doing it in a way

00:05:29   that people aren't actually using your application for.

00:05:33   Exactly.

00:05:34   So the next one I wanted to react to is a question we got from Rob Farney who asked

00:05:41   essentially about the way we do UI layouts.

00:05:43   So do we code them?

00:05:44   Do we use Interface Builder or do we use a combination or libraries and auto layout and

00:05:49   all those kinds of things?

00:05:51   And so I think I have a slightly strange view on this, at least compared to a lot of people.

00:05:57   I've never really met someone else who does it the way that I do it, but this just works

00:06:00   for the way my brain is.

00:06:01   So I do all of my layout in code for the most part.

00:06:05   I'll have a few Interface Builder files.

00:06:07   Usually those are for things like setting screens or kind of one-off views that aren't

00:06:12   dynamic or interesting.

00:06:13   They're just kind of like a little corner of the application that I don't want to do

00:06:18   in code, but usually I'll just write them in code.

00:06:20   I do all my layout in code as well.

00:06:25   I don't use auto layout.

00:06:26   I instead do dynamic and interesting layout things, but I do it all in layout subviews

00:06:34   or equivalent methods in either the view controller or the view, depending on what it is.

00:06:38   So every time a view's frame updates, I'll go through and update the frames of all of

00:06:44   its subviews appropriately, which is essentially what auto layout does.

00:06:48   But I do it in a way that for me I can understand, that I can write clearer declarative code

00:06:57   that says I want this to be at this percentage of this thing, and I could do that in auto

00:07:02   layout and maybe I would get some benefits.

00:07:03   But every time I've gone down that road of taking my layout and putting it into something

00:07:09   else, whether that's Interface Builder, whether it's auto layout, whenever there's some kind

00:07:12   of magic that's happening somewhere else, in my experience it comes back to bite me

00:07:19   eventually.

00:07:20   There's going to be weird edge cases or problems or things that just mean that I would rather

00:07:26   just do it in code.

00:07:27   It's not for everybody.

00:07:28   You have to kind of be good at imagining a layout in your brain without seeing it in

00:07:36   front of you.

00:07:37   So if you can't do that, then this approach doesn't work, but that's what I do.

00:07:41   And a random pro tip for any kind of UI layout things is that every UI view has a layer,

00:07:47   and every layer can have a border width.

00:07:49   And so one of the biggest tools I ever use for fixing and debugging problems with my

00:07:56   layouts is taking whatever UI view I'm working with and I say view.layer.border width equals

00:08:02   1, which just adds a little black line around it, which makes it incredibly easy to see

00:08:07   where things are actually laid out on your screen.

00:08:10   >> Black?

00:08:11   That's so boring.

00:08:12   You should be using FOF, the bright pink ugly color that nobody ever uses in reality, so

00:08:16   you always know that's what you're looking for.

00:08:18   >> It's true.

00:08:19   But then I would need two lines of code rather than just one.

00:08:21   >> That's true.

00:08:22   All right.

00:08:23   Yeah, I actually have a pretty similar answer to that question where I do occasionally use

00:08:28   interface builder for something, but it's rare.

00:08:32   I prefer to do things in code.

00:08:34   Now I actually do use auto layout more than just like a view will layout sub views kind

00:08:38   of thing where I will use constraints and constraint language, but I do it through the

00:08:45   library that I have open source called compact constraint and it's basically a kind of shortcut

00:08:51   CSS looking kind of language for declaring constraints manually.

00:08:56   And I use a combination of that along with the, what's it called, the visual format language,

00:09:01   the kind of ASCII language of constraints.

00:09:03   >> Like the ASCII art thing?

00:09:04   I don't know what it's called.

00:09:05   >> Yeah, I believe it's the, I think it's called visual format language.

00:09:08   >> Okay.

00:09:09   >> I use a combination of those two things.

00:09:11   So basically my layouts end up, you know, there is a code, there is a function somewhere,

00:09:16   maybe it is view will layout sub views or awake from nip or whatever.

00:09:20   There's a view somewhere in my code there is a section where for every view I have listed

00:09:26   like here's all the constraints for when you create this view.

00:09:29   And it looks kind of like CSS and it makes it very easy to see what's going on and to

00:09:34   change what's going on.

00:09:35   And one of the reasons I do it this way and one of the things I don't really care for

00:09:39   about using Interface Builder is when you're using Interface Builder to do things, it's

00:09:44   often difficult to at a glance see what are all of the rules and all of the property changes

00:09:51   from default that I'm applying to this object.

00:09:54   You know, with Interface Builder a lot of times these things are buried in check boxes

00:09:57   somewhere or like little value changes deep down somewhere that like you might miss if

00:10:01   you're glancing at the file.

00:10:04   Whereas if you do the layout and customization of properties all in code, you can see it

00:10:08   all right there.

00:10:09   You can see everything you're doing to this view or to this window or whatever the case

00:10:13   may be and it makes it a lot easier to find and fix problems and a lot easier to figure

00:10:17   out like oh what's going on here, like why is this thing bold or whatever.

00:10:20   You can see it all in one place and that's something that you can just never get really

00:10:24   in Interface Builder.

00:10:26   All right, my next question comes from William Robinson asking failure, putting an app out

00:10:33   and nobody caring/downloading.

00:10:35   So basically what happens if your app just doesn't go anywhere?

00:10:38   This is heartbreaking.

00:10:40   It happens though, it happens to everybody.

00:10:42   You know, ultimately what if it starts going somewhere and then stops and then you know

00:10:46   eventually sales reach negligible levels.

00:10:49   This has happened to a number of my apps because again this happens to everybody and you know

00:10:53   one of the clearest ones was Bugshot where it just kind of shot up, you know made a couple

00:10:58   thousand dollars in the first few months and then just kind of went down to nothing and

00:11:01   was making like a dollar a day for a while at best.

00:11:05   And you know that's, when that happens you kind of have to face reality and it's a little

00:11:10   hard to judge like okay well if I put a lot more effort into like a 2.0 maybe I can like

00:11:17   save this or rescue this.

00:11:19   Usually that's not the right move.

00:11:21   Usually you can't save or rescue it.

00:11:23   Usually the market is telling you something.

00:11:24   The market is telling you either, you know either we don't need this or we are satisfied

00:11:30   by other solutions to this problem enough that yours isn't necessary.

00:11:35   And you know you could change things about it like you know you could change the price

00:11:40   maybe you could you know again you could release a 2.0 but usually if something has failed

00:11:44   in the marketplace enough that you need to face this reality, chances are any of those

00:11:49   changes you would make to it would not be enough to turn what is clearly a failure into

00:11:54   a success.

00:11:56   You might eke a little bit more time out of it, a little bit more money out of it maybe

00:12:00   but probably not.

00:12:01   Chances are you know recognize your, recognize failures early enough and then just move on

00:12:07   if you can.

00:12:08   That's usually a better use of the time than like you know shoving more time and effort

00:12:13   into an app that has already failed in the market.

00:12:16   Yes and I've failed a lot.

00:12:20   Like the experiences you're describing is something that I've experienced many times.

00:12:23   I've launched a lot of apps and I've had many of them that go out and either have the thing

00:12:29   you describe with Bugshot where it's like it goes up and then just like falls flat or

00:12:33   even I've just had it never go anywhere.

00:12:36   Like you just never know and the biggest thing I suppose is to understand that it is not

00:12:44   like the ultimate, the ultimate product that I am building throughout my career is myself.

00:12:53   Like what I want is to at the end of the sort of have each project of everything of each

00:12:58   thing that I build make me a better developer, make me more able to make better and more

00:13:03   awesome you know products and things down the road.

00:13:07   Because tastes will change, platforms will change, like all of those things are always

00:13:12   going to be very, you know evolve over time and no one product is going to last forever.

00:13:17   You know my business has been based on products in the past that now do kind of terrible but

00:13:23   that was fine.

00:13:24   They had their moment and sometimes you know you never are going to know exactly what's

00:13:27   going to happen.

00:13:28   And so whenever you have failures I think the most constructive way to look at it is

00:13:31   to say what can I learn from this?

00:13:35   How can this experience make me a better developer?

00:13:38   And then take that experience and just pour it into your next thing.

00:13:43   Because as long as you are getting better each time then you're being successful.

00:13:48   Like you are meeting the core goal and while that's nice when it's you know you hit on

00:13:52   a product that is successful and really just takes off and like that's awesome you know

00:13:57   I'm just really not diminishing that.

00:14:00   But making sure that you always keep it respected that like the individual product is not you.

00:14:04   You know you trying to have some distance from what you create is really helpful and

00:14:08   keeping the focus on what can I learn and now let's go work on the next thing and not

00:14:13   get too stuck on it.

00:14:14   All right we are sponsored this week by Braintree.

00:14:18   Learn more at BraintreePayments.com/Radar.

00:14:21   Why make payment integration more difficult than it has to be?

00:14:24   Braintree's powerful full stack payment platform allows you to accept nearly any type of payment

00:14:29   from any device with just one integration.

00:14:32   It's flexible to your system's needs and supports most programming languages.

00:14:36   Whether you're using Java, God I hope not you have my sympathy, Java, Ruby or Python

00:14:41   you always have a range of server side and client side SDKs available.

00:14:45   The Braintree code supports Android, iOS and JavaScript clients and it takes just 10 lines

00:14:50   of code to implement.

00:14:52   Braintree makes payments and your job a whole lot easier.

00:14:54   Learn more at BraintreePayments.com/Radar.

00:14:58   Thanks a lot to Braintree for sponsoring our show.

00:15:00   Okay so the next question I wanted to address is from Hip Tomcat and he's asking about

00:15:07   architectural patterns like MVVM, MVC, coordinators.

00:15:10   I've had a few kind of questions about this like the all of these things do kind of I

00:15:16   don't I don't go and maybe my answer will probably point out that I don't go down the

00:15:21   road of paying too much attention to a lot of these things like there's a lot of things

00:15:25   that I keep hearing about where people are talking about like new patterns or sometimes

00:15:28   there are new structures or approaches to apps or like and I see that and I look at

00:15:34   it and I the thing that I always worry about whenever I see people who get really wrapped

00:15:39   around patterns and this goes back to like back in my old Java days where the like design

00:15:46   patterns thing was a big like there was like a big fad where it was that was the whole

00:15:50   thing everything had to be a factory or an observer.

00:15:54   And the important thing I always try and keep in mind and get him and like when I get this

00:15:58   kind of people ask me this kind of question is making sure that you're writing code that

00:16:03   a you can understand and not that you understand like at a vague level how it works but you

00:16:09   can under you understand why it's structured the way it is like the worst implementations

00:16:14   of it whenever was back when I used to do consulting read come in to a project and try

00:16:20   to try and work out how they're doing something and you kind of clearly get the sense that

00:16:24   they're using a design pattern because they feel like they should but they don't really

00:16:29   understand what that design patterns intent or purpose was and so it's just a mess.

00:16:35   So if you're ever going to use a pattern you have it should be this thing that's like well

00:16:39   I you know this is the best way to do it I completely understand the trade-offs on both

00:16:43   sides of this and for me and the way that I think about this problem this will work

00:16:47   really well and if one of these approaches works great that having view models or coordinators

00:16:53   or whatever it is like that that fits with the way your brain works then awesome that's

00:16:58   great but definitely never feel like you have to go down the road of adopting some pattern

00:17:03   because it's sort of hip and trendy because the nature of hip and trendy is that it will

00:17:07   change and it isn't necessarily changing because we've somehow like had this breakthrough discovery

00:17:13   and now it's like turned the world of software development over time like there's an element

00:17:18   of it that is just trendy and so find what works for you and make sure that you can if

00:17:23   you can understand your code and it's understandable you're gonna have far fewer bugs then the

00:17:28   thing where it's like oh well theoretically if I use this thing and I completely abstract

00:17:31   all of my logic away down the road it'll make it easier and I'll have great encapsulation

00:17:36   and my bugs will go down because I can you know test all my interfaces and that's great

00:17:40   that's probably true at a certain point but the actual like developer sitting at the keyboard

00:17:45   has to understand what's going on and if you can do that then great like for me most of

00:17:50   my architectural patterns in my apps are structured around like singletons and managers I guess

00:17:55   I call them that's the way most of my apps all my app logic is kind of broken up into

00:18:00   you know I have a whole bunch of singletons that handle a bunch of different like have

00:18:05   a particular domain so like I have a singleton that handles all my stuff with health and

00:18:09   dealing with health kit or dealing with core data or doing networking and for me that works

00:18:15   like I can I know we're all like all the problems with that like there's certainly issues with

00:18:19   singletons and coupling and like I understand those downsides but for me it works great

00:18:24   and I understand it and I know how not to do it wrong and so that's what I do and I

00:18:29   try not to be too distracted whenever there's like some hip new thing that's come out and

00:18:33   you know it's like you have the problem of you see a talk say at a conference or something

00:18:37   or blog post and someone's like hey we did this thing and it worked great for us and

00:18:42   you immediately can try and extend that to say like hey they did this cool thing and

00:18:47   it will work great for me when if you really you have to have a much more deep understanding

00:18:52   of what that thing is and what its benefits are before you can ever make that kind of

00:18:56   a judgment.

00:18:57   Yeah I pretty much agree with everything you said I also develop with a lot of singletons

00:19:02   and things I also don't use a lot of design patterns or at least like I never read the

00:19:07   Gang of Four book and so maybe I'm using them without even realizing I'm using them but

00:19:12   I never really got into that side of software architecture of like really obsessing over

00:19:18   that kind of thing because in the scale that I'm typically working at with you know a one

00:19:23   person team that kind of stuff tends not to matter as much as it would maybe on a larger

00:19:29   team and I'm working on pretty simple things and also like you know I just tend to follow

00:19:33   the conventions of the system I'm in so like I'm very familiar with the way Apple does

00:19:37   things with the cocoa API's and the way they're structured and kind of the patterns that they

00:19:41   encourage and that they use themselves and I try to structure the rest of my app that

00:19:45   way to kind of mesh well and kind of mimic the structure of the cocoa API's beyond that

00:19:52   I don't really do any kind of other fancy structure.

00:19:55   Alright next I wanted to bring up a question from Luke Allen who's asking about the viability

00:20:00   and landscape for new indie developers to break into the iOS and Mac marketplace in

00:20:05   2016.

00:20:06   Now this is obviously a big and kind of broad and kind of squishy feelings question so it's

00:20:11   a little hard to answer like you know can new indies break in now?

00:20:15   To me I think all you have to do to answer this question is to take a look at your phone

00:20:20   home screen and what apps are on it today and then think back or if you have old screenshots

00:20:26   even better look back at what your home screen looked like three years ago and how many of

00:20:31   the apps that you're using today were out three years ago?

00:20:35   I bet it's not that many you know ruling out like Apple's built in apps or anything which

00:20:40   even they have changed quite a bit but the fact is that yes this is a large and saturated

00:20:46   and old market however there's always churn in every software market there's always room

00:20:52   for something new and it isn't always easy to break in but there's always a spot somewhere

00:20:58   in the market like you know simple things like that you think would be very very crowded

00:21:02   like notes and weather apps like you know we bring up these examples a lot.

00:21:06   I mean there's always a market for a new notes or weather app if you can do something a little

00:21:11   bit differently some people will like yours some people won't and that's okay there's

00:21:16   room it's a very very big market lots of people use it not everybody wants the same things

00:21:21   out of every app and a lot of times people just kind of get tired of what they're using

00:21:24   and just want to look at something new so there's always room it is getting harder to

00:21:29   find that room and there's more people vying for it however there is always room for new

00:21:34   things to bring into the market.

00:21:36   Yes and I think the key thing when you're if I was if I was a new indie trying to like

00:21:42   sort of if I decided one day that that was what I wanted to do I want to be an independent

00:21:46   software developer I would be very careful about a like my check my motivations make

00:21:54   sure I'm doing it for the right reasons and like understand how terrible of a job it is

00:21:58   and not just sort of get which I can say a bit jokingly but quite honestly as well like

00:22:05   it is not the it is it is not like a glamorous lifestyle being an indie software developer

00:22:11   that there's only some upsides of being your own boss and being able to work on things

00:22:15   that you think are cool but there's a lot of really not so great things some things

00:22:20   that you give up from working for a corporate job or in a consulting job so you know you

00:22:25   there's definitely some trade-offs make sure you're doing for the right reason and then

00:22:28   making sure that you're having realistic expectations about what you are hoping to accomplish you

00:22:36   know is it that your goal is to have in you know just have a side income from your bit

00:22:41   from your indie work is going to be your entire income and understand that those different

00:22:47   levels are going to require different amounts different amounts of time and luck and effort

00:22:54   and be careful about what you're going after you know like sort of like you said like some

00:22:58   apps there's a natural trendiness to them and so it makes sense to get into something

00:23:05   and you know be someone that somewhere there's a lot is a lot of churn like a weather app

00:23:10   is and they sort of comes to mind as something where there's a there's this natural like

00:23:14   I don't know everyone just thinks of something differently and so you can have a unique take

00:23:18   on something and that has has an opportunity to be successful and I'd also say be really

00:23:24   careful about taking on projects that are very complicated to start with like you either

00:23:32   need to be have some if you have some like really deep and interesting new approach to

00:23:37   something like I think of someone like Chris Lissio with all of his audio processing stuff

00:23:42   that he does like he has made a business of making software because of a really specific

00:23:52   skill set that he has that he really is good at audio processing and so he can make a business

00:23:57   because not a lot of people can do that and so if you have a skill like that like run

00:24:00   with that if you have some background knowledge or some domain expertise like go for that

00:24:04   and pursue it but if you don't don't get sucked into the trap of trying to like build this

00:24:10   grand big very like it's just like this existing thing but like way bigger and more complicated

00:24:15   and better yeah that never works like that's gonna really come back to bite you especially

00:24:19   if it's just involved like oh it's gonna have data syncing and it's gonna have all this

00:24:21   other stuff and like that would be something I'd stay away from and especially to start

00:24:25   with like start simple start with something you enjoy something that if you made the app

00:24:30   that no one downloaded it but you had it and could use it every day that you would be happy

00:24:34   and that's probably a good place to start all right the next question I wanted to address

00:24:39   is from Phil Curry who's asking about unit testing for the one-man shop is it worthwhile

00:24:45   and if so where to start so unit testing is a I would say is an academic topic for me

00:24:53   as it is something that I have never done so I can speak to it only in the theoretical

00:25:00   rather than in the practical experience type unit testing is something that well I have

00:25:06   used it in the past like in different projects but not never by Mandy work and I would say

00:25:12   unit testing in my experience is useful for one of two reasons it's either useful because

00:25:20   the cost of messing something up is very high so if you know if you're someone who's writing

00:25:29   software that you know is used to control a plane is flying through the air you need

00:25:36   some unit testing like you need some serious you know quality assurance kind of process

00:25:40   because if you mess up that really like like genuinely bad things can happen not just like

00:25:46   bad things like my server went down for a few hours like you know life and death kind

00:25:50   of situation so if you're if you're in a situation where the cost of having him having a bug

00:25:55   having a mistake is truly you know significant absolutely and the other situation where in

00:26:02   my experience unit testing is helpful is I know like there are some developers I've worked

00:26:07   with over the years for whom like developer unit testing is the way they think of development

00:26:12   that they create you know sort of like the test driven development approach of saying

00:26:15   like here's this problem I'm going to code a test that will you know be will pass once

00:26:23   I've solved that problem and then they go and solve the problem and it's just like a

00:26:28   construct that is helpful for the development process and if that's helpful for you then

00:26:32   like you're probably you know if you're that kind of person like I'm not that person I

00:26:36   like maintaining unit tests is one of the things that it like destroys my soul more

00:26:41   than anything else in development because I feel like I'm building the app twice and

00:26:47   I hate that feeling I what I value most in my development is being fast and efficient

00:26:53   and not doing a lot of ceremony around the development like I just want to get into X

00:26:59   code I want to you know write the codes and ship them and unit testing feels like I'm

00:27:03   building two apps and one of them no one will ever see so that's my approach to unit testing

00:27:08   yeah I'm pretty much the same I think if I had to write unit tests for everything I did

00:27:13   I would stop programming. Alright one very last thing very quick thing here from Pete

00:27:20   who asked things you now know that you wish you could have told your younger developer

00:27:23   selves when just starting out so we only have time for maybe one each so my one is going

00:27:28   to be that your actions in your app that you do to your customers are way more important

00:27:34   in a competitive landscape than what your competitors are doing so like if you if your

00:27:40   app already has people using it it is yours you like they are yours to lose people don't

00:27:46   usually flee to other apps because of some competitors feature that attracted them over

00:27:51   there they flee to other apps because your app is sucking in some way you're neglecting

00:27:55   something you're not addressing something you're not fixing something you're being too

00:27:58   slow to to adapt something new whatever the case may be your customers usually yours to

00:28:03   lose and so what you do is way more important than what your competitors do. Absolutely

00:28:09   I think my best advice that I would give my younger self is that nobody has it all together

00:28:17   and this is most I guess to address this sort of like the imposter syndrome kind of a problem

00:28:22   that early on in my career I struggled with a lot and I still do in some ways but it's

00:28:28   so easy to look at someone else's output and judge just like judge the output not the process

00:28:35   that it took for them to get there because it's easy to look at the output and say wow

00:28:39   look at all like this is perfect it's like you know as though it was somehow like born

00:28:43   like it was birthed magically into the world with just this perfect process that was effortless

00:28:47   and without problem it's like when the reality is we all make mistakes we all have like the

00:28:53   development process is often messy and uncomfortable and we have lots of failures some of those

00:28:58   are public some of those are private but everyone nobody has it all together we're all just

00:29:03   kind of like fumbling our way through and the more I was able to wrap my head around

00:29:09   that and be comfortable with that reality I the more honestly that I was just able to

00:29:14   make better software because I was less worried about comparing myself to this impossible

00:29:19   standard that I imagined other people were living up to and just did my best and that

00:29:27   really worked out a lot better.

00:29:29   Well said.

00:29:30   All right thank you very much for listening everybody not bad eight topics in 30 minutes

00:29:34   not bad at all.

00:29:35   It's pretty good.

00:29:36   Yeah all right and we will talk to you next week.

00:29:38   Bye.

00:29:38   Bye.