Live data from Hacker News

Linus Torvalds: 'I Do No Coding Any More'

linux.slashdot.org

151–160 of 246 posts

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

#151

> " in the end, my job is to say no. Somebody has to be able to say no to people. " This is funny to me, because I feel like Linux got ahead over BSD specifically because it had a more accepting policy in the beginning. I think this says something important about project maturity and lifecycle. BSD was already a "well established" system by the time the Linux kernel appeared, and as such had more gatekeeping to meet…

There was also the licensing/copyright controversy. It wasn't clear that BSD was really free until Linux was already taking off. From 1992-1994 there was a legal cloud over BSD and probably even after that people had lingering doubts that something like that could happen again. https://en.m.wikipedia.org/wiki/UNIX_System_Laboratories,_In... .

Ten years later, ironically enough, Linux encountered a similar fate: https://en.m.wikipedia.org/wiki/SCO_Group,_Inc._v._Internati.... ... and technically it’s not fully settled yet.

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

#152

> 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…

Head of Engineering with 15 years of experience here. If found that when we starting using Github flow, with pull-requests and etc, commit messages stopped really matter, in favour of PR descriptions. Plus when you use "squash" strategy, and use PR description as commit message, history looks great. When you look at commit history through Github tooling, all PR ids turned into links, and it is very easy watch for the…

You say that, and yet I have seen so many projects large and small transition between various code storage platforms and lose history of random ancillary conversations, due to how all of these tend to be locked up walled gardens of tools that prevent a useful "import" :/.

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

#153

Earlier quoted context omitted.

Commit messages are supposed to be short. "Fixed stuff" is totally wrong. I usually write "Added ability to do foo with bar when baz is true." Commit messages aren't mutually exclusive to the inline documentation. I am making the case that inline documentation is far more important than commit messages.

There's no general rule about what length a commit message should be, except that often people try to keep the first paragraph as a single short line for better readability in systems like GitHub and the git CLI. When additional detail is helpful about the motivation for or gotchas related to a commit, starting a new paragraph and elaborating there is totally fine. But I agree with you, they aren't mutually exclusive…

I was taught by a previous manager always to follow: `add/update/remove/fix {feature/bug} by/with {reason} ({further explanation if required})`

This also follows what I've seen at a few companies since then. Would you say that's a general rule?

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

#154
post #59

Earlier quoted context omitted.

Another thing those juniors are seldom good at, is knowing how to refactor an existing old code base. Which is not surprising, as everything they worked on during education is new code. Knowing how to change a code base from one abstraction to another is a skill that often take many years and lots of mistakes to learn.

Yet another boomer generalization designed to sow biases against hiring younger people. At what age am I allowed to become a senior, oh wise one?

The tech industry has a lot of problems, but bias against hiring younger people is not one of them.

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

#155
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…

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 with no rigor or consistency. Just what random bikeshedding objection that person happened to think of, maybe they had a bad night's sleep? Who knows...

Remnants of an era where most software was low stakes and had low number of users. We now have many more "-ilities" we are judged on, that are measurable and that actually matter, so ignore the code quality trolls stuck in 2005.

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

#156
post #34
post #6

Earlier quoted context omitted.

I've seen that useful commit message make it incredibly easy to see where the code came from and is going. It also never gets 'out of sync' like code comments tend to, as it's a comment on a static place in the code, not a dynamic one.

> It also never gets 'out of sync' like code comments tend to, as it's a comment on a static place in the code, not a dynamic one. That's simply not true, not in a git world where rebasing to rewrite history is standard practice.

I don't see how this can possibly be relevant to how relevant a commit message is.

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

#157
post #117

Earlier quoted context omitted.

I consider the version control history to be part of the code. I put docs into the source tree (sometimes in the form of comments; sometimes in dedicated doc files) for things that are suited to live next to the code, but often my commit messages contain more discussion of what used to be and why I chose a certain implementation approach. I generally think that documentation in code should describe what the code does…

Code tends to live longer than the VCS that stores it. I've seen more than one VCS migration that ended up losing a lot of the history of how things got to be where they are today.

Particularly if there's been a big refactor of the directory layout. The easiest way to do that is move the code and merge it, along with all the fixups needed, as a giant delete & add operation, and git won't necessarily figure it out.

With care, it's possible even to merge different git repos into a single repo while preserving history. But it takes care; it's not a pit of success.

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

#158
post #140

Earlier quoted context omitted.

How do you convince other people of this though? That's been what I've struggled with. I hate squashing too, but I can't convince anybody.

I like to remind people that pull requests are an abstraction over a set of commits. I show people that they can click on each individual commit in a PR and see the granular delta. Surprisingly often I’ve learned that people really don't know you can do this! If they argue that you cant revert entire features remind them that merge commits are a thing. If they don't like lots of merge commits littering the history su…

In practice, one should be doing -all of these things- in different circumstances.

Rebase and push -- along with some squashing of redundant work-- is great. There's some degree of annoyance if intermediate states don't build, so it requires care to know that all the individual between states are probably safe (because CI, etc, generally don't help you here).

Merge commits are fine, though they do require a higher degree of acumen for people exploring the history.

And there's plenty of times when a developer submits a moderate sized 3 commit PR that whoever looks at the pull can decide that it's better to squash and make into one commit.

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

#159

> 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…

definitely valuable for the linux kernel

for bob's old ERP software company, really won't make a difference

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

#160
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" commenting system being developed to accommodate a wide range of proficiency (one size fits all is either too terse or too bloated).

I am not sure of the difficulty of linking comments by line number between revisions, but outside of having an official repository of comments, being able to toggle through multiple perspectives from the same line/set of code would offer valuable insight and chronicle mindset/POV in a way that a global scratchpad could never deliver.

Writing terse or bloated comments should not be top of mind, but rather a frictionless byproduct (expect terse, but be pleasantly surprised on occasion by the detail and multiple perspectives).

Post reply on HN