> duplication is actually reducing cognitive load, because the “chunk” is self-contained
I've been thinking about that and I'm still not convinced. In my experience most of the time duplicate code increases cognitive load because every time I suspect a block of code is duplicate I have to go back and check if the other duplicate places do exactly the same thing or something slightly different. Just as DRY can be abused, PRY will be as well, and I'm afraid the consequences will be worse than the consequences of DRY abuse.
I don't buy it either. At least not as a blanket statement.
For a simple expression as shown here, sure, I'll buy it, PRY away.
For a block of 20 lines of code, I think most would agree to move that to a function, if the alternative was to paste it in many different places in your codebase, especially if a change to one copy would require the same change to the other copies.
So the boring answer is there's no simple answer - it depends. The more interesting question to consider then is how you can tell when to DRY and when to PRY.
Well, let’s say you have a task that requires performing a specific set of transactions. You’ve noticed that the code you need to use is duplicated in several places, and you’re not sure which version is the most up-to-date or actively used one. Different developers might have added extra logic to different copies, making them diverge over time. As a developer, you want to use the most valid and reliable version, but figuring that out takes time — just as Célio mentioned earlier.
> One thing to not take from Linus’s point: the tone and general rudeness.
Yeah, beat me to it. I've seen him have other outbursts in the past, and frankly it's disappointing. I'm not involved with the Linux project, but if I was, I'd be sure to avoid him because of behavior like this.
>I'd be sure to avoid him because of behavior like this.
I think that's the intended effect. The cost of being nicer is that it both takes more time to word things tactfully since you need to think more deeply about how your words will be interpreted, and also, you'll encourage people to ask for your time more.
Now for most of us, our time and experience isn't actually so valuable that we need to be so careful about protecting our time, so there's really no excuse to be rude. However, I think it actually makes sense to make an exception for Linus because his time is incredibly valuable, and him being rude means people will think twice next time they ask for his time, and spend more of their own time making sure they're presenting him something high quality when asking for his time.
That's not saying that anyone else should act like him. If you ask yourself if your expertise and time is anywhere near as valuable as Linus Torvalds the answer is going to be no 99.999% of the time. But, I think there's a valid argument for him specifically to act this way to protect his time.
I never liked the vibe of "this person is so important that they get to play by different rules". In the immortal words of the philosopher Carlin: "Let's not have a double standard, one standard will do just fine".
There are plenty of ways to say "no" without belittling the other person or making them feel unwelcome. Because when we do such things, it isn't just the recipient that sees them, it's countless others. And that burns goodwill.
It only takes a second to paste your rude draft into an LLM and ask for a more polite version. If someone is rude nowadays it’s because they mean to be rude.
Have you ever stopped to consider what led to this? When you build the world's most effective kernel, you encounter unbelievable amounts of challenges and when you do it in the open, many people are contributing. From your perspective it may not "cost" anything to be nice, but being nice about it means that it WILL happen again from other contributors. The amount of contributors to the Linux kernel is. Over 20,000 individual contributors have made changes to the Linux kernel. While it's not "polite" the fact that this is being shared as a monetized story means that it's getting passed around. A lot of people will see it, and rethink their notions about abstractions. If he just said "You need to remove these abstractions because they are creating too much cognitive load to determine what the word order is, the feedback would go largely unnoticed by the community at large. The IS plenty of code that is garbage, and we've all seen it.
Further, you cannot work on the Linux project and "avoid" Linus. It's his project. He's been overseeing it for over 30 years, and he takes a very active role in reviewing and merging. His leadership and oversight have led to this being one of the most successful software projects in the history of mankind. It will be talked about for the next hundred years. He hasn't been the "nicest" guy but also, many of those "nicest guy" types would be unable to manage such a project. Being the "nice guy" here means suffering through more of the same issue again and again, like groundhog day.
The Linux project is his own, Linus' project. If you want to get involved in his project you play by his rules, and his rules include being publicly berated for bad commits like Linus Torvalds does it. I believe he does it like that for a good reason - he prevents low code quality by incurring high cost (penalizing) of commiting bad code to his project.
Sad to say, but I agree on this one. The Linux project is possibly the most successful open source project in software History, where everybody would be proud to participate, even if only to fix a typo. I don't see alternatives, unfortunately.
If this was a junior dev that he was directly managing and this was a private conversation, yes, his tone should have been calmer and that of a mentor and leader. But he's a public personality, this was random contributor, and this was a public conversation.
Therefore, he needs to set boundaries strongly for all to see - both because otherwise he'll get pushed around endlessly, and because the only way to fix the the problem at scale is to be loud and create ripples.
No one would be talking about this if he was a teddy bear about it. The cost of teaching tens of thousands was upsetting one discourteous dev's afternoon. Price well paid.
If you want someone to actually fix something they’ve done wrong, you need to point it out objectively—separating the issue from the person—so they don’t feel personally attacked. The “sandwich” method works best in these situations. The moment someone feels attacked, they stop learning and just get defensive. Especially when working with a team, it’s important to build the skill of giving constructive criticism without sounding harsh or harassing, even if the feedback is only going to be seen by that one person.
> Being rude makes committing code a risk. Nobody wants to write code and risk the chance of being berated publicly like above.
That’s actually the point of why he’s rude. He probably doesn’t want to work with people that send him garbage PRs late in the merge window. His incentives are aligned.
Besides the awful tone, I don't even fully agree with the original statement.
The question `make_u32_from_two_u16()` vs. `(a << 16) + b` and potentially a cast is fundamental but can easily be debated from either side.
"Maybe you need to add a cast to make sure that 'b' doesn't have high bits" It sounds like the "maybe" modifier here is stretching it, and that he omitted it on purpose to better sell his perspective. Write it out with the cast, then compare it.
"it's not going to be exactly pretty, but it's not going to be wrong and incomprehensible either." I'd argue that pretty and comprehensible are related in SE.
"you have not a f^%$ing clue what the word order is" True. There are ways around that. Can they be considered extra work or mental overhead? Maybe, maybe not.
I understand why Torvalds thinks he is right, I just don't think this is clear-cut or egregious enough to warrant such an emotional response.
Not code related, but this was submitted *during* the merge window. It goes along with the rudeness point, but the submitter followed instructions, and then was criticized for it. If it was too late, the merge window shouldn't have been opened.
Was in the army before engineering, as long as I trust he got my beat interest in mind, I prefer directness and sincerity over fake niceness… though probably has more to do with my eastern european heritage over anything
- Being polite and respectful is not about being nice, it's about being a decent human being
- You don't have to be an asshole to be sincere.
Do you talk to your mother, or your kids, the same way when you're being sincere? ... This kind of behavior is never warranted and creates nothing but negativity in the world.
I've seen this problem arise a lot from engineers who are too extreme with principles like DRY or with Clean Code. If you follow those practices to the nth degree then you can take something that could have been expressed in one function, and express it in 7 classes, 12 files, 3 sub-directories, some interfaces/abstract classes, ... There's always a balance to be had. Sometimes DRY is good, sometimes PRY is good. IMO knowing when to use which is what separates an experienced software engineer (e.g. principal engineer) from a junior.
I also very much agree that the way Linus expresses himself is just poor. But his sentiments are usually correct. I thought he'd got a lot tamer in recent years, but clearly he's still at it. Poor psychological safety will deter contributors and only hurt open source. It's possible to give feedback, train/educate people, but not make them feel like crap.
Linus strong personality drove him to create one of the most thriving projects in the history of software engineering. He can be nicer but that nicer quality wouldn't have driven him to create linux. Though he is not nice we all benefit from his creation.
Very cool. I am not an engineer but a researcher and financial modeler who used to have to write a ton of reusable code that would be maintained by others.
I invested a lot of thought in “clean code” and read the famous book of that name.
I always struggled with whether to optimize readability (which prioritizes self-containment and sometimes duplication) and modularity (which supports maintenance as long as someone understands the structure). They are clearly competing goals, but sometimes too much duplicated junk impedes readability.
In today’s world of tabbed editors, multiple files never reduces readability, so I differ with Torvalda there.
I don’t read it the same way personally. I understand Linus’ comment as: this function is a wrong abstraction, as it requires reading the code of the function to understand what it does (here: word order). It has nothing to do with cognitive load.
Most of the code is read much more than it's re/written, yet code reading and comprehension is usually not top consideration. Among the few on top - but usually not #1. Documentation is necessary but not sufficient. That code should be written with the reader in mind, as much as it is written with the compiler and cpu in mind. Especially when it costs almost nothing to make the code reading friendly. When I join a new team, there maybe few millions of code already. I will contribute some thousands too - but a lot more reading goes on, especially to start with. Code Reading by Venables & Spinellis is one of the rare books that I know that discusses this. Another related (the accent is adjacent to code reading) is Steve Maguire's "Writing Solid Code" is the rare book that is both practical and abstract in the right amounts for - among other things - code readability.
OK I get the part where code should reduce cognitive load, but I don't get how it is a good example of this. Being more of a business logic scripter than a wizard programmer, I do not know the << operation. But that nice long function name I like, it tells me what it does. I like to do such things. Relatively verbose code, verbose about what it does is what I call self-documenting. If you see a random <<, how do you know what is the purpose? But if it tells you it is converting two 16 bit words to one 32, that tells you what it does. I absolutely love working with libraries that are full of long function names, it feels like I am writing an essay, not something "tech". Same with long variable names. Fuck a and b.
Code I find readable looks a lot like price_with_tax = price_without_tax * percentage_to_multiplier(tax_rate) where the percentage_to_multiplier function is 1+(percentage/100), I really like these very readable helpers, they do reduce my cognitive load.
> duplication is actually reducing cognitive load, because the “chunk” is self-contained
I've been thinking about that and I'm still not convinced. In my experience most of the time duplicate code increases cognitive load because every time I suspect a block of code is duplicate I have to go back and check if the other duplicate places do exactly the same thing or something slightly different. Just as DRY can be abused, PRY will be as well, and I'm afraid the consequences will be worse than the consequences of DRY abuse.
I don't buy it either. At least not as a blanket statement.
For a simple expression as shown here, sure, I'll buy it, PRY away.
For a block of 20 lines of code, I think most would agree to move that to a function, if the alternative was to paste it in many different places in your codebase, especially if a change to one copy would require the same change to the other copies.
So the boring answer is there's no simple answer - it depends. The more interesting question to consider then is how you can tell when to DRY and when to PRY.
Why do you have to go and check that whether the other duplicates are doing same thing or slightly different?
Well, let’s say you have a task that requires performing a specific set of transactions. You’ve noticed that the code you need to use is duplicated in several places, and you’re not sure which version is the most up-to-date or actively used one. Different developers might have added extra logic to different copies, making them diverge over time. As a developer, you want to use the most valid and reliable version, but figuring that out takes time — just as Célio mentioned earlier.
Exactly. If it works why go touch it.
If you have to edit many lines because of one single change due to duplication then yes you need to touch it.
> One thing to not take from Linus’s point: the tone and general rudeness.
Yeah, beat me to it. I've seen him have other outbursts in the past, and frankly it's disappointing. I'm not involved with the Linux project, but if I was, I'd be sure to avoid him because of behavior like this.
Dude needs to be kind and rewind.
>I'd be sure to avoid him because of behavior like this.
I think that's the intended effect. The cost of being nicer is that it both takes more time to word things tactfully since you need to think more deeply about how your words will be interpreted, and also, you'll encourage people to ask for your time more.
Now for most of us, our time and experience isn't actually so valuable that we need to be so careful about protecting our time, so there's really no excuse to be rude. However, I think it actually makes sense to make an exception for Linus because his time is incredibly valuable, and him being rude means people will think twice next time they ask for his time, and spend more of their own time making sure they're presenting him something high quality when asking for his time.
That's not saying that anyone else should act like him. If you ask yourself if your expertise and time is anywhere near as valuable as Linus Torvalds the answer is going to be no 99.999% of the time. But, I think there's a valid argument for him specifically to act this way to protect his time.
I never liked the vibe of "this person is so important that they get to play by different rules". In the immortal words of the philosopher Carlin: "Let's not have a double standard, one standard will do just fine".
There are plenty of ways to say "no" without belittling the other person or making them feel unwelcome. Because when we do such things, it isn't just the recipient that sees them, it's countless others. And that burns goodwill.
It only takes a second to paste your rude draft into an LLM and ask for a more polite version. If someone is rude nowadays it’s because they mean to be rude.
You’re talking about someone who created an operating system because the existing ones didn’t meet his needs.
Within 25 or 30 years, his system became the standard that keeps the internet running.
I think that, when it comes to code, he can respond to anyone however he wants.
The only possible reply from the other person is: “thank you.”
"Rules for thee but not for me" is a really bad take.
Who publicized this PR? Does anyone know?
Have you ever stopped to consider what led to this? When you build the world's most effective kernel, you encounter unbelievable amounts of challenges and when you do it in the open, many people are contributing. From your perspective it may not "cost" anything to be nice, but being nice about it means that it WILL happen again from other contributors. The amount of contributors to the Linux kernel is. Over 20,000 individual contributors have made changes to the Linux kernel. While it's not "polite" the fact that this is being shared as a monetized story means that it's getting passed around. A lot of people will see it, and rethink their notions about abstractions. If he just said "You need to remove these abstractions because they are creating too much cognitive load to determine what the word order is, the feedback would go largely unnoticed by the community at large. The IS plenty of code that is garbage, and we've all seen it.
Further, you cannot work on the Linux project and "avoid" Linus. It's his project. He's been overseeing it for over 30 years, and he takes a very active role in reviewing and merging. His leadership and oversight have led to this being one of the most successful software projects in the history of mankind. It will be talked about for the next hundred years. He hasn't been the "nicest" guy but also, many of those "nicest guy" types would be unable to manage such a project. Being the "nice guy" here means suffering through more of the same issue again and again, like groundhog day.
There are plenty of nice ways to say "no" and "not happening" without yelling profanities at people.
I love the Linux kernel, but the world would be a better place if it were worse and he were better.
Disagree. "Nice" men never make history.
Disagree.
Gandhi, Mandela, and Martin Luther King Jr. changed the course of humanity through empathy, not ego.
Being nice doesn’t mean being weak - it means being strong enough to stay kind when power tempts you otherwise.
The Linux project is his own, Linus' project. If you want to get involved in his project you play by his rules, and his rules include being publicly berated for bad commits like Linus Torvalds does it. I believe he does it like that for a good reason - he prevents low code quality by incurring high cost (penalizing) of commiting bad code to his project.
Sad to say, but I agree on this one. The Linux project is possibly the most successful open source project in software History, where everybody would be proud to participate, even if only to fix a typo. I don't see alternatives, unfortunately.
>"And sending a big pull request the day before the
merge window closes in the hope that I'm too busy to care is not a
winning strategy."
This was the key part here. Linus was absolutely right to tear him a new one.
If this was a junior dev that he was directly managing and this was a private conversation, yes, his tone should have been calmer and that of a mentor and leader. But he's a public personality, this was random contributor, and this was a public conversation.
Therefore, he needs to set boundaries strongly for all to see - both because otherwise he'll get pushed around endlessly, and because the only way to fix the the problem at scale is to be loud and create ripples.
No one would be talking about this if he was a teddy bear about it. The cost of teaching tens of thousands was upsetting one discourteous dev's afternoon. Price well paid.
If you want someone to actually fix something they’ve done wrong, you need to point it out objectively—separating the issue from the person—so they don’t feel personally attacked. The “sandwich” method works best in these situations. The moment someone feels attacked, they stop learning and just get defensive. Especially when working with a team, it’s important to build the skill of giving constructive criticism without sounding harsh or harassing, even if the feedback is only going to be seen by that one person.
> Being rude makes committing code a risk. Nobody wants to write code and risk the chance of being berated publicly like above.
That’s actually the point of why he’s rude. He probably doesn’t want to work with people that send him garbage PRs late in the merge window. His incentives are aligned.
So he favors the brave, not necessarily the better
Besides the awful tone, I don't even fully agree with the original statement.
The question `make_u32_from_two_u16()` vs. `(a << 16) + b` and potentially a cast is fundamental but can easily be debated from either side.
"Maybe you need to add a cast to make sure that 'b' doesn't have high bits" It sounds like the "maybe" modifier here is stretching it, and that he omitted it on purpose to better sell his perspective. Write it out with the cast, then compare it.
"it's not going to be exactly pretty, but it's not going to be wrong and incomprehensible either." I'd argue that pretty and comprehensible are related in SE.
"you have not a f^%$ing clue what the word order is" True. There are ways around that. Can they be considered extra work or mental overhead? Maybe, maybe not.
I understand why Torvalds thinks he is right, I just don't think this is clear-cut or egregious enough to warrant such an emotional response.
Linus's behavior is outrageous and absolutely unjustifiable. I don't like people who take every little thing personally.
Not code related, but this was submitted *during* the merge window. It goes along with the rudeness point, but the submitter followed instructions, and then was criticized for it. If it was too late, the merge window shouldn't have been opened.
🤷
Was in the army before engineering, as long as I trust he got my beat interest in mind, I prefer directness and sincerity over fake niceness… though probably has more to do with my eastern european heritage over anything
- Being polite and respectful is not about being nice, it's about being a decent human being
- You don't have to be an asshole to be sincere.
Do you talk to your mother, or your kids, the same way when you're being sincere? ... This kind of behavior is never warranted and creates nothing but negativity in the world.
I've seen this problem arise a lot from engineers who are too extreme with principles like DRY or with Clean Code. If you follow those practices to the nth degree then you can take something that could have been expressed in one function, and express it in 7 classes, 12 files, 3 sub-directories, some interfaces/abstract classes, ... There's always a balance to be had. Sometimes DRY is good, sometimes PRY is good. IMO knowing when to use which is what separates an experienced software engineer (e.g. principal engineer) from a junior.
I also very much agree that the way Linus expresses himself is just poor. But his sentiments are usually correct. I thought he'd got a lot tamer in recent years, but clearly he's still at it. Poor psychological safety will deter contributors and only hurt open source. It's possible to give feedback, train/educate people, but not make them feel like crap.
Linus strong personality drove him to create one of the most thriving projects in the history of software engineering. He can be nicer but that nicer quality wouldn't have driven him to create linux. Though he is not nice we all benefit from his creation.
Very cool. I am not an engineer but a researcher and financial modeler who used to have to write a ton of reusable code that would be maintained by others.
I invested a lot of thought in “clean code” and read the famous book of that name.
I always struggled with whether to optimize readability (which prioritizes self-containment and sometimes duplication) and modularity (which supports maintenance as long as someone understands the structure). They are clearly competing goals, but sometimes too much duplicated junk impedes readability.
In today’s world of tabbed editors, multiple files never reduces readability, so I differ with Torvalda there.
I don’t read it the same way personally. I understand Linus’ comment as: this function is a wrong abstraction, as it requires reading the code of the function to understand what it does (here: word order). It has nothing to do with cognitive load.
Most of the code is read much more than it's re/written, yet code reading and comprehension is usually not top consideration. Among the few on top - but usually not #1. Documentation is necessary but not sufficient. That code should be written with the reader in mind, as much as it is written with the compiler and cpu in mind. Especially when it costs almost nothing to make the code reading friendly. When I join a new team, there maybe few millions of code already. I will contribute some thousands too - but a lot more reading goes on, especially to start with. Code Reading by Venables & Spinellis is one of the rare books that I know that discusses this. Another related (the accent is adjacent to code reading) is Steve Maguire's "Writing Solid Code" is the rare book that is both practical and abstract in the right amounts for - among other things - code readability.
OK I get the part where code should reduce cognitive load, but I don't get how it is a good example of this. Being more of a business logic scripter than a wizard programmer, I do not know the << operation. But that nice long function name I like, it tells me what it does. I like to do such things. Relatively verbose code, verbose about what it does is what I call self-documenting. If you see a random <<, how do you know what is the purpose? But if it tells you it is converting two 16 bit words to one 32, that tells you what it does. I absolutely love working with libraries that are full of long function names, it feels like I am writing an essay, not something "tech". Same with long variable names. Fuck a and b.
Code I find readable looks a lot like price_with_tax = price_without_tax * percentage_to_multiplier(tax_rate) where the percentage_to_multiplier function is 1+(percentage/100), I really like these very readable helpers, they do reduce my cognitive load.
The ideal code just reads like an essay, imho.