| ▲ | austin-cheney 5 hours ago |
| 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. 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. |
|
| ▲ | iamflimflam1 5 hours ago | parent | next [-] |
| > 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" |
| |
| ▲ | f1shy 4 hours ago | parent | next [-] | | It is to me incredible, how many „developers“, even “10 years senior developers” have no idea how to use a dubugger and or profiler. I’ve even met some that asked “what is a profiler?”
I hope I’m not insulting anybody, but to me is like going to an “experienced mechanic” and they don’t know what a screwdriver is. | | |
| ▲ | afpx 3 hours ago | parent | next [-] | | The last time I interviewed (around 10 years ago) I was surprised when 9 of the 10 senior developers didn't know how many bits were in basic elemetary types. (Then, shortly afterward I also tried to find a new job, realized the entire industry had changed, and was fortunate enough to decide it wasn't worth the trouble.) | | |
| ▲ | WalterBright 3 hours ago | parent | next [-] | | > 9 of the 10 senior developers didn't know how many bits were in basic elemetary types That's likely thanks to C which goes to great pains to not specify the size of the basic types. For example, for 64 bit architectures, "long" is 32 bits on the Mac and 64 bits everywhere else. The net result of that is I never use C "long", instead using "int" and "long long". This mess is why D has 32 bit ints and 64 bit longs, whether it's a 32 bit machine or a 64 bit machine. The result was we haven't had porting problems with integer sizes. | | |
| ▲ | switchbak 3 hours ago | parent | next [-] | | It's substantially worse on the JVM. One's intuition from C just fails when you have to think about references vs primitives, and the overhead of those (with or without compressed OOPs). I've met very few folks who understand the overheads involved, and how extreme the benefits can be from avoiding those. | | |
| ▲ | Quarrelsome 2 hours ago | parent [-] | | Conversely I've met many folks who come into managed environments and piss away time trying to wrangle the managed system into how they think it should work, instead of accepting that clever people wrote it and guidelines when followed result in acceptable outcomes. The sort of insane stuff I've seen on the dotnet repo where people are trying to tear apart the entire type system just because they think they've cracked some secret performance code. |
| |
| ▲ | afpx 3 hours ago | parent | prev [-] | | That's a reasonable answer. But, I meant they seemed to have little understanding or interest. I don't interview much, and I'm probably a poor interviewer. But, I guess I was expecting some discussion. | | |
| ▲ | WalterBright 3 hours ago | parent [-] | | I ran into some comp sci graduates in the early 80's who did not know what a "register" was. To be fair, though, I come up short on a lot of things comp sci graduates know. It's why Andrei Alexandrescu and I made a good team. I was the engineer, and he the scientist. The yin and the yang, so to speak. |
|
| |
| ▲ | SAI_Peregrinus 3 hours ago | parent | prev | next [-] | | How many bits are in an `int` in C? What do you mean "at least 16", that's ridiculous, nobody would write a language that leaves the number of bits in basic elementary types partially specified‽ | | |
| ▲ | bluGill 2 hours ago | parent [-] | | It is a good idea - most of the time you don't care, and on slower systems a large int is harmful since the system can't handle that much and it cost performance - go to the faster system with larger ints when you need larger intw. |
| |
| ▲ | ekidd 3 hours ago | parent | prev | next [-] | | I mean, as a senior developer, the number of bits in an "int" is "who the hell knows, because it has changed a bunch of times during my career, and that's what stdint.h is for." And let's not even talk about machines with 32-bit "char" types, which I actually had to program for once. If the number of bits isn't actually included right in the type name, then be very sure you know what you're doing. The senior engineer answer to "How many bits are there in an int?" is "No, stop, put that down before you put your eye out!" Which, to be fair, is the senior engineer answer to a lot of things. | |
| ▲ | estimator7292 2 hours ago | parent | prev [-] | | On the one hand, in today's world asking how many bits is in an int is exactly as answerable as "how long is a piece of rope" On the other, the right answer is 16 or 32. It's not the correct answer, strictly speaking, but it is the right one. | | |
| ▲ | jandrewrogers 2 hours ago | parent | next [-] | | An 'int' is also 64 bits on some platforms. | |
| ▲ | fragmede an hour ago | parent | prev [-] | | It's the wrong question. How many bits is uint64 is a much better question, if we're at a place where that's relevant. |
|
| |
| ▲ | didgetmaster an hour ago | parent | prev [-] | | I once interviewed at Microsoft. The hiring manager asked me how I would go about programming a break point if I were writing a debugger. I started to explain how I would have to swap out an instruction to put an INT 3 in the code and then replace it when the breakpoint would hit. He stopped me an said he was just looking to see if I knew what an INT 3 was. He said few engineers he interviewed had any idea. |
| |
| ▲ | alexjplant 2 hours ago | parent | prev | next [-] | | > "code should be self documenting It should be to the greatest extent possible. Strive to write literate code before writing a comment. Comments should be how and why, not what. > - ergo: We don't write any comments, ever" Indeed this does not logically follow. Writing fluent, idiomatic code with real names for symbols and obvious control flow beats writing brain teasers riddled with comments that are necessary because of the difficulty in parsing a 15-line statement with triply-nested closures and single-letter variable names. There's a wide middle ground where comments are leveraged, not made out of necessity. | | |
| ▲ | Sharlin an hour ago | parent [-] | | You misunderstood the GP - they were criticizing the way some programmers use "code should be self-documenting" as an excuse when they actually mean "I’m too lazy to write comments even when I really should". Just like "premature optimization is bad" may in fact mean something like "I never bothered to learn how to measure and reason about performance" | | |
| |
| ▲ | p0nce 4 hours ago | parent | prev | next [-] | | Laziness in moral clothing. | |
| ▲ | msla 5 hours ago | parent | prev [-] | | > 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: https://en.wikipedia.org/wiki/Time_in_the_United_States | | |
| ▲ | pc86 3 hours ago | parent | next [-] | | This isn't a counterpoint, it's just additional (and barely relevant) information. | | |
| ▲ | msla 3 hours ago | parent [-] | | It's a counterpoint to the maxim, not the post I'm replying to. |
| |
| ▲ | switchbak 3 hours ago | parent | prev [-] | | Documenting it in a way that ensures it satisfies the example case would be preferred. You know, like with a test. |
|
|
|
| ▲ | rkaregaran 4 hours ago | parent | prev | next [-] |
| (this is the correct answer, parent needs to understand this better) |
|
| ▲ | sandeepkd 3 hours ago | parent | prev | next [-] |
| This is crucial detail that almost everyone misses when they are skimming the topic on surface. The implication is that this statement/law is referenced more often to shut down the architecture designs/discussions |
|
| ▲ | dimitrios1 3 hours ago | parent | prev | next [-] |
| Even moreso . I like the Rob Pike restatement of this principle, it really makes it crystal clear: "You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is." Moreso, in my personal experience, I've seen a few speed hacks cause incorrect behavior on more than one occasion. |
|
| ▲ | Sammi 5 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | jcgrillo 4 hours ago | parent | next [-] | | Reminds me of a codebase that was littered with SQL injection opportunities because doing it right would have been "premature optimization" since it was "just" a research spike and not customer facing. Guess what happened when it got promoted to a customer facing product? | | |
| ▲ | Shorel 2 hours ago | parent | next [-] | | Now that's an stupid argument. I'm with you.
Removing SQL injection has little if anything to do with performance, so it is not an optimization. I guess we will get more of this with the vibe coding craze. | | |
| ▲ | fragmede 44 minutes ago | parent [-] | | We'll see. It's easy enough to ask Claude to red team and attack the system given the codebase and see what holes it finds to patch up. It's good enough now to find blatantly obvious shit like an SQL injection. |
| |
| ▲ | Quarrelsome 2 hours ago | parent | prev [-] | | tbf that's not their fault, as long as they were open about the flaws. Business should not have promoted it to a customer facing product. That's just org failure. | | |
| ▲ | jcgrillo 2 hours ago | parent [-] | | I disagree. If you merge code to main you immediately lose all control over how it will be used later. You shouldn't ever ship something you're not comfortable with, or unprepared to stake your professional reputation on. To do so is profoundly unethical. In a functioning engineering culture individuals who behave that way would be personally legally liable for that decision. Real professions--doctors, engineers, etc.--have a coherent concept of malpractice, and the legal teeth to back it up. We need that for software too, if we're actually engineers. | | |
| ▲ | Quarrelsome an hour ago | parent [-] | | Profoundly unethical? Ok so wtf is this formatting in your comment. You DARE comment, online where people can see, where you start a new sentence with two dashes "--". What are you thinking? Where's the professionalism? Imagine someone took that sentence and put it on the front of the biggest magazine in the world. You'd LOOK LIKE A FOOL. OR, perhaps its the case that different contexts have different levels of effort. Running a spike can be an important way to promote new ideas across an org and show how things can be done differently. It can be a political tool that has positive impact, because there's a lot more to a business than simply writing good code. However if your org is horrible then it can backfire in the way that was described. Maybe business are too aggressive and trample on dev, maybe dev doesn't have a spine, maybe nobody spoke up about what a fucking disaster it was going to be, maybe they did and nobody listened. Those are all organisational issues akin to an exploitable code base but embedded into the org instead of the code. These issues are not the direct fault of the spike, its the fault of the org, just like the idiot that took your poorly formatted comment and put it on the front page of Vogue. | | |
| ▲ | jcgrillo an hour ago | parent [-] | | Grammatical errors, formatting mistakes, or bad writing in general aren't something the magazine publisher can be held liable for, it may be embarrassing but it's not illegal or unethical. Publishing outright falsehoods about someone is though--we call that defamation. Knowingly shipping a broken, insecure system isn't all that different. Of course the people who came along later and chucked it into prod without actually reviewing it were also negligent, but that doesn't render the first guy blameless. | | |
| ▲ | Quarrelsome 42 minutes ago | parent [-] | | If it was only supposed to be a spike then it does render the first guy somewhat blameless. Especially if the org was made aware of the issues, which I imagine they were if someone had raised the issue of the exploits in the code base. I mean I could take a toddlers tricycle and try to take it onto the motorway. Can we blame the toy company for that? It has wheels, it goes forward, its basically a car, right? In the same way a spike is basically something we can ship right now. |
|
|
|
|
| |
| ▲ | f1shy 4 hours ago | parent | prev [-] | | That is the giat of the leftpad history, isn’t it? |
|
|
| ▲ | giancarlostoro 2 hours ago | parent | prev [-] |
| > except for those 10% of situations where you know in advance that crucial performance is absolutely necessary Yeah like, NOT indexing any fields in a database, that'll become a problem very quickly. ;) |
