How to ACTUALLY SHIP side projects?

Key Takeaways

when you want to build a project or start on something in general I often have a lot of trouble to actually start a while ago we mentioned breaking things up into smaller things to make it realistic to achieve but how do you plan out the start or project since I always get stuck there so for me it is it's very important to start with the end goal so for instance what I'm coding on now is something that I had a lot of time getting started with or rather like getting momentum so it's this the thing that you're watching watching here the little the little thing that changes the title that is this quite a quite a complicated thing to do it's a lot of moving parts yeah there's a little there's a little admin that I use here then where I've changed the title that we're moderators can sign in where their Twitter account and then it checks if this they are moderators and then it the overlay itself is a little react app that that changes changes title watching a fire race thing what what helped for me was to very clearly define what it was I wanted to do I wanted to have something that showed the title on the screen because I wanted people to know what I was working on and I wanted moderators as well to be able to update that title for me while I was while I was coding we're still not quite there yet because we actually have to make this a little bit reliable and decide which of the moderators do it and have a little bit of flow but but right now it's actually there you know I did it yes start with what you want to do and why like a sentence of that yes and that's important because otherwise I tend to be paralyzed I tend to just start like a setting up a project maybe I should have some time script man I should I also find that defer coding a little bit start drawing I do a lot of drawing so I made whatever is your poison but I for me it just helps to do sketches so they look a little bit like this I have these sketches that kind of show where I want to go they're not meant to be super detail or correct I try to not spend to it like it they are just mock-ups but they are enough for me to get a sense of direction and like get a get a clear picture in my hand so this is this here is the thing that I like focusing on that and then yes time boxing it so I want this feature done for this stream and in addition lower your quality standards lower your quality standards because I initially I I failed at this project because I wanted to make it like according to all the standards that I'm used to at at Spotify where we did everything we unit test and everything has to be like Paul requested and everything lalala lalala and I just got so distracted in that and it just took so much time that my like I just didn't make enough progress for me to be motivated when I just decided to just a for the end goal very very fast or not like the end goal but like the next milestone just get that out I created like a boost like a reward in my brain that was like wow I actually got something out I actually got something out and that made me it's very very happy showing something off to David and people on streaming like oh it's out there dedicated do you think TDD would help here or only add to the distraction for me like as much as I believe in TDD I getting rid of that in this case actually helped in getting me getting the property a project out and I feel now then I added typescript that I'm not sure if it was a good idea or not because now I have these quality problems that I have to have to deal with and I like I'm getting distracted by it a lot so mmm I'm a bit uncertain be very very skeptical to adding adding these these quality constraints on your projects when it comes to refactoring and typescript and unit tests and stuff I think it's important to at least for me to defer that after the work unit is done so once you have like the thing working like you've unit like now it's an odd function then you're allowed to do quality work on it and you might wonder then how does that work with TDD but because test-driven development is that you write write code only when you have a test that requires it and the only thing like that has really worked for me ears to throw away the code to throw away the code I write I write these prototype implementations that boom a run for their like run for the happy path making sure that everything works for or not not everything works like the the main case works like the basic basic path it renders stuff and then like and it works for logging in the main user doesn't work for like any of the other cases and then I implement like maybe one or two more cases and then the thing works no and then once you have that we we start finding like okay this component now we can start adding typescript to this and we can start adding unit tested s and the then you have like these little bits of progress because if you don't you end up in this situation where you never never get that reward feeling from working it's so important for you to feel that you're making progress and if you have like a lot of guards in place in the initial stages you just you're just fighting all of them until like something is on screen and perusing value they kind of like they are good later when you have like projects and you can like when things set up and you want to add like like this little thing and then the TDD will start making sense from our reward standpoint but not only in the early stages I think that it is valid to go for a very prototype be approached in the beginning yes to get things out because it probably gonna write the wrong thing anyway the you're probably gonna write entire modules that you just and like the discover are like oh I this is not what we needed at all so you're gonna throw it away anyway so yeah just try to write code of throwaway quality maybe even intentionally so you're not you don't feel too bad about throwing it away when you're TV and it also makes TDD a lot easier when you know how the api's work Tilly for me is very very hard to do when I'm unfamiliar with api's dedicate I already figured out the TS helps me it creates some calmness in the chaos mmm yeah it yeah it does in a sense I find that I get a lot of anxiety when I work in too big of a ball of work I wear hours and hours go by when I don't actually know it what I'm doing is working if if everything is it's too much so I think it's like super super important to to work in a small units as possible it does help to get TDD when the problem is very challenging it needs to be broken down into small pieces in order to get the concept together in your head oh yeah I find that typescript and aunt Edie help help in the same way that when they're like when there's a lot of cases that you need to ensure are working which is the case for any software really but it's they are both very bad when you just need to get to the that first feeling of having a working thing so when it comes to motivation in small projects and especially when you're alone it's getting to the protein like getting the the thing out there and like it's a clicky thing and like wow we have something he is is very like then it's it's best you just let all the guards go on it right the prototype first what first first version is crap and then then use that as a basis for for an X version because that it's so it's so fast to to write anyway it's all a matter of not saving saving the shitty code as long as you do that and you're fine other than ignoring TDD and type what other ways are there to create tight feedback loops um I find that be very very careful about injuries in new tools territorial chain as part of your project do like don't try to just like be just exactly the same tools that you use for your last project that you're well aware of that that will work sort of okay and if you want to try out something new because you feel like it would be suitable just pick one new tool don't change your process around it's it's a lesson that I had from from video production is that if you change something around it's going to break and it's gonna require a lot of time fixing it's extremely useful to rely on the same thing that you're always using whenever I walk into this room I just push like turn on the computer and hit the stream button and everything works because everything is set up in an extremely predictable way if I change something around like into you start using like the overhead camera here or like tweak something around it yes things fall apart and I have to fix them and that is important because you know you want to involve and if you yes if you just rely on on the same tools all the time you stagnate and what you create stagnate so it's important to to do to have change in your process but in order to get [ __ ] done rely on the tools that you know well even if they're not the ideal tool doc Pagani I think forging a proof of concept is important in Clara your tests for your real development which makes TDD easier otherwise it's hard to imagine what behavior we actually want yeah I think the declare like that that summarized in my position really well we should not be afraid of of doing proof of concepts kisser 6 says I created a server that restarts itself on on its own every time I save a file takes 50 milliseconds to see the results I actually invested some code in invested some in some code getting that to work yet gives me a tighter feedback loop that's a very good point I it's so important that your project is set up in such a way that you're not waiting minutes to see things you need immediate feedback you all like having things like the create react app which gives you immediate feedback of what on screen like oh now it works it's it is so important see like if you're if it takes more than a few seconds to know that you're making progress then it is definitely a good idea to spend some time and getting a test runner up or or Auto refreshing if you're working on front-end code that's really really nice but also why like when it comes back to DDD and you're writing like a back-end thing and if it's purely a back-end thing then then TDD might actually be a good idea especially if I like a test runner like wallaby which is super super refreshing and giving giving us this of giving a sense of progression that's that's really really nice now if you think the feedback loop ends the moment you push the code you're wrong the feedback loop ends the moment you get feedback from it from the customers stakeholders ah yeah I I mean this feedback cycle might still continue even after that I think it's important to think about dopamine here the reasons why games are fun is that they they have this very short reward loop you hit like the raid event rare right about an abundance gives you a reward you see like oh I did the right thing it's good good that's very inherent to us as humans and that is why I eventually like what I had to quit Spotify because I was just working on this thing that like it was rolled out to a million kabillion people but I didn't see them didn't know really what like I was so disconnected from from like the actual value I was producing you need to like figure out a way to actually feel that what I am doing is valuable I'm in the right direction and we are simple creatures so that sometimes has to be very very direct you know and if there is somebody else using your thing even if it's just your your co-founder or a friend that is you is gradually testing out your work and you're sending it and they've been clicking on it then then that is that might be enough we need to we need to have that constant reward dedicate it yeah but what would be a new feedback loop for a bug-fix patch I don't think that it like feedback loops are that I complicated on a on a bug fix I mean if the bug is complicated then it might be a little bit tricky but like let me show you let me show you a little bit how I think when it comes to bugs so in order to keep myself motivated in bug fixing I trying to like start asking questions right so I asked like okay so their event is not getting triggered and then I asked myself why and I write these things in a document because this way I can kind of like a board my processing go grab a cup of coffee and still get into it plus I'm super easily distracted so and then I write like a theory like could it be in the twitch API is the event triggered in the first place and then I asked right how can test this and then I answer that question and and it been like a log in the the top of event handler and then I do that and I find out that nope the event is getting triggered error is somewhere else and sometimes I guess right when I don't know what you write I guess like go like hmm and then like just to keep my flow going because somebody's told me once that creativity's in the fingers and then I write okay maybe it is in the database right and then I answer that query test and I answer that question put like put a log there and so like I tend to like narrowed bugs down so I start like could there be here no okay but like maybe the error is way down here and I like no it's it's fine here so it has to be somewhere in between here they're fine it's fine here it's fine here so then I start like gradually narrowing it down until like I find the bug to solve if you're familiar with with with search algorithms it's sort of like making a binary search in the in the in the bug so to speak by conceptually and working in this way allows me to feel like I'm making progress even though I'm failing all the time so it's like feels like I'm getting quite closer to the problem let's see Kesler 6 says and what did it say there's this kisser success there's a spiral of feedback loops there are multiple feedback loops one inside another start with pressing a key on the keyboard and with money in your bank from a paying customer yeah oh yeah it's oh it's so important to be able to segment feedback loops so you don't deal with all the loops at the same time because that then then that becomes a problem this is why I'm such an advocate of adding like linting and styling as separate steps so you so that I can work on code first making work and then I've run the linter to like find stuff that is like a little bit off so the vintage still catches like error errors but styling stuff that never goes right in my editor so that I'm not like starting to do like these little tweaks because then then it then the main unit of of work takes more time or like everything becomes baked into a ball yeah that's my thoughts focus on being I'm getting something out there fast but don't start working start like drawing up like what is that you want to do and write a description of of what it is and why you want to do it and try to give it minimal I try to make the smallest possible thing don't worry about quality in the beginning write a proof of concept to get the entire thing working and then once that is working use that as basis for your for your nice typescript TDD project and think about like the dopamine loops think about setting up your environments so that you get to success as fast as possible the closer you can make your environment work like a computer game the better yeah and if you're solving a bug break it down in little problems and like view it as an investigation that's my that's my advice on that hello hope you enjoyed that clip if you like this kind of content do consider joining our discord at fun fun don't shut and jump into maybe the on the job channel or the self care channel they are really really nice spaces where do you like it there whole fun fun chat is cuddly and nice atmosphere where we support each other and have a very good time it's very big and very active I think we're close to 1,400 members now so I think that you should join the fun fun family or you know maybe you just feel like watching more videos right now and then you should check out this one you