Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds: 'I Do No Coding Any More'

linux.slashdot.org

Post reply on HN
Print view View original

101–110 of 246 posts

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

#101

Post by nemetroid »

tmh88j wrote: post #71
justapassenger wrote: post #54

Earlier quoted context omitted.

This so, so much. Too many people think that commit message is to explain HOW you did something. Unless you did something extremely clever (and in any commercial project, 99% of clever solutions are wrong - simple is the king), it should need more than few words. WHY you did it this way is the most important part. Given known and understood set of constrains, a lot of engineers will come up with similar solution, or…

>Too many people think that commit message is to explain HOW you did something. >WHY you did it this way is the most important part. What was done is better suited for the commit message than how and why it was done, in my opinion. The latter two are better explained by comments in the code. I agree that why something was done is important for future reference, but when I'm tracking down code changes I'm looking for…

Requirements change over time, and so do the "why"s. So unless the code base is your primary documentation for requirements, "why" comments in the code can be dangerous: while outdated "what" comments can be determined as such by reading the code, there is no way (from the code itself) to determine whether a "why" comment is still accurate.

A "why" comment in a commit message, on the other hand, only tells you what the "why" was at that time, something that cannot become outdated.

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

#102

Post by u801e »

secondcoming wrote: post #82
dasil003 wrote: post #26

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

Well, Linux's commit messages kind of have to be descriptive since Linux is an Open Source project that doesn't have (that I can see anyway) an issue tracker or other management tool. When you do have those, then it's the ticket that gives the why's and how's. The commit messages do not have to be essays. And, at least with JIRA, if you name your branch such that it starts with the ticket id, it automatically picks u…

> And, at least with JIRA, if you name your branch such that it starts with the ticket id, it automatically picks up any pushed commits for that ticket. It's very useful.

I've been working at my current place of employment long enough to see them transition between several different issue trackers. The links to old issue tracker tickets no longer resolve, so it's definitely better to include a description of the issue directly in the commit message in addition to the link to the issue tracker.

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

#103

Post by systemvoltage »

mrisoli wrote: post #92
dasil003 wrote: post #26

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

Yep, no one ever reads them and the cost to benefit ratio is extremely low.

Writing good comments is far more important. Don't explain what the code does - that's what the code is for, explain the why and the background information in the code. Additional, explain what the code does at the function level or at the module level - at a much higher abstraction level basically than the line of the code.

No one ever looks at the commit messages when trying to figure out what the code does as it convolves history and state of the repository, having to contextually wrap your head around when and how this commit was added.

Inline documentation? Perfect.

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

#104

Post by u801e »

teddyh wrote: post #60
dasil003 wrote: post #38

Earlier quoted context omitted.

This is a good start: https://chris.beams.io/posts/git-commit/

See also: • https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... • https://git.wiki.kernel.org/index.php/CommitMessageConventio...

This is another good reference: http://who-t.blogspot.com/2009/12/on-commit-messages.html

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

#105

Post by mister_hn »

dasil003 wrote: post #26

> 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 happened with SVN and also is happening with Git.

Unfortunately you can't argue with those ones since are in lead position and there's no one with technical skills above them in the C-level who can say anything (we don't have a CTO or a CIO, just CFO and CEO who can't even use their own iPad)

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

#107

Post by dtech »

mrisoli wrote: post #92
dasil003 wrote: post #26

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

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

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

#108

Post by hn_throwaway_99 »

ashtonkem wrote: post #91
subroutine wrote: post #52

Earlier quoted context omitted.

In a way though, he's still coding, just at a different level of abstraction. Metaphorically, he used to generate bricks himself, then add them to his castle. Now people bring him bricks and he choses the ones he likes and which to discard. So at the end of the day, perhaps this is still a castle of his design. meh?

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.

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

#109

Post by 0xEFF »

systemvoltage wrote: post #103
mrisoli wrote: post #92

Earlier quoted context omitted.

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…

Yep, no one ever reads them and the cost to benefit ratio is extremely low. Writing good comments is far more important. Don't explain what the code does - that's what the code is for, explain the why and the background information in the code. Additional, explain what the code does at the function level or at the module level - at a much higher abstraction level basically than the line of the code. No one ever looks…

I look at commit messages quite often working on a 10+ year old code base.

Bisect leads to the commit, the commit message explains why the change was made. I take the explanation from 10+ years ago and determine if the reason still applies today.

Or, I bisect and there's a low quality commit from 10 years ago from a person long since departed that simply says "fixup" and I'm dead in the water.

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

#110

Post by tmh88j »

nemetroid wrote: post #101
tmh88j wrote: post #71

Earlier quoted context omitted.

>Too many people think that commit message is to explain HOW you did something. >WHY you did it this way is the most important part. What was done is better suited for the commit message than how and why it was done, in my opinion. The latter two are better explained by comments in the code. I agree that why something was done is important for future reference, but when I'm tracking down code changes I'm looking for…

Requirements change over time, and so do the "why"s. So unless the code base is your primary documentation for requirements, "why" comments in the code can be dangerous: while outdated "what" comments can be determined as such by reading the code, there is no way (from the code itself) to determine whether a "why" comment is still accurate. A "why" comment in a commit message, on the other hand, only tells you what t…

>So unless the code base is your primary documentation for requirements, "why" comments in the code can be dangerous

No, but you seem to be implying that commit messages serve that purpose. If your code changes why wouldn't you add new comments and remove outdated/misleading comments?

>A "why" comment in a commit message, on the other hand, only tells you what the "why" was at that time, something that cannot become outdated.

What is version control for if not to retain state of the code as it was being written? Any popular IDE has simple interfaces to compare commits and see what was changed.

Post reply on HN