Talk:2730: Code Lifespan - Revision history

172.70.90.141 at 09:16, 29 January 2023

2023-01-29T09:16:18Z

Hkmaly at 01:20, 29 January 2023

2023-01-29T01:20:02Z

172.69.34.112 at 17:02, 28 January 2023

2023-01-28T17:02:43Z

Xurkitree10 at 16:32, 28 January 2023

2023-01-28T16:32:40Z

NiceGuy1 at 05:29, 28 January 2023

2023-01-28T05:29:52Z

NiceGuy1 at 05:25, 28 January 2023

2023-01-28T05:25:39Z

172.71.242.11 at 19:05, 27 January 2023

2023-01-27T19:05:40Z

Rtanenbaum: UNIX Timestamp Issue

2023-01-27T18:58:11Z

UNIX Timestamp Issue

172.70.131.65 at 18:40, 27 January 2023

2023-01-27T18:40:08Z

172.70.206.150 at 18:19, 27 January 2023

2023-01-27T18:19:26Z

@@ Line 4: / Line 4: @@
 :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!) [[Special:Contributions/172.70.86.28|172.70.86.28]] 17:19, 27 January 2023 (UTC)
 ::Surely there is a sweet spot in the middle where you obsessively spent too much time trying to make the code better and yet it's still so bad you will need to replace it next time. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 01:20, 29 January 2023 (UTC)
 :On the contrary, there are perfectionists like myself who get a distinct satisfaction out of tweaking code to perfection, making it airtight, cover all conceivable bases. Make the code look clean, efficient, making sure it's fully commented... A lot of the joy in programming, for me, comes from this crap. :) [[User:NiceGuy1|NiceGuy1]] ([[User talk:NiceGuy1|talk]]) 05:25, 28 January 2023 (UTC)

@@ Line 3: / Line 3: @@
 <br />My own experience is that one loses the fun of programming something if the perfectionism plays to big of a role.{{unsigned ip|162.158.203.40|14:53, 27 January 2023}}‎
 :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!) [[Special:Contributions/172.70.86.28|172.70.86.28]] 17:19, 27 January 2023 (UTC)
 :On the contrary, there are perfectionists like myself who get a distinct satisfaction out of tweaking code to perfection, making it airtight, cover all conceivable bases. Make the code look clean, efficient, making sure it's fully commented... A lot of the joy in programming, for me, comes from this crap. :) [[User:NiceGuy1|NiceGuy1]] ([[User talk:NiceGuy1|talk]]) 05:25, 28 January 2023 (UTC)

@@ Line 20: / Line 20: @@
 :I took the (un)crossed combination as implicit, myself, as I read that version, dealt with prosaically in the follow-up paragraph, but I added the contrariwise statements (and preamble) to the end to make it perhaps more obvious as to the intended humour.
 :...on your earlier point, add "...I don't have time ''not'' to write it as a behemoth of a function, when I'm sure it could all boil down into a few lines that are far simple to understand and maintain". By incremental testing and putting together, you miss that you end up with something that basically has some common role such as "looks for the third non-digit character after every other colon, and returns the first full whitespace-delimitered word that follows on from that" in multiple different data-unmunging instances that all looked the right way to pick apart the necessary data at the time. With time, you can realise that this'ld go nicely into a singly-defined internal function which can be more easily commented, centrally maintained for immediate cross-code consistency, updated or even made more flexible by additional parameterisation (for when it occasionally needs to be the ''n''th non-digit character, etc) and... most importantly... give it a decent function name that does most of the work of commenting its own purpose wherever it appears. But that may takes time, and then they change the stream-format to some alternative that requires a new rewrite across the board. [[Special:Contributions/172.71.242.11|172.71.242.11]] 19:05, 27 January 2023 (UTC)
 I took it to mean if you say it's fine it isn't (thinking of Murphy and that

← Older revision		Revision as of 16:32, 28 January 2023
Line 26:		Line 26:

	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. [[User:Rtanenbaum\|Rtanenbaum]] ([[User talk:Rtanenbaum\|talk]]) 18:58, 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. [[User:Rtanenbaum\|Rtanenbaum]] ([[User talk:Rtanenbaum\|talk]]) 18:58, 27 January 2023 (UTC)
		+
		+	Should this be added to the Code Quality series? It fits the vibe and the title style too.[[User:Xurkitree10\|Xurkitree10]] ([[User talk:Xurkitree10\|talk]]) 16:32, 28 January 2023 (UTC)

@@ Line 3: / Line 3: @@
 <br />My own experience is that one loses the fun of programming something if the perfectionism plays to big of a role.{{unsigned ip|162.158.203.40|14:53, 27 January 2023}}‎
 :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!) [[Special:Contributions/172.70.86.28|172.70.86.28]] 17:19, 27 January 2023 (UTC)
-:On the contrary, there are perfectionists like myself who get a distinct satisfaction out of tweaking code to perfection, mak8ng it airtight, cover all conceivable bases. Make the code look clean, efficient, mak8ng sure it's fully commented... A lot of the joy in programming, for me, comes from this crap. :) [[User:NiceGuy1|NiceGuy1]] ([[User talk:NiceGuy1|talk]]) 05:25, 28 January 2023 (UTC)
+:On the contrary, there are perfectionists like myself who get a distinct satisfaction out of tweaking code to perfection, making it airtight, cover all conceivable bases. Make the code look clean, efficient, making sure it's fully commented... A lot of the joy in programming, for me, comes from this crap. :) [[User:NiceGuy1|NiceGuy1]] ([[User talk:NiceGuy1|talk]]) 05:25, 28 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.

@@ Line 17: / Line 17: @@
 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 >.> [[Special:Contributions/172.70.206.150|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. [[User:Rtanenbaum|Rtanenbaum]] ([[User talk:Rtanenbaum|talk]]) 18:58, 27 January 2023 (UTC)

← Older revision		Revision as of 18:58, 27 January 2023
Line 20:		Line 20:
	I took it to mean if you say it's fine it isn't (thinking of Murphy and that		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)		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. [[User:Rtanenbaum\|Rtanenbaum]] ([[User talk:Rtanenbaum\|talk]]) 18:58, 27 January 2023 (UTC)

← Older revision		Revision as of 18:40, 27 January 2023
Line 17:		Line 17:

	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 >.> [[Special:Contributions/172.70.206.150\|172.70.206.150]] 18:19, 27 January 2023 (UTC)		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 >.> [[Special:Contributions/172.70.206.150\|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)

← Older revision		Revision as of 18:19, 27 January 2023
Line 15:		Line 15:
	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!		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~~		~~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 >.> [[Special:Contributions/172.70.206.150\|172.70.206.150]] 18:19, 27 January 2023 (UTC)