WuASM Episode 9 - "Devil in the Details"

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:39

   hey good morning welcome to uh wake up and more I am your host Joe from devhub uh and today we got a fun episode I'm just looking for my marker here it is uh today we're going to talk about a few different things that I think are really critical to kind of pull together a lot of the stuff that we've been been talking about on previous episodes some of the things that we've been discussing around uh building your app and architecture and stuff like that have been really important uh we're going to talk a little bit about pulling some of

2. 1:11

   that stuff together and this episode is called uh devil in the details and the reason why is because we're going to talk about some of those details that go into actually shipping code and why it's more than just pushing code but before we get started uh a few housekeeping things uh scrolling at the bottom of the screen right now if you have not already signed up for uh the newsletter uh for

3. 1:33

   from devhub I suggest that you sign up for it we have tons of great information there uh that is uh really well uh put together every single week with what's happening in the developer ecosystem what events are coming up uh changes things that you should be aware of definitely check that out we uh also if you are not aware Let's uh redacted Bangkok uh that is the big in-person event but leading up to that as well is a eight-week hackathon it's going to be

4. 2:05

   massive there's going to be tons of stuff around that uh that from both this show from the dev Hub live from all our different social channels we're going to have a lot going on uh that will help you be successful in that hackathon so if you're interested in doing that it's a great opportunity over $500,000 worth of prizes throughout that uh definitely check that out redacted bangkok. is the

5. 2:30

   web address uh couple other things uh too if you are looking to kind of get started uh whether it's through finding different uh communities whether it's uh looking for documentation things like that uh you can start here at uh near deev hub.org and get started from there so let's let's jump in oh one last thing actually here before I even forgot if you are watching this on a replay if you are not watching this actually live uh there's a telegram group you can join

6. 3:02

   you can come in you can join the conversation and ask questions there as well you can also reach out to me uh on Twitter uh my handle is there under my name you can reach out at any time and ask questions there as well uh we also encourage questions during the show as well so feel free to jump into all of that so let's talk a little bit about actually shipping code and like what we're actually talking about when we

7. 3:26

   talk about um you know what it means to send some to production and there's some things here that I think uh are both maybe more complex than people always consider especially if you never really shipped anything of any kind of scale and secondarily I think there are things that are are small and minor maybe feeling but are actually really important so I want to address all those different pieces of that today and kind of pull some of the what we've been

8. 3:56

   talking about over the past few weeks all kind of together in getting some to production uh so let's kind of just jump right into it I think it's probably the easiest way to talk about this so one of the things here is that you need to understand like what you're shipping and what it means to actually deploy your product and and what I mean by that is fairly fairly simple so basically if

9. 4:30

   you have an app and it includes again so I have an app and I have my website okay and maybe I also have a mobile app right so I have something in Mobile and then I have a back end right so I know I got to ship these different components here so like what does that mean to actually go and and and ship all of this and so that's that's a piece that I do think is is worth really trying to talk through and

10. 5:06

    understand what goes into all of that so within this setup you're likely going to have some kind of of architecture and we've talked about architecture in some previous episodes I definitely think it's worth checking out some of those if you haven't seen them before and when you think about what your architecture is like that's going to determine how you actually deploy something so if I

11. 5:28

    have a a architecture setup of you know let's say a dozen microservices well then my deployment process and I don't want to get into the details of like you know continuous integration and like what the actual devops of this is we're talking more in the planning and strategic pieces of this and like how you think this through so we can do devops a different day um but it's important so I need to understand like okay do I have microservices do I have a

12. 5:59

    monolith like what actual code base is actually getting shipped out and so my code base here usually again on my back end is going to be one of the first things that has to get shipped and I need to also think about two of like what other services are connected to this and so and that's this is where things start to get a little bit complicated right so I'm especially when we're dealing with stuff on blockchain but even in web 2 like you're going to

13. 6:28

    have your testing environment right you maybe have your staging environment and then you're going to have your production these variables that are there for your environment are going to likely be different so there's some things there that you need to be aware of and so you need to make sure that you're you're really listing this all out to be clear of what's going on there so the challenge that becomes though is

14. 6:52

    as you get further along and as you're ready to go to production and let's say you have an app that is now pass the MVP stage so we're saying we've done our MVP uh We've validated our idea we are ready to actually go to production and get this into hands as many people as possible well I've had to have made some decisions then of like what my structure is uh and what technologies are maybe

15. 7:23

    like what third parties I'm using and so all of that is in my initial deployment it's important to then understand of like what does it mean to deploy also with some of those third party Services as well so sometimes that might affect it but what happens is a lot of times is you're so focused on like my my launch date right so everyone's caught up in like this first part of my launch date that you

16. 7:54

    forget that sure I have a launch date but then I'm going to have to maintain this and now once it's live like software is never really done right so if it's never really done then I need to think a little bit more through that a little bit of like okay then what does my maintenance start to look like you know how do I start to maintain what I've now shipped and that's kind of the part two

17. 8:19

    so like if this is the part one I'm considering like what does this look like what is the structure going to be here part two would then be how do I maintain all of this so now to understand like did I plan well enough that this code base and this architecture is not unwieldy to then maintain uh there are a lot of different opinions about again things like monolith versus microservices and

18. 8:47

    everything else like that um that's a separate discussion and I think there is no perfect answer for a lot of that but what I can say is that you need to be comfortable with whatever decision you have Chosen and you need to know what it means to update your code and that's where the again the whole theme of this episode is Devil's in the details here so the details of like what does that mean for me to go in and make a significant change in the code base that

19. 9:20

    maybe you know could affect my users uh could cause downtime whatever that might be so those are things you have start to think about you also need to be able to understand we'll call this part three is like how am I going to know that everything is okay and everything is going to not just work the way it's supposed to work but also like as it starts to grow as more users come on board that they're all

20. 9:52

    having the proper and most likely the same experience Okay so we'll call this uh like how robust is your app that's a decent word for that so now I I have to consider like and how do I know and so this is where I talked about in a previous episode about like you need to have logging in your setup in some form that is descriptive enough to you as the developer again whether that's you you you being a team or you being a solo Dev or whatever that

21. 10:30

    might be like that feedback that you're getting in that logging has to be meaningful to you someone should be able to say to you uh this function didn't work right or I feel you know I faced some kind of error or negative situation I should be able to know where to look to see and understand what maybe happened now not always you can figure everything from the logs and sometimes

22. 10:58

    you have to be able to recreate the issue and actually see it happen fine I totally get that but you need to have enough information enough logging for that stuff you also need to be able to understand too of like where your scaling is right so as things start to grow a little bit um where does that all come together so that's that part now the piece here and this is kind of tied into again our launch and our maintenance and everything else but this is really a

23. 11:31

    part of the details that I think again are often overlooked so and this is where I want to make sure that when you are looking at what your code base is you know I always try to draw it with not just like my backend infrastructure you know and like my apis and like talking everything else like what's my front end look like you know what is the end user actually interacting with with and in this case maybe a website and a mobile app and so if those are the two things that they're

24. 12:04

    actually interacting with then I need to be considered of that but my details here is where you win your user and I'll I'll give the example that I gave before in another episode here but where ux can really make a difference so if you're building in web 3 and you're working on a crypto project uh you sometimes run to the issue obviously time right so uh some chains are are fast but you still sometimes have these delays and you are beholden

25. 12:37

    sometimes to uh other infra that is outside of your main infra like you know rpcs and indexers and everything else and maybe you're running your own and that's its own issues and everything else so you sometimes though want to mask as much as that to your end user you shouldn't make your user wait just because uh you have to wait on the back end so what can you do to make that

26. 13:00

    experience better for the end user where they don't feel like they're constantly just waiting for things to happen and that's where UI and ux comes in that's where the little details of like what happens like what does my loading screen look like how does what are the indicators letting the user know that everything is okay that something was successful something was not successful

27. 13:22

    um does my interface provide something clear enough that um you know that if something does go wrong they know how to reach out and get support and they're not just instantly put off uh a great example is the you know so the old Diablo error I think it was like error what like 30 I say yes error 37 that's what it was okay so uh back you know this is now JZ over 10 years old or so now longer um so in

28. 14:03

    Diablo 2 or three um so there was an error that would have come up called uh you know error 37 and that's what all would show to the user the user would see this error and they wouldn't know what was going on um error 37 was related to logging in and it was so was an authentication error and the problem would be is that the error had no descriptor they had no the end user had no idea what was really actually

29. 14:28

    happening when that error came up and so they would just keep trying to log in they were like I can't get to my game I can't log in and so I'm just keep hitting it well if you scale that and you think of all these users who don't know that the error is actually an authentication error they don't really know that it's a login error and they're all getting this and they keep trying to

30. 14:51

    log in over and over and over again then you kind of come into this thing of like now you're like dosing yourself just because there's not good user experience for your end user so like this is where I think it's like just you know your details here have to really be carefully thought out it's not just about again having a cool looking interface it's like is it actually functioning in a way that like is providing experience to your user that makes sense and when your ER when your end user has an

31. 15:22

    issue they can either react appropriately or better provide you that information whatever that might be and you don't want to have that eror 37 issue okay um part of the details here again when we talk about like again I need to consider all the details of my app right so I thought about how do I launch it how do I maintain it how robust is it how is it going to scale um do I know what's happening with it my user interface so the the next piece here is

32. 15:59

    about like performance okay and this kind of ties into robustness but it we're going to I'm giveing its own category because it's not necessarily just tied to scaling this could be just even on launch in day day one so you know do I know my approximate load times do I know like when a load time is abnormal do I know when you know uh how fast a transaction should happen like what is an acceptable

33. 16:28

    when window and how do I then handle an some an incident that is outside of my window and that's where I I again the details here are super important because if I don't know or I don't know what to expect from my performance I have no way of judging it I no knowing if I'm being successful or not so we really want to be careful that like our performance is a big piece of this of like again how are we staying focused on the end user experience and

34. 16:59

    knowing that where I need to make changes we also need to know like what goes into this okay and so this is going to be a few different things it's going to be your infra okay it's going to be your code okay uh it could also be though a little bit of again like your UI ux so performance might simply just be like yeah my code maybe is clean and efficient and my infro is good enough but like if the user experience is poor

35. 17:36

    where like I don't know where to click I don't know um that I'm supposed to do the next action well now the performance actually is gone down due to like your user just getting stuck like and so now like they're like oh you're in your mind you're like oh this task should take five seconds to do on my site but now it's taking 20 30 seconds well if it's not these first two maybe it's the user experience right maybe it's that interface is not clear and so that time that's being used up is actually just

36. 18:11

    time that is like the user fumbling around trying to find how to do the next thing so something just to consider of like what really goes into your performance now uh there are some more like Minor Details that you can get into that I think kind of tie into some of your performance and some of your robustness and little bit of that as like you know uh you know let's say like like what's

37. 18:44

    my o setup you know um what can I do in the background you know and and that's that's a really big piece too of like how much can I abstract away from the end user and just have things happen for them so and again like these are little details that maybe are not don't seem so meaningful at first but as you start to think about again like that whole full experience right this whole thing here like maybe

38. 19:17

    that like pushing some more stuff to the background or happen later is maybe more important uh again like the pulling in data right so if you're showing like any charts so this is a this is always a good one here of like if you're showing analytics charts of any kind and it you don't necessarily need to have real-time data it's silly to pull data in real time still because if it's

39. 19:47

    not as meaningful to the end user to be truly real time you're better off having some kind of mechanism that is fetching it at a certain interval in the background and so that when they go to that Analytics page it's instantly loading with with data for them to see and then maybe updates subsequently after that versus like I'm going to bring you to that page and we're going to now load for the next 30 seconds to a

40. 20:12

    minute pulling in all this data and then making the charts like that's that's the stuff that is again it's it could be maybe minor when you just think it through or you talk talk it through and yes there's maybe a lot more coding that has to go on the back end but that stuff again those details are what start to make the difference of your product and it also changes again for the end user

41. 20:38

    of like what are they focused on where are they going to give you the best feedback if the feedback is constantly like oh the lad times are so long well now you're scrambling to figure out lad times and like the number one thing that people do when they say he low times is like let me beef up my Hardware it's like you know let me get the big bigger server the fast more memory the faster

42. 21:01

    internet connection it's like okay maybe that's the issue and but like the first bet usually actually is probably like your code so maybe can you clean that up make that more efficient and second again is that user experience so this is that detail again of like can you focus on that and understand how you can improve your user experience through these little pieces of that mechanisms so again when we talk about devil in detail that's what we're talking about here

43. 21:33

    okay now uh we we want to be cognizant of I guess modern software development and for that this is where I would say like weal I mentioned it at the top here but external Services okay this is a really important detail that you need to almost be be uh like hyper Vigilant against because it is so easy to let this stuff slip but what I mean by that is so I have a product and I use a handful of external Services inside my product if I

44. 22:21

    don't know exactly how they work how much extra code is it going to bring in how much uh dependency am I going to now have on this is it going to affect other things that I have in there do I understand what gets affected it's just like you know when you talk to your doctor and they're like they prescribe you one medicine they say okay you're going to take this medicine don't have this other medicine because they'll interact well it's the same thing

45. 22:45

    possibly when you have all these third parties of like hey if you're going to use this third party don't use this other third party because they're going to interact they're going to cause a problem and you need to be able to really be clear about that um so many times when I've just like even like casually consulted not not even coming in formally just giving feedback they say I'm stuck here I I don't know what's going on it's like oh you could look at

46. 23:10

    the third party libraries and you can point to there and you see oh yeah like this one is causing an error here uh this one's dependencies are off and now you've just caused this mess so your external service is a place where you really want to be detail oriented you also want to make sure as well that you are really on top of like when they make changes because now as soon as

47. 23:34

    you introduce a third party you are beholden to their changes and their code and so yes like you can you can essentially like lock the code out from auto updating and you can do those type of things and you know but you have to be cognizant of that like you have to plan for that you have all these things have to happen as part of your planning and and then execution of your product and actually shipping to production so that's where again and

48. 24:05

    also I will say you have to be careful too because sometimes like in the test Library things feel maybe very fast because there's nobody on the test Network or maybe things feel um you know fast because you know it doesn't matter you're running it locally so there's nothing else hampering there's no other right that you're not worried about like current users and things like that but then all sudden you

49. 24:30

    ship to production and now you have a problem so you really you really have to take time with those third parties and really go through them carefully you also want to make sure that again any in your back end that then has to interact with that do those apis match up have you taken the time to go through all of that stuff like that uh lastly I think on this part here that to me makes the most sense is just making sure that and this isn't even like the actual Act of shipping but

50. 25:05

    I just want to include this because I think this is important and I will say coming from uh spending time in a corporate environment like a very corporate environment like Enterprise you know like big Enterprise uh this doesn't happen too often of like you as the developer developer need to keep learning and this does not mean this does not mean I'm going to keep trying new things I'm going to shove all this stuff and all the like the hot cool new thing into my product I not saying that but it's

51. 25:40

    important that you keep learning and saying on top of stuff because you want to be able to better adapt when it's time to adapt hopefully you're adapting before it's too late you know you want to make sure you're head of the curve you want to make sure that you're following what are potentially best practices or maybe best practices have changed over time and so you want to be clear on like hey like am I still doing the right thing all that uh a thing

52. 26:08

    that's come up I know even for myself before is that you know if you're working in let's say mobile right like if you're not learning and you're not staying up to dat uh because of how quickly you how often the operating system will change from year to year uh and maybe will include breaking changes like you have to be on your toes constantly all about that so that's where to me I really want to make sure that like you are considering like

53. 26:40

    learning and you're staying on top of stuff and that's part of your detail oriented process of like hey now I'm going to go ship you know my product because um you know I I I I feel comfortable of all these different parts of it okay so that's the the first part of when we say like here here are the details and what are we focusing on and this is a a big transition you know we just talked about here seven

54. 27:12

    categories of stuff you know with some subcategories here that all go into essentially shipping a product where before when you were just building you're just like you know code in code out and like here's maybe my architecture and here's you know my back end my front end and you know yeah this is a lot of work and a lot of code and a lot of planning but like this is like all the stuff that really goes into it

55. 27:36

    and you know when you get to a really big team sure there's going to be different groups that are handling different parts of this like you might have a devops team you might have a testing team and you may have maybe maybe have like a a really big team you might have like a team that's handling just like you know authentication you're going to have like your designers and everything else but the teams that I've seen be successful and the teams that I've seen you know or this even the

56. 28:01

    small teams that have been really successful have been around those who can understand the stack as best as possible it no one expects you to be an expert in all of these things like that's not realistic so like I I do not fancy myself as a designer I don't think I am particularly great at uiux that's not what I am but I know enough to one have a conversation about about stuff and and understand what a when a designer is telling me and giving me different feedback I know also enough to

57. 28:35

    be able to then like recognize something that could be blatantly problematic and so in my thing that hopefully I don't have to wait for a designer to do that and so that becomes part of that so hopefully you are minimizing some of that uh being reliant on all these different smaller pieces but you also need to be able to know like even if you're not devops if you are just the developer right you're just like let's say the you know the lead developer even like a midlevel

58. 29:06

    developer you know like how do you launch this like you should know even if you are not authorized to do it okay you don't have the Privileges to sign off on it you should know how do I launch my code how do I ship an update you know at what point are we going to hit limits against you know know like our scaling and everything else you know uh what are thing you know how does my app actually work what can what can i p to the background how does the

59. 29:38

    authorization actually work all things like this what kind of in infra is being used I should know all of these things as a developer and if you are on a small team and you are segregating your stuff self even in a small team you're making a huge mistake and again I don't I don't want to confuse you where you're saying like if you if you're a small team let's say five people okay and you have a devops

60. 30:04

    guy who's like he's doing he or she's doing devops and that's her his or her job that's great you know like that's an awesome position to be in because that is a a it can be a very challenging position but I would expect anyone on my team who is just maybe a developer right so my your job is to code and ship code you know take take tickets and take stories and ship and and push updates and everything else like that I would still expect you to understand like

61. 30:38

    again how things get deployed I don't need you to be skilled enough to do the deployment I don't need you to be trained in devops but you should know enough of like here is how something gets shipped and the answer also can't be like hey you know send it over to you know that she's going to go ship it no it it can't be like that either it needs to be enough like you know what's happening so the other part of this too is then like again you should be able to troubleshoot your own app from top to

62. 31:10

    bottom as well uh and this is a must for a small team so again if you are a team of even just again two or three and let's say one of your two or three is an intern or a junior developer you know someone who's inexperienced like I I would encourage you as the then more senior developer to bring that person along and make sure they know how to fully troubleshoot the app and be able to go through all these

63. 31:40

    different parts of it and understand it at the bare minimum they don't have to be able to do something about it but they need to be able to understand it and I think you'll see a lot more success come out of there by doing that now why do we have to focus on the details the reason why is because again when you are shipping your product if you are not crazy about especially here we'll start here first

64. 32:12

    we'll call this like section one okay like this first group this this will be group one okay if you're not like you know just you know a a a professional level like paranoid Pro going through your process of like did I like do everything right do I have everything set up have I put myself in a position to be successful if something goes wrong still like then like you're just rolling the dice like you're just gambling at that point it is worth it every time to spend the extra

65. 32:56

    time even if it takes you an extra few days even if it's an extra week to know that you have really mastered what a launch looks like and what a maintenance piece looks like that's just group one like that's the bare minimum and if you can do that you're at least on the right track because I promise you you're going to ship to production and then you're going to have to make an update fairly

66. 33:21

    soon after that's just like typically how things end up going even if you think you've got everything right something comes up and it could be minor hopefully it's minor could be a little bit bigger you need to know from day one very clearly how this is going to work and be comfortable knowing that this is going to be an efficient process because again like it's not just about knowing

67. 33:47

    it it's about understanding it and believing that it is going to be an efficient process okay uh the the next part here I would say is you know we can group I would say these three things here this would be my group two okay I want to take that a step further and I really want to dig into again like do I understand how robust everything has to be you know uh do I understand my my user experience performance things like that and then my group three is here

68. 34:28

    and the reason why group three is is kind of on its own is because look I understand when like when you're trying to ship especially if you get smaller like you have limited limited time some often to really dig super deep into your third party stuff you are likely going off of uh either previous experience feedback from people that you trust or maybe just uh reviews online or whatever you find to uh trust in like my this external

69. 35:06

    code I I don't love that approach but I understand it's not always realistic so I put it in group three because these are you know they're not necessarily nice to have I do think they're important they're more than a nice to have but they don't have to be truly on day one especially if you're a smaller team you don't just don't have the resources to really address all of this right away like if you have to kind of

70. 35:30

    push some of this off a little bit that's fine if you though completely ignore these two things and you don't dig into the details of how all your external stuff is going to Loop in how it connects all this stuff you're going you're doing yourself an enormous disservice like you're just you're asking for trouble down the road and then same thing with like the learning piece um you know without the learning piece next thing you know you're 10

71. 35:55

    years into a product and you have you know Legacy code code and Technical that that just at that point is like never going to get fixed and now the only way it gets fixed is like to do a major overhaul which introduces a million other complexities and everything else like that so that's what that's the the major piece of when we say like hey are you digging into the details of how you actually deploy something if you actually get the code shipped are we doing that the other part that I think is

72. 36:28

    really relevant to this conversation and I think this is a good exercise that goes in with like just understanding like am I thinking through the details well enough um and I hope you're if you're watching you know most of these episodes you're picking up on a theme that like a lot of the stuff that I'm talking about is all about like like are you taking the time to really think through what you're doing what are your processes to

73. 36:59

    consider what like what is the right or wrong decision right or wrong path uh what is your thought process it really it can't be just by like your gut in in software uh you have to have some justification because at some point even if you're a solo Dev unless like your product is just going to just die on the vine and you're just going to let it go and run its course somebody might have to come at some point and do that or

74. 37:29

    even yourself you're going to have to come in and try to update something or fix something way down the road where pretty much it might as well have been somebody else who wrote wrote it because it is unrecognizable to you and if you have not taken the time to put all those details in place and really been thoughtful about that your decision making uh you're again you're just you're setting yourself up for failure down the road you are taking shortcuts early on that will lead to much larger issues

75. 38:00

    down the road so a trick that I learned a few years back is um and this was a from actually another group of developers who had a podcast who were talking about you know how do they make decisions around um the defaults in their app and defaults are things like the settings that you would allow somebody who's using your app uh your product to change so it could be like you know

76. 38:32

    turning on notifications do I get emails uh you know dark mode light mode uh if let's say you have like an audio player like the default speed how do I load data is it by like uh you know is it by date is it by alphabetical whatever it might be and so maybe these are all different choices that maybe you give a user maybe you maybe you don't and so they talked a lot about like first off like what choices do I actually want to

77. 39:03

    give the user which I think is a great exercise like it's a great thing of like when you're thinking about the features in your app of like like how much I want to really let my user customize and there's a lot of stuff that we can go into maybe on like a different episode of like some of the psychology around all of that but the choices makes a difference of like what I'm actually going to give choices about secondarily then it becomes

78. 39:28

    of like what is the default setting of those choices okay so the like the most basic one would be is like light mode dark mode right what is the default so nowadays I would say most time the default would is like whatever your operating system is set to so if your operating system is set to like light or dark mode the default is usually one or the other um so that's usually how that's solved um and if you were to then make a decision outside of that you would say well yeah we're not

79. 40:07

    going to look at their operating system value we're going to decide for them and then they can go back and change they can change it on their own later so we're going to put everybody in dark mode regardless well okay that's a again it's just light or dark most is that maybe not like a huge huge thing but now like you have made a decision for the user that is possibly outside of what their

80. 40:31

    expectations are so what does that mean how do that affect how they use the app things like that uh again like just all the stuff like if you let's use the example of like a profile right what data I share how I go through all this stuff you know what are all those defaults uh like privacy is a big one right so yeah there's some laws in different parts of the world that dictate some of that but there's that like it's not always comprehensive in some places don't always have it and so

81. 41:04

    you as the product owner need to decide like what is the defaults and like what does this look like can the user change these defaults uh so for example again if youve ever shipped a mobile app you now have to fill out uh both IOS and Android a a form stating like the different privacy choices and things like that and one of the questions actually is like does the user have a choice to like opt in or opt out of certain data and you can say no you say no they don't have a choice like

82. 41:37

    this is what's happening and then just gets reported as such the challenge there obviously is like you know if it the user doesn't like that choice uh they may not use your app which is there again might be okay uh but like you have now eliminated that from their their choosing and so that the lack of choice becomes a choice so all of these things here all of your defaults are things that you have to you you should carefully think through and

83. 42:10

    this is again tying all of this stuff together like when I want to be really conscious of the details of how I ship a product the details of how I maintain my product a great again the exercise of you know this is this is the tip of the today really here is do the exercise of like what are my defaults what am I allowing my users to actually choose to turn on and off you know like how much Choice do I give them what are the choices they allowed to have and then like where do they start so anything

84. 42:44

    that does have a choice what is the default choice so if they don't go in and change anything what's the experience that they have and you doing this exercise is like really meaningful long term because it hopefully recogn helps you recognize one like the actual user experience they're going to have but two of like it should force you to explain your decision making and as I said in previous episodes like that is the number one thing that can help your

85. 43:16

    productivity is like talking through like why am I making this choice because I think you're going to learn a lot about yourself and your timing and where you put your effort the more you talk it through so the default of like CH making default choices and doing this as an exercise is is just a huge piece of that couple quick things around here before we wrap up so if you have a small team this is a great collaboration

86. 43:48

    exercise okay you get you break this down you give it to each team member you let them go through it and let them justify it um and let them talk it through of why they believe certain things should be set up a certain way okay in theory in theory the way you set up your defaults okay should be geared towards what I would consider a faster onboarding okay because you never want a purposely slow onboarding your users you want your users in in using the app as fast as

87. 44:27

    possible you don't want them making a million choices So the faster they can onboard right so so this is an important piece this is an important piece these two things right off the bat my team's going to collab better and I'm going to get my users in here faster because I've gone through this exercise I know what defaults they should have set for them things like that and now all of this

88. 44:49

    stuff really hopefully pulls together you know your thought process of like what you're your app actually is and like have you shipped it in a way that makes sense because again this exercise if you if you think it through it's going to address certainly some things here and now you hopefully as a team have talked through and learned group one group two actually does get a boost a little bit if you do this you know team

89. 45:22

    exercise okay and so now you have a really hopefully thoughtful and detailed out experience so I just you know we'll continue to talk about some of the stuff I I do really hope that you know you're starting to get a sense of there's so much more planning and consideration that goes into actually shipping product than just writing code uh it's writing code is such a a small part in all of

90. 46:02

    this it's an important piece you have to write good code uh you have to be able to do you know you have your product has to work the way it's supposed to work that comes down to like the code that you write but to actually ship a product okay and again we're focused here on on you know productization and getting things out the door and getting things in your user's hands you have to be

91. 46:26

    considerate of all these little details and really take the time to do all of that planning so that's going to win more battles for you in the long run by taking that time before you go live as you go live and then after you go live because that is going to Define again your product all the way through time as you make updates how do you make these decisions everything else because the coding can always get done the coding is going to

92. 46:58

    get done faster too the reality of it is is if you are using any AI tools you see how much time you can start to save how much more productive you can become using some of those so I am I have always been this way you know especially the past probably five six years and a lot of the work I've been doing um really tried to been Focus heavily on some of this pre-planning stuff but I will say that now more than ever like you you need to be spending your

93. 47:30

    time doing this stuff because it's going to pay off much more because if I can type in a prompt that takes me maybe a minute two minutes to write really carefully and it's going to spit out you know a thousand lines of code you know from system that I can just drop into my app like that's what is what is that in total time half hour maybe 20 minutes maybe less right to go through all of that check that run that so the the act of like actually getting

94. 48:05

    code you know completed and shipped is not is no longer really the issue it's all of the planning and everything else that goes into it it's all of the other structure stuff so the details are super important I encourage you to take the time I encourage you to plan uh and really focus on all these different pieces here that I truly believe are going to make a big difference in how you get stuff to production and everything else uh we'll stop here uh I encourage you to join the

95. 48:37

    conversation through telegram there's a telegram group for wum here um please come check that out I ask questions there you can always reach out to me on Twitter x uh as well and ask questions uh definitely go back you know look through some of the other videos see how we're putting some of these pieces together uh that all hopefully fit in and I I do think you'll start to see the pattern of what's going into all of this

96. 49:02

    uh we will have another episode this week as well you know continuing our path to continuing to ship more stuff uh I will also want to encourage you again we have devhub live tomorrow Thursday um that you make sure you're checking that out uh we have tons of stuff coming up for the redacted hackathon uh again if you have not checked it out here I put put the site up again go check out the website make sure you sign up for the hackathon it's online hackathon it's 8

97. 49:33

    weeks uh $500,000 in prizes uh and then if you can make it to the actual you know event in November even better um but if you can't you should at least participate in the hackathon uh it's going to be a really great experience in here at devhub we're going to have tons of stuff tons of content um interviews tutorials all the things you can think of you know leading up to it and through

98. 49:56

    the event so plenty of stuff to help you and we're here to help you you know ship your product and you know be successful whatever you're trying to do uh until then uh again keep building keep asking questions keep planning and we will see you next time uh thanks for watching Everybody Take Care n a