Live data from Hacker News

Linus Torvalds: 'I Do No Coding Any More'

linux.slashdot.org

221–230 of 246 posts

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

#221

> 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 absolutely agree with you, but I'd like to point out that singling out "young programmers" here does not do this topic justice.

This also goes for certain programmers that have been in the industry for decades. And if you deal with one of those, you'll find that they are even less likely to change their practices, so I'll take an impressionable young programmer to convince any day of the week.

Of course, this topic extends to many other practices, such as using descriptive variable names, writing good comments and documentation (instead of the Captain Obvious approved ones), designing good APIs,…

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

#222
post #205

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

As a relatively young developer, I have to ask, are comments not a better place to document context? Commit messages are much less discoverable to me than comments when I'm looking at a piece of code. I usually put the "why" in comments and the "abstracted what" in commits. Enough info for someone to quickly rule whether or not a commit could have introduced a given bug, since that's usually what I'm looking for when…

It's different context. If you're explainig why you write a piece of code the way you do, a comment is most certainly helpful. If you're explaining, why you're changing it the way you do, that's where the commit message shines. That's not to say you can't do both for intricate problems. And there are certain things you'll likely don't want to see inside your codebase (like references to bug tracker IDs and so on), which are IMO perfectly fine in a commit message.

On the discoverability: Do you use `git blame` much? Because in projects that live a long time, that will most likely be the way you'll discover commit messages the most. And it is very handy in one of those WTF moments to see why and how a particular piece of code was altered, as opposed to "update" or "improve logic".

Also: On your notion of "abstract what": That's supposed to be your commit's subject line. The rest of the message then will be the "why". I like to think of it as an email to some future maintainer (e.g. me in a year) on why it was necessary to change a piece of code.

Edit: It's also important to see the differences workflow between your project and Linux, which Git was originally built for. In Linux, your change most likely is an email to some maintainer. If it sucks, your code won't be merged.

And there's something to be said about being able to vocalize your reason for changing code. I still get the impression that many people who riff on the "return on investment" part of commit messages don't factor in that you're very likely not understanding a problem if you cannot describe it readably in text.

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

#223

> 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've worked with 20yrs+ senior Devs whose commit message is always something like 1 or 2 words sentence (think of "cleanup", "feature X done") and some of there work manually with diff-tools between their local copy of code and the for repository they check out on a different folder. If they're not satisfied with the incoming changes, they just overwrite them and push the overwrite back to repository. This has happen…

> they just overwrite them and push the overwrite back to repository.

I'm not sure I understand what they're doing -- they overwrite some of the changes in their local working tree, and push to the repo, without explaining what they did/what they changed or why?

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

#224

Earlier quoted context omitted.

I've worked with 20yrs+ senior Devs whose commit message is always something like 1 or 2 words sentence (think of "cleanup", "feature X done") and some of there work manually with diff-tools between their local copy of code and the for repository they check out on a different folder. If they're not satisfied with the incoming changes, they just overwrite them and push the overwrite back to repository. This has happen…

> they just overwrite them and push the overwrite back to repository. I'm not sure I understand what they're doing -- they overwrite some of the changes in their local working tree, and push to the repo, without explaining what they did/what they changed or why?

Exactly. They keep a folder which isn't git-sync'ed (they fear the overwrites), then git pull on another folder and with graphic diff tools (e.g. Meld), they compare the changes. If they don't like the changes, they simply recopy the files from the non-sync'ed folder to the git folder and push it (a cherry pick would be too hard for them)

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

#225

I'm an academic (post-doc) and while I am about to transition, I've never really worked hard to get an actual tenure track position because honestly I don't want to become a grant writer who does so little actual scientific work, in all honesty. I might have to for my future's stability sake but I've been loathe to. I want to do science, not academia.

> I want to do science, not academia.

Don't get me wrong, I come from the same background you do and have similar wishes, but isn't this just "I want to do the things I like and not the things I don't" (which is true for anyone anywhere in any job)? Any job is going to have unliked things (that's why it's w.o.r.k and not f.u.n).

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

#226
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?

Which part of my answer gave the idea that this is about age?

FWIW, academia have never been good at teaching these skills, so the answer to your question is "You'll stop being junior with regards to refactoring complex code bases whenever you have enough experience of refactoring in big old code bases". Mentors pushing you in the right direction can also help. But this is very much a skill acquired by actually doing.

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

#227
post #107

Earlier quoted context omitted.

Spending time on commit messages that will be essentially removed when the PR is squashed seems... not very productive

And that’s why PR squashing is counter-productive. Good luck trying to track down an issue when bisect leads you to a 1500 line commit containing an entire feature. Repo commit history is an artifact the team produces, as much as the code it contains.

If you consistently have 1500 LOC PRs you are really doing PRs wrong. Our median PR is 150 LOC, altough we do rarely (a couple of times a year) have "jumbo" PRs of 1K-2K LOC, but making better individual commits is not going to help with understanding those. Those are the PRs that have extensive documentation and design consideration in the PR description.

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

#228

> 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 think the inexperienced developer simply hasn't had to personally dig through old commits/history to solve enough problems. There's likely a threshold (a 10000 hours type thing) where you've researched enough code history to value great commit messages and descriptions and docs/readmes, issue descriptions and comments etc. But how do we impart the importance of this to the other devs around us that will make it sti…

Maybe let them maintain a 20 years old project with unusual behavior and requirements, and nice helpful 20 years old commit messages?

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

#229

Am I the only one who's intensely jealous of Linus? I'm 34, I've been coding prolifically since I was 9, and by 20 I was running on fumes. That was probably the last time it was any fun. By now it's very hard to sustain anything remotely resembling motivation, especially having been around long enough to have been around the block with a few technology waves. This article, circulated on HN a while back, resonated wit…

Yep, same. I am supposed to be coding and writing Infrastructure as Code for cloud programs, but I find myself wishing I could be in Architecture or Design. I am an excellent facilitator of conversations and problem solving - I would love to "be in the room where it happens" and make sure we as a program have a coherent vision.

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

#230

Earlier quoted context omitted.

This is the typical trade off of management. You surrender low level control for higher level control and the ability to get more done overall (since you’re coordinating the labor of dozens of people).

But honestly, what Linus is doing strikes me as a much lower level than what we normally think of as the "management tradeoff". I mean, he's reviewing a ton of PRs, actually writing code in is email client as suggestions to patches. I see that as more of a "principal engineer" type role than an "engineering management" role.

He's also fulfilling the role typically handled by a product owner; he's deciding what features get prioritized. That has to be a pretty exhausting way to work.
Post reply on HN