Please next time link to the source and not to another discussion forum:
Linus Torvalds: 'I Do No Coding Any More'
121–130 of 246 posts
Re: Linus Torvalds: 'I Do No Coding Any More'
#122Earlier 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?
"Junior" is about experience, not age. You can be a junior developer at age 30, or a sage by that same age.
Re: Linus Torvalds: 'I Do No Coding Any More'
#123Earlier 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 think the issue with comments is that they lose all temporal and situational context. You see a comment next to code, but you have no idea if it's actually still addressing that piece of code. How out of date is that comment? Nobody knows. But if you look at the git history of all the edits specific to a part of code, you'll have a full view of what happened and why and by whom. I think the big issue is that programmers aren't taught to properly leverage git in this holistic way - instead it's just "version control", when it can be such a crucial and informative and helpful part of a process around documentation, writing good code and working in a team.
Re: Linus Torvalds: 'I Do No Coding Any More'
#124Earlier 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.
Yep. I actually think PR squashing should be something you ask of someone else when they don’t take the time to clean up their commit history. If they don’t have the discipline to do it then one big sloppy commit is better than 25... I rarely squash my PRs because I always take the time to provide meaningful context surrounding my work.
Re: Linus Torvalds: 'I Do No Coding Any More'
#125Earlier quoted context omitted.
>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…
> If your code changes why would you leave outdated and misleading comments? The point is that the code might not change. When you wrote it, maybe it was to cover use cases A and B. Sometime later, a new use case ”C” is added to the requirements, and this particular part of the code happens to already support C without making any changes. Now, further down the line, some developer comes along to work on this code. If…
You seem to be confusing end user documentation with code documentation....an actual document that describes how to use the software vs comments in the code that describes how it works
>Sometime later, a new use case ”C” is added to the requirements, and this particular part of the code happens to already support C without making any changes.
Can you give an example of a new use case being introduced without the code changing? Why would this be documented in the code in the first place if nothing has changed?
Re: Linus Torvalds: 'I Do No Coding Any More'
#126Earlier 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?
We really gain skill for this over time.
As I gain experience, I find that I understand in more details existing codebases. This increased my chance of a successful refactoring. Especially when replacing a core abstraction without a full rewrite.
Re: Linus Torvalds: 'I Do No Coding Any More'
#127Earlier quoted context omitted.
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.
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 to inline documentation. The inline documentation is more important when the explanation is relevant to understanding the code which results from the commit, whereas a clear commit message is more important when the information is to illuminate the reasons for (or history surrounding) the change itself.
Re: Linus Torvalds: 'I Do No Coding Any More'
#128Earlier 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.
Yep. I actually think PR squashing should be something you ask of someone else when they don’t take the time to clean up their commit history. If they don’t have the discipline to do it then one big sloppy commit is better than 25... I rarely squash my PRs because I always take the time to provide meaningful context surrounding my work.
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.
Re: Linus Torvalds: 'I Do No Coding Any More'
#129Earlier 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?
Usually senior is 5+ years experience...
At what age did you start working, oh snarky one ?
Re: Linus Torvalds: 'I Do No Coding Any More'
#130Earlier quoted context omitted.
What's wrong with placing that documentation right where it belongs?: In the code.
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.