Live data from Hacker News

Linus Torvalds: 'I Do No Coding Any More'

linux.slashdot.org

231–240 of 246 posts

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

#231

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.

In all seriousness -- why can't you move into architecture and design? I know it sounds a little trite, but I've seen many times where people don't do what they want or dream just because they haven't bothered to figure out how to get to their goal or simply because they don't let themselves. I know the world isn't always that simple, but I truly believe it is sometimes (plus some work and planning).

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

#232

Earlier quoted context omitted.

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

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

I agree, and I've found the same adding tests to existing code. It often uncovers bugs that have been there for years, and there's a certain schadenfreude from doing that.

Sometimes it turns out that the bug doesn't really occur only because that function never happens to be called in a certain way. I've also run into cases where when I'm trying to figure out how to reproduce the bug for real that I uncover a another bug that is blocking it. Both of these are examples of brittle code: the right change or separate bug fix is going to expose this, and hope your QA is good enough to find it.

I've also been able to identify and fix a couple long-standing bugs this way: the kind where it's been observed in production a handful of times and in more than one deployed environment, but no one had ever figured out reliable reproduction steps. It's a great moment when suddenly you realize all this crazy behavior can be fully explained.

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

#233
post #203

Earlier quoted context omitted.

I (and my team) always run an interactive rebase before opening PR. This gives us a chance to reorder, squash and cleanup individual “work in progress” commits into a logical set of atomic, meaningful commits, without turning the entire PR into a single commit.

On my team, we will open a PR with a logical set of commits. As reviews are posted, we will address those comments by using fixup! or squash! commits (using the title of the commit we want to amend). fixup commits are used for code changes and squash commits are used for commit message changes. In the end before merging, we'll run git fetch orgiin git rebase -i --autosquash --keep-empty origin/master git log -p --rev…

Thank you, learned something today :)

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

#234
post #227

Earlier quoted context omitted.

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.

I may exaggerate for effect, but 150LOC developed over two weeks is still vastly more surface area than a localized 5LOC change developed over the course of a few hours.

Of course circumstances vary and it depends on verbosity and idioms of your preferred language, framework and codebase. Maybe 150LOC is the minimum it takes to express a logical change unit.

My point is not about specific “maximum line count in a commit” but about a commit expressing a single logical change concept, and not a whole chapter of a book.

> making better individual commits is not going to help with understanding those … "jumbo" PRs of 1K-2K LOC.

This is where we disagree, it seems. You appear very categorical here, could you clarify why you think this is the case?

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

#235

Earlier quoted context omitted.

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.

In all seriousness -- why can't you move into architecture and design? I know it sounds a little trite, but I've seen many times where people don't do what they want or dream just because they haven't bothered to figure out how to get to their goal or simply because they don't let themselves. I know the world isn't always that simple, but I truly believe it is sometimes (plus some work and planning).

I have only been in my current role for a handful of months, and frankly, I need to put out more work to get the kind of creds I need to command legitimacy in a design role. Before, I spent years as a SME on a different set of technologies - in a non-pandemic world, I may drop back to that world and do consulting. Right now, though, I have a great team, a great manager, and decent pay, so given all the volatility in the world I am taking what I can get until I feel a bit safer moving around.

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

#236

Earlier quoted context omitted.

In all seriousness -- why can't you move into architecture and design? I know it sounds a little trite, but I've seen many times where people don't do what they want or dream just because they haven't bothered to figure out how to get to their goal or simply because they don't let themselves. I know the world isn't always that simple, but I truly believe it is sometimes (plus some work and planning).

I have only been in my current role for a handful of months, and frankly, I need to put out more work to get the kind of creds I need to command legitimacy in a design role. Before, I spent years as a SME on a different set of technologies - in a non-pandemic world, I may drop back to that world and do consulting. Right now, though, I have a great team, a great manager, and decent pay, so given all the volatility in…

That makes sense -- I guessed it more something like this. Thanks for the response.

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

#237
post #203

Earlier quoted context omitted.

On my team, we will open a PR with a logical set of commits. As reviews are posted, we will address those comments by using fixup! or squash! commits (using the title of the commit we want to amend). fixup commits are used for code changes and squash commits are used for commit message changes. In the end before merging, we'll run git fetch orgiin git rebase -i --autosquash --keep-empty origin/master git log -p --rev…

Thank you, learned something today :)

No problem :) One thing I forgot to mention about squash! commits was to use the --allow-empty flag when running git commit, so that we can make a commit without having to actually change any files.

Then, when doing the interactive rebase with the --autosquash and --keep-empty flags, you'll get to a point where your editor opens up with text saying that "this is a combination of X commits". At that point, you can delete the text down to the text of the last squash commit, exit the editor, and it will replace the commit message for the corresponding commit with the text that was in the squash commit message.

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

#238

Earlier quoted context omitted.

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

> 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) I agree, and I've found the same adding tests to existing code. It often uncovers bugs that have been there for years, and there's a certain schadenfreude from doing that. Sometimes it turns out that the bug doesn't really occur on…

> I've also run into cases where when I'm trying to figure out how to reproduce the bug for real that I uncover a another bug that is blocking it.

During a JS project refactor, I ran into a couple of those "This should be broken, why is it working?" headscratchers. In my case, 4 out of 5 times was that there was an earlier "quick-fix" further up the call-chain that papered over the bug for certain use-cases, but did not generalize well; I feel that that sort of bug is harder to catch using (unit) tests.

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

#239

Earlier quoted context omitted.

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

Sounds like annoying to get no feedback about one's changes

Thanks for explaining

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

#240

Earlier quoted context omitted.

"Supposed" to? Git was made with the intention that commit messages look like whole emails, describing not only why the change was made but also the thought process behind it, why this particular solution was chosen instead of some other etc. What you describe is a decent header, although most people would probably prefer "Add ability to" (not "Added ability to", this is a custom that goes way back before git). Inlin…

GitHub discourages making commit messages longer than a certain number of characters; it’s interesting for me to see other opinions on that.

Adding on to sibling comment, on GitHub the additional lines they're talking about go in the box before the commit title.
Post reply on HN