Linus Torvalds: 'I Do No Coding Any More'

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 complained about code quality of my work, I was dumbfounded, I have no problem with being criticised, but I at least wanted to be able to learn from it and adapt. I went back through every single PR I did at the company and found little to no comments and it made me feel personally attacked with very little evidence. I then went on my peers PRs and see what I could learn from them, most PRs included highly non-descriptive commit messages and descriptions often only included a link to a JIRA ticket which most of the time was only visible to their direct team members and not me. From that I took the position of being more demanding on not just code quality during reviews but also descriptions, I didn't manage to influence a single developer to improve documenting efforts. That was a major reason why I eventually left the company.

I continue to be a believer in taking your time to write good commit messages, I have yet to collect dividends from it however.

This is not good. It's key to keep your hands practicing. A person needs feedback from objective reality and not subjective reality (people).

This will hurt the platform short term and long term.

I wonder why he's not coding? Maybe his ego is too big and hence sensitive?

A commit message will always be associated with a line of code until that line changes. A code comment may or may not be updated when the code changes.

>> about how a code base "is crap" > Translation: "Not written in the particular arbitrary style that I'm used to" > I've found this to be almost universally true especially when the claim is given forcefully but not immediately backed up with a litany of actual user-impacting serious problems.

There's certain code smells that most experienced developers are going to identify that would be almost universally considered bad. Things like poor variable/method/class names, use of magic values, duplicated logic, high coupling, and lack of unit tests.

None of these have immediate user-impacting problems, and arguing that's the only thing that matters is very short-sighted.

All of these issues will slowly degrade a codebase over the long term -- as the requirements change, new developers start working on the code, and bugs compound other bugs -- and the user impact will be slower delivery and lower quality. Eventually the code will get to a point where the only save is a major rewrite which causes even slower delivery and higher risk of regression in both features and bugs.

Writing good variable names at the time the code is created is significantly easier than fixing it months later. Writing the code in a way that can be unit tested is easier up front (and sometimes impossible later, without a rewrite and all the dangers that go with that).

There's also a big difference between a code base that's maintained by the same focused person (or small group) for a long time, vs being one of several code bases maintained by a team of people (who may change over time). In the former you can get away with things you can't in the latter case, and moderately or highly successful small projects tend to shift to the latter, and are the ones people will call crap code bases despite their commercial or user-facing success.

If you squash commits in a PR down to a single commit, then doesn't that result in a commit that makes a lot of changes that makes it harder to pinpoint a bug or revert without conficts?

A lot of features take more than a single logical commit to implement, so it makes sense to have multiple logical commits associated with a feature update. Squashing them down to a single commit makes it harder to review in my opinion.