Live data from Hacker News

Linus Torvalds: 'I Do No Coding Any More'

linux.slashdot.org

191–200 of 246 posts

Re: Linus Torvalds: 'I Do No Coding Any More'

#191
post #183

To think that [them] having made so much progress in the kernel by carrying a "Lean and Mean" profile for all of those decades is astounding! My guess is Linus is still L&M (if people didn't enjoy his lean, they wouldn't appreciate his mean), but perhaps he's not in his element right now (and just taking a breather). Either way, I'm a fan (not a professional) of a lean (looking) codebase with perhaps a new "overlay"…

You know that 'git blame' exists?

I guess the above was more about keeping the comments terse (at best) by default, rather than instituting an ambiguous or arbitrary formality.

The overlay thought was similar to the map concept, where you can load and toggle data layers (comments of various verbosity or from a dynamic source) easily.

Re: Linus Torvalds: 'I Do No Coding Any More'

#192
post #78
post #66

Earlier quoted context omitted.

An individual function can quite reasonably be 500 lines long. A giant case statement handling routing is one example. More controversially, if I am gong to need to do a lot of ugly compatibility hacks then I prefer to consolidate them and thus keep most functions clean.

Cyclomatic complexity is one of the more well-rigorously studied measure of code quality, I don’t know if I’d pick that hill to die on.

The average size of functions is independent of the programs total cyclomatic complexity.

Re: Linus Torvalds: 'I Do No Coding Any More'

#193
After having been paid for a few months to do upstreaming, I know very well that nobody close to the linux kernels is doing any 'coding' anymore.

it's seems to be more of an excercise into pleasing the priesthood to their, current, very important way/shape/form "canon" of what IS right at the moment than actually get any 'coding' done. And given the time it takes, i wonder if ANY of the top level maintainers actually program anymore, and are just "patch gateways".

And yes, there is a massive caste of priesthood of the patch series, discussing and making decisions on stuff they often borderline understand, and on criteria that are in fact quite far from the "it make sense" line of thinking.

I know, I've spend months re-writing drivers which were perfectly fine, neat, written with the upmost care of "upstreaming" as our team could figure out, to have to rewrite them completely and entirelly in the whim of someone halfway across the world, who didn't couldn't possibly have known what we were working on (as we were the designers, mostly) but who decided that version of the "canon" was not matching ours.

It's a stupid waste of time, money, brain cells, and the result is actually lesser than the original code.

For no good reason as the canon will change next year anyway.

For many years, I thought that the Linux kernel ecosystem was pretty much self-sufficient, but it's grown way too big, to the level of MASSIVE bloatware level nowadays. Massive corps have dozens of guys working on it, and many of them are also 'maintainers' -- full time; threading patches, some of them with conflicts of interest, or lack of understanding, or both, or just having been left behind a while back while still being innundated with patches.

I think it's doomed, in that form anyway.

Re: Linus Torvalds: 'I Do No Coding Any More'

#194
post #92

> commit messages to me are almost as important as the code change itself This is high on my list of code craftsmanship points. It's very difficult to explain to young programmers who have never worked on an old code base how valuable this is when done well. In fact, often you hear complaints about how a code base "is crap", but more often than not I'd wager this is just a result of the context at the time not being…

I write detailed commit messages for every single commit I make(even though commits would be squashed on merges), I write detailed PR descriptions that included before/after screenshots in multiple resolutions whenever relevant. Never once did I have any indication that someone took their time to read descriptions or commit messages. In my previous job, I received some feedback from my manager that some people compla…

[deleted]

Re: Linus Torvalds: 'I Do No Coding Any More'

#195
post #92

> commit messages to me are almost as important as the code change itself This is high on my list of code craftsmanship points. It's very difficult to explain to young programmers who have never worked on an old code base how valuable this is when done well. In fact, often you hear complaints about how a code base "is crap", but more often than not I'd wager this is just a result of the context at the time not being…

I write detailed commit messages for every single commit I make(even though commits would be squashed on merges), I write detailed PR descriptions that included before/after screenshots in multiple resolutions whenever relevant. Never once did I have any indication that someone took their time to read descriptions or commit messages. In my previous job, I received some feedback from my manager that some people compla…

I now write PRs descriptions and commit messages for my future self. I know that nobody in my Team reads them, it has happened to me that a question is asked and the answer was already in the description backed by a commit

Re: Linus Torvalds: 'I Do No Coding Any More'

#196

Earlier quoted context omitted.

Until you use squash and merge. Suddenly commit messages become far less helpful.

Yep, a good argument against squash and merge.

I guess it's an argument for and against it at the same time.

Re: Linus Torvalds: 'I Do No Coding Any More'

#197
post #155

Earlier quoted context omitted.

All the "code quality" people write shitty systems. You are too zoomed in if you think code quality is really important. It's kind of important, but your system likely has much more important things wrong with it than the "code quality". Things you could actually get fired for, or seriously reprimanded if the winds don't blow in your favor. Almost all "code quality" discussion in PRs is lightweight value judgements w…

Most of the code quality comments I make (and recieve) on PRs are about naming and comments, and they're mostly for future changes and maintenance. Good example from a couple days ago: someone made a helper method for compressing something, with the signature string Compress(string value) It was actually doing gzip followed by base64. My comment was to rename it to something like Base64Compress as well as change the…

People who don't care about code quality write brittle, hard-to-maintain systems - which is occasionally fine, depending on expected longevity of the system.

If you're interviewing for a job that involves any sort of maintenance over a long-lived project, organizational attitudes towards code quality are a useful smell test to how miserable it might get. I bear the scars of a couple of wholesale refactors (that cowboy coders wanted no part in, to no ones surprise) to improve readability/maintainability. Merging those gigantic PRs and having everything work was satisfying; it almost made up for the hair pulling. Also satisfying was catching a surprising number of hidden bugs caused by sloppy programming (some logical errors are obvious when you give functions, arguments and variables good names)

Re: Linus Torvalds: 'I Do No Coding Any More'

#200
post #187

Earlier quoted context omitted.

Why is the reason to peculiarity not in the comments in the code itself?

Comments aren't supposed to state the obvious and at the time it probably was. Commit messages are redundant by definition (everything said in the message is supposedly already there in the diff) so they are like magnets for stating the seemingly obvious.

> Commit messages are redundant by definition (everything said in the message is supposedly already there in the diff)

Commit messages are far easier to parse and understand compared to a moderate size diff. By reading the commit message before looking at the diff, it really helps in terms of understanding the context of the diff and what to expect.

Post reply on HN