No, it's more like saying "I judge an artist on my terms regardless of how well they sell on the market".
> artists on their end products, their overall vision, their motifs, their philosophy, and so on
The main output of programmer's work is their understanding of the system they work with, the rest comes from that. Behind the code there's its author's intention, vision, their tastes, philosophy and experience that makes them tackle problems in specific ways. Code review is, aside of quality assurance, mostly about communication between people, convincing them to your ways of doing things (or getting convinced by others) and communicating needs. It's what keeps projects running and what makes people improve their skills.
You don't need to see magnificence in code to realize that there's more to it than just the syntax tree to compile.
> No, it's more like saying "I judge an artist on my terms regardless of how well they sell on the market".
I feel like I need to push back here, because some of the best programmers around: Carmack, Torvalds, Johnathan Blow, even folks that make programming languages like K&R, Rob Pike, etc. are judged on their respective end products, not on minutia found in code reviews. For example, if I asked you "why do you think Stroustrup is a good programmer?"—you wouldn't cite some obscure optimization he came up with, but would rather talk about his overall vision for C++, his ideas of evolving C, his staunch anti-GC takes over the years (and their justification), etc.
You're contradicting yourself. First you say that they're judged on the end product, then you mention things that are very clearly not end products but thoughts and visions behind them that only lead to end products.
Frankly, I have no real idea of how good Carmack, Torvalds or Blow are as programmers, I have never worked with them so I don't really have a way to tell (even though I do contribute to Linux and I've seen some of their code). They're likely past a certain above-average threshold, but they haven't got famous for their programming skills.
That said, if you think Torvalds isn't being judged on "minutia found in code reviews", I'm not sure your take is very serious in the first place - that's the main thing he was being judged on for decades now :)
> you mention things that are very clearly not end products but thoughts and visions behind them that only lead to end products
Thoughts and visions are much more closely intertwined with end products (in fact, likely supercede them) than some random code review is, so I'm not seeing where the contradiction lies.
> that's the main thing he was being judged on for decades now
Linus hasn't written any code[1] in at least half a decade+. To argue that he's being judged on his code misunderstands why Linux became so popular to begin with.
Either I'm bad at communicating today or you're bad at reading, because you're now using my points, so I'm not sure what to make out of it. Let me repeat myself then:
> Code review is (...) mostly about communication between people, convincing them to your ways of doing things (or getting convinced by others) and communicating needs. It's what keeps projects running and what makes people improve their skills.
The way he does that is exactly what most news stories about Torvalds have been focusing on for many years now. In practice, unless you run a project alone, code review is where thoughts and visions surface up the most. Or, well, should be - not everyone is good at it.
(that said, even though my point is that's he's obviously not being judged on his code, you can easily find code that he wrote as late as this month, so your statement is clearly wrong even if that doesn't really influence the discussion here - code review is still the vast majority of his job, just like he stated there under your link)
> Either I'm bad at communicating today or you're bad at reading
Could be both :)
The way I look at it is like this, and you could call this my thesis: I do not categorically think that code in itself is primarily relevant to us looking at a "software engineer" and saying "wow, she's good." The product (the Linux kernel, in Torvalds' case) is, on the other hand, what actually matters. I think we're getting caught up on the idea of a code review; a code review can serve many purposes, as a code review is basically just people talking about the code, the product, their feelings, and so on. Sure, sometimes it's like "this `i` should be a `j`", but other times it's "this should serve feature X, not feature Y."
Overall, I don't think Torvalds is judged by his code quality. And the snippet I cited is the man himself saying "I don't write code anymore" so I took that at face value, even though my conviction stands wether or not he actually does still write code. I don't think anyone actually cared that much about his code quality (maybe with the caveat that the kernel didn't crash).
PS: I could be totally wrong, and this is an interesting & stimulating conversation, regardless.
Exactly. It looks like GP is guilty of the thing they accused others of - their understanding of what FLOSS is about is so shallow it resembles an aesthetic.
I’m not saying this is aligned with FLOSS, FLOSS is a collaboration model. I’m saying the outcome of easier access to knowledge should be celebrated by supporters of FLOSS. Licenses and copyright aren’t good for their own sake, they’re tools for increasing people’s freedom to use, study, modify, and build on existing software. LLMs are another tool for increasing people’s freedom to make new software or improve existing software.
See, that's exactly what I meant - you are indulged in the aesthetics. FLOSS is very obviously not a "collaboration model" (as evidenced by the whole variety of diverse collaboration models used by FLOSS projects), it's not about licenses and copyrights either; it's all about power dynamics - more specifically, not letting the software creator/distributor constrain their users in unjust ways. GNU GPL does not even require public distribution, it allows selling the software to limited recipients as long as you don't take these recipient's rights away. It's not about collaboration, it's not about being developed out in the open and it's not about preventing the siloing of knowledge aside of very specific contexts - it can be (and is being) used as a tool for pursuing, bettering or enabling each of those matters, but these are not its core concern at all.
You don't seem to understand what FOSS is really about. The GPL has always been about the user. When a company license-washes a existing GPL software project and turns it into a proprietory product, the resulting code is not "free" anymore in the sense that the user has lost control. This is exactly what the author wanted to prevent in the first place by licensing their code under the GPL.
In 2008 I've got a Neo Freerunner, a few years later a Nokia N900, then a Librem 5. So at least the last 18 years, I guess? We need to work hard for it to keep going though.
(well, unless we start to bikeshed on the exact meaning of "fully control")
That's a redefinition of the term - while there is some merit to your interpretation, it's an already commonly used term that means something else. It'd seem to me that the modern tech is significantly less "autistic" than it used to be in the prior decades and will only continue to move in this direction; and aside of that, I'm pretty sure Netcob's "modern" was meant to mean current thousands rather than tens of years.
Don't worry, the fact that you may be able to get something worth a dime out of these models if you really try does not yet mean you won't get flooded by slop from people who did not bother at all. The background noise is elevating rapidly and discerning signal from it takes more and more effort.
As much as I dislike this distribution model, this is a completely misapplied analogy. In npm with cooldowns case you "buy" a thing and get to use it instantly without any delay, it just won't get improved until a few days later - exactly as if the project you installed would use some timed staging channel for testing before making releases, except you're the one who controls the timing here.
> artists on their end products, their overall vision, their motifs, their philosophy, and so on
The main output of programmer's work is their understanding of the system they work with, the rest comes from that. Behind the code there's its author's intention, vision, their tastes, philosophy and experience that makes them tackle problems in specific ways. Code review is, aside of quality assurance, mostly about communication between people, convincing them to your ways of doing things (or getting convinced by others) and communicating needs. It's what keeps projects running and what makes people improve their skills.
You don't need to see magnificence in code to realize that there's more to it than just the syntax tree to compile.
reply