Is your generalization actually procrastination?

Key Takeaways

hello this week on the livestream I was asked this interesting question about like how do you how do you deal where that sinking feeling of oh maybe I didn't make this code flexible enough and I went on this interesting rant at least I thought it was interesting on how one can use generalization as a way to procrastinate and also like planning planning as well and also testing strategies to like basically us ensure try to insure yourself from real or reality and never actually get anything done I thought it was a little bit then interesting interesting thought and I've clicked it here for you before we go to the clip I would like to thank today's sponsor brilliant brilliant is a brilliant sponsor that have been with the show for a long time brilliant it's a great loss service that allows you to do this interactive tutorial so you didn't they're not like passive video courses they're interactive and with a sense of progression that allows you to learn subjects like computer science or like the math behind machine learning stuff like that yeah that that just requires a lot of interactivity and repetition in order to actually get them it's a really great service they're a great supporter of the show so please check them out if you're if you're interested in learning any of those topics they're great you can go to brilliant of org slash FFF to get quite a bit of your annual subscription so check that out after the show I will remind you that as well now on to the clip alright this one this question my underscore funk how do you deal with the feeling of did I build enough flexibility when starting to write architect this app I feel I get an anxiety when starting something that might slowly be digging myself into a hole instead of making a thing and then I spend my wheel looking for solutions based on potential problems oh man oh man I'm let's go Frank I feel ya I feel ya aye aye aye I can't say how much I relate to that I I so often get stuck in like riding and riding a piece of code and then I I start generalizing a little bit too much it's too flexible so like every everything I write takes so much time because general solutions always cost much more a lot more actually and you know I think that perhaps that's a good proxy recognizing the fact that general solutions wide solutions are ludicrous ly expensive I kind of like demonstrate found this when I was writing the the video this week that I posted this Monday was about like I wrote this all habits tracker thing and that thing is dirty coded it like like laser focused on just getting it done and also getting it done for just me like not a general solution so it's a habit tracker that it's kind of like it goes green and then I like if I don't do the habit which is like being my bring food to work every day then it goes red then it goes yellow and then it goes red the next day until it like breaks the streak and it resets itself at midnight every day and the thing is like midnight is a little bit tricky thing with time zones so I just went with the UNIX epoch because that is UTC time and it's not quite Swedish time it's it's like 1:00 a.m. and 2:00 a.m. depending on daylight savings time but that's close enough for me you know this code won't work for a u.s. person but eius went for it you know it's not perfect it's a little bit off but I will never notice that because like the switches in the middle or not anyway and I really just needed it to work for my case I just wanted a prototype to test how this feels you know I'm not sure if this is even a good way of tracking habits just want the prototype and for that purpose he would like and that saves so much time because getting like time zones to work in that thing would have taken I idea Kunshan amount of time it would probably be like the majority of the time I haven't spent on the project SEO tech went for it so I think that you should be very defensive about generalized solution and trying to make things as dirty as possible and instead like be more overt about like this is a prototype that we are trying like we and only make they're like fancy thing once you're very very sure of it like general things are a generalization is is dangerous I would say it's dangerous it's I've did like I find I found that much more projects have been destroyed by things being too general rather than them being too narrow underscore function oh I want to write this thing wait I should do TDD wait how do I even test this that's the story of my life that is why we don't have an overlay that has as twitch let's stretch integration you know like I think I should just dirty coat it first make like a version that is buggy and shitty and then write a nice version maybe it's it yes they tend to be so stuck in it you know Oh cats Inc I so suffer from over planning things too early yeah you know like this is actually a procrastination technique / planning it's me dropping pants constantly it's it's a thing so that like it's you have to understand this compensation technique that you use to to prevent you from facing reality because in a planning stage your product is perfect you don't need to deal with reality you can use ignore reality planning is sort of like a map or reality you know how a map it's not actually a picture of a city it's just a simplified model of the city and it's the same thing with planning that when you're in the planning stage you can dream up that reality is easier than it is you don't like nobody ever writes hacks into their planning whoever does that no you don't because you're just planning and you're wishing for reality to be nice you're you're thinking like on the blank stage your your code is still like mmm it's architecture it's so nice I cover everything you know so I think that the planning is there for like this is perfect you can live in your fantasy world and like another variant of it is to write frameworks because frameworks frameworks are great because when you build a framework you you don't actually have deal with a real problem you can just invent an imaginary problem that doesn't have the edge cases that are nasty to deal with so you just write a framework that is like that's why frameworks is so great to procrastinate with underscore Fung said follow up questions so I should a show should you just skip things like TDD when you're stashing out a prototype I would say yes I would say yes this requires though that you actually throw away the prototype I think that like for me I've found that it's very important when doing prototypes to write them very badly very badly you can't write a prototype that it's sort of good like if you're not writing with tests don't write with architecture right [ __ ] garbage that cannot possibly be used like it needs to be like that the code and whole thing needs to just scream rewrite like don't do a nice design on it either like or maybe like yeah like it's just that is dangerous because if something is too good it's going to be used reused so it has to be like under that level Robert Abel says oh this is good this is good Robert chaebols premature abstraction can be much more deadly than allowing some duplication to arise this truer words have not been spoken make it work and then make it good and if you need to then make it fast yep yep that's also very very good yeah like I think that it's one of the most important things I learned as a software developer is to allow duplication to a rice before removing it never anticipate duplication you will fail in that anticipation we are not that good at predicting the future you are just you're just being like a fortune teller then and like it you're not gonna do it well generalize based on duplication and don't two cases are not enough to see the general case like you cannot you cannot see what a mammal is based on just a cat and a dog you need to see an elephant you need to see like a you need to see a deer and you need to see a dolphin it's like you won't get what a mammal is like you don't see the general thing until you have quite a wide range of things certainly that says I've seen it argued that TDD can be useful when prototyping one specific example is when exploring a new API Oh interesting I actually think that I found that TDD is really bad when developing API is I always do an exploration of the API first before writing tests that's actually like a the case where I never do TDD interesting like some Lisa Darko says say if you were to write a thing properly from the first time wouldn't you need to do less refactoring yeah sure if you write it properly the first time but I think thing is like this is like the assumption this is assuming that you can write a thing properly from the first time it's like if you look at any product any product and like the history like any tech product and a software product how many of those call it right in the first iteration Instagram was like there was a [ __ ] bizarre a super complicated location-based checking thingy thing and then they pivoted towards like a thing that just added nice filters to uploaded uploaded images and then I liked Flickr was some kind of online game thing with that failed but they had a sort of good image uploading component I don't know if you know this about MT GOx like the biggest Bitcoin exchange in the world until it shuddered like I thought always aw that mountain MT GOx that that was like referring to some like Chinese mountain like month walks or something now it stands for Magic the Gathering online exchange and it was just like a like the use it was a forum for training Magic the Gathering cards and there was a segment on the forum where you kid could use like bit a Bitcoin to buy buy magic cards and then people here start trading Bitcoin but like just using selecting any fake cards because it was like one of the few exchanges and eventually just morphed into like one of the most biggest Bitcoin exchanges in well I guess processing billions of dollars you never know like it's it's hard to protect predict to you the future you're almost gonna you're gonna do it wrong underscore fun for me it's to do with the PTSD I didn't plan I made a lot of problems and a pain from that echoes into the planning of future projects yeah but it's yeah it comes down to though if you if you can plan or not like no oh battle plan survives contact with the enemy none it's always going to be like a bunch of a bunch of problems like you cannot you can never prevent [ __ ] from hitting the fan you can only be good at cleaning the fan it's much better to invest in your [ __ ] cleaning skills than your [ __ ] velocity projecting skills because they're gonna hit they're gonna hit like your service are going to go down like you there's going to be a critical bug hitting production and you need first and foremost to be good at like identifying problems and redeploying fast rather than trying to never have any problems in the first place that secondary you know and it's this also it's a lot related to where your product is in the cycle if you're doing like if you're not if you're very sure about like what it is that you know works like Spotify for instance like it's it's a thing is it streams music like there's not a lot of experiments experimentation space what if I it's not suddenly going to pivot into a car sharing service we know that but in the early stages of a start-up like the code has a very low chance of survivability TDD is a waste of time don't tell your interviewer that yeah like TDD is one of the most valuable tools in my toolbox but I find that like it's important to like it's important to like it's good when you know sort of where you're going when you know like sort of what the API is but you can like TDD is way too much [ __ ] when you are doing complete exploration when you when you like when you have no idea what what the feature said is gonna be like and like when things are gonna wait like highly highly likely to be thrown away like it's the point of TDD is to add some inertia to your code so that it doesn't change as fast and when you change it you you do it very carefully so that you don't accidentally change something and that's the same thing with static typing it adds it adds inertia like the inertia is what we want you don't want to be able to refactor your code base into a car-sharing service you want the changes to be very very slow and methodical mpj says TDD it sounds like a honking car TDD Blackwell says because mbj is a transformer and his vehicle form is a truck honk thank you so much for watching this was a little clip from the live streams I do every Monday morning you can find them at twitch.tv slash fun fun function don't forget to check out our sponsor brilliant you can find a link in the episode description that gives you a lot of discount on your annual subscription if you want to sign up for that if you're new this is a show about programming you can you can also subscribe to more clicks like these here and if you want to check out more about what your channel is about you can do so here I am mpj until next Monday morning stay curious