Talk:2730: Code Lifespan

I'm not sure if the thesis in this comic is accurate. But if it is, my explanation would be that a person with a more spontaneous live-in-the-moment attitude might program stuff that is more interesting, than the stuff made by the person who is (maybe neurotically) obsessed with making clean code.
My own experience is that one loses the fun of programming something if the perfectionism plays to big of a role. 162.158.203.40 (talk) 14:53, 27 January 2023 (please sign your comments with ~~~~)‎

The advice always given to me is "never let the perfect be the enemy of the good enough". Though I tend to bounce between being so obsessive, that I don't realise that I'm now gilding the lilly, or hastily kludging it because of the need for an immediate workaround, knowing that if it needs looking at again then I'll be doing it later anyway and that's when I'll get my gilding gear ready. (Hence why I'm 'always' being told that phrase. But I suspect that there really is no sweet spot between too little and too much, or at least no single keystroke at which I would earn universal praise for my finely balanced tenacity and moderation upon the handling of the issue. Always critics!) 172.70.86.28 17:19, 27 January 2023 (UTC)

At least at a corporate level, I suspect this phenomenon has an extremely simple explanation. When your code is high-quality, people often won't even realize they are using and interacting with it, because it just does what it's supposed to. When your code is hackish, you and your coworkers will constantly find it breaking seemingly unrelated stuff, forcing them to go back to it over and over, trying to make it work, only to discover it breaks even more things when they try to fix it.
Your high-quality code is still interacting with those seemingly unrelated things, it's simply not breaking the unrelated things, so you don't notice it's interacting with the seemingly unrelated things.172.69.68.97 16:32, 27 January 2023 (UTC)

This also reminds me of 2347: Dependency where a single project made in 1990 has become the backbone of so many other applications. 172.71.151.100 17:47, 27 January 2023 (UTC)

I won't do the edit myself (because I'm shy), but here is how the comic rings to me (from my own current experience): - Often in dev, there are many daily repetitive tasks that are annoying (i.e., build-test-lint-commit-push). These get automated out of spite by someone in a quick'n'dirty way, just to make life easier. It has a limited audience (the development team), but lives on forever, since it is used daily (and therefore maintained accordingly). - On the other hand, the stuff the team codes and sells is subject to changing requirements (cf. next release, marketing, ...). So it gets overhauled often, all the more easily because developers are not familiar with it (because they don't use it, and they worked on some other part of the project). There is also the fact that there is no budget for making changes on the tools, as opposed to the product, so no one really has time to refactor the former - that's how it lives so long! ~~Aveheuzed~~

The never ending war between "I don't have the time to do this right", and "this is way too complex for our simple needs" is exactly where this comic lives. The reality of programming is that general solutions are great for saving time writing, but are often bloated (with unneeded options), miss edge cases, or introduce extra dependencies and slow downs. plus the whole "not invented here" thing coupled with licensing headaches means this will probably still be a thing in a hundred years. PS I think the person explaining missed the point of the order in which the title text options are presented >.> 172.70.206.150 18:19, 27 January 2023 (UTC)

I took it to mean if you say it's fine it isn't (thinking of Murphy and that it's fine fire cartoon here) and if you worry that it isn't it will usually be. Jinx. That's the word I was looking for.18:40, 27 January 2023 (UTC)

Circa 1969, "Surely 16 bits will be enough for a timestamp, it won't break until the year 2000. Who knows if it will still be around by then." Circa 1998, "Surely 32 bits will be enough for a timestamp, it won't break until the year 2038. Who knows if it will still be around by then." But to be fair, while Unix has outlasted one of it's major contributors (Dennis Ritchie, RIP), it was designed with best practices to encourage reuse. Rtanenbaum (talk) 18:58, 27 January 2023 (UTC)