The most misunderstood statement in all of programming by a wide margin.
I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context.
Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment. I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things.
> I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things.
Similar to the "code should be self documenting - ergo: We don't write any comments, ever"
> Similar to the "code should be self documenting - ergo: We don't write any comments, ever"
My counterpoint: Code can be self-documenting, reality isn't. You can have a perfectly clear method that does something nobody will ever understand unless you have plenty of documentation about why that specific thing needs to be done, and why it can't be simpler. Like having special-casing for DST in Arizona, which no other state seems to need:
In particular I've seen way too many people use this term as an excuse to write obviously poor performing code. That's not what Knuth said. He never said it's ok to write obviously bad code.
I'm still salty about that time a colleague suggested adding a 500 kb general purpose js library to a webapp that was already taking 12 seconds on initial load, in order to fix a tiny corner case, when we could have written our own micro utility in 20 lines. I had to spend so much time advocating to management for my choice to spend time writing that utility myself, because of that kind of garbage opinion that is way too acceptable in our industry today. The insufferable bastard kept saying I had to do measurements in order to make sure I wasn't prematurely optimizing. Guy adding 500 kb of js when you need 1 kb of it is obviously a horrible idea, especially when you're already way over the performance budget. Asshat. I'm still salty he got so much airtime for that shitty opinion of his and that I had to spend so much energy defending myself.
When it comes to frameworks (any framework) any jargon not explicitly pointing to numbers always eventually reduces down to some highly personalized interpretation of easy.
It is more impactful than it sounds because it implicitly points to the distinction of ultimate goal: the selfish developer or the product they are developing. It is also important to point out that before software frameworks were a thing the term framework just identifies a defined set of overlapping abstract business principles to achieve a desired state. Software frameworks, on the other hand, provide a library to determine a design convention rather than the desired operating state.
Honestly, if you really have to ask the question then none of this matters because it sounds like you are already delegating your career to AI which would make this list unapproachable.
Do the boring parts first. I mean this seriously. You need to build personal routines of accomplishment for the more administrative tasks. Some of that can be worked in parallel with other things.
You cannot teach life skills using games unless the game is explicitly designed to terminate and delete all play data the moment user persistence degrades, and the game cannot have a pause function.
The real answer, that came out only last week, is that everybody in Trump’s administration, with possible exception to Hegseth, strongly advised against attacking Iran regardless what Israel says. Trump chose to attack Iran believing regime change was probable despite all guidance, from his administration, that it was not possible without a ground invasion.
Holy fuck, another young person give up on life thread.
Yes, as a software developer you will still need to learn to write software. The most important skill learned from this, speaking from 20 years experience writing open source and corporate software and 30 years military, is systems of organization. Call it architecture if you want. You won’t know how to put the Lego pieces together until you have done it yourself many different times.
AI can write software for you, as can a rookie, but only an experienced developer can determine what’s crap and how to do it better according to evidence.
So I guess when employers force AI use by their developers those developers progress towards worthlessness in that they will produce wrong code, not know the difference, not care about the resulting harm, and finally not even try to course correct if AI is removed.
This sounds like something I have seen before: jQuery, Angular, React.
What the article misses is the consequence of destroyed persistence. Once persistence is destroyed people tend to become paranoid, hostile, and irrationally defensive to maintain access to the tool, as in addiction withdrawal.
My experience is that people cannot copy original ideas for two reasons:
1. People generally fear originality until it receives sufficient social validation, but by then your business is established.
2. People generally cannot copy anything original after a certain point of complexity without motivation well into unnatural territory. For example nobody is going to quit their jobs to replicate your unproven idea because the effort is too high for something completely unused.
A rare exception to those two points is Minecraft. They replicated the idea of a sci-fi voxel game from scratch, changed the scenery, and kept in beta for years.
I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context.
Here ya go: https://dl.acm.org/doi/10.1145/356635.356640
Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment. I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things.
reply