<story><title>Linus Torvalds: &apos;I Do No Coding Any More&apos;</title><url>https://linux.slashdot.org/story/20/07/03/2133201/linus-torvalds-i-do-no-coding-any-more</url></story><parent_chain><item><author>dasil003</author><text>&amp;gt; &lt;i&gt;commit messages to me are almost as important as the code change itself&lt;/i&gt;&lt;p&gt;This is high on my list of code craftsmanship points.  It&amp;#x27;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 &amp;quot;is crap&amp;quot;, but more often than not I&amp;#x27;d wager this is just a result of the context at the time not being known or appreciated.  Frankly, all code we write is heavily governed by context we take for granted at the time, but is in precious short supply 1, 5, 10 years later.  If you come back with a different use case later, the original code may very well be unsuited for that purpose.  We can argue all day about good judgement and YAGNI, but at the end of the day no one can see all ends, therefore the best we can do is document clearly why we did what we did.&lt;p&gt;Taking the time to rebase, cleanup, and explain your changes in detail will pay huge dividends for any long-lived project.  I&amp;#x27;ve literally had successors write me a thank you note for a commit message from over a decade ago because I take this so seriously.</text></item></parent_chain><comment><author>mrisoli</author><text>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&amp;#x2F;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.&lt;p&gt;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&amp;#x27;t manage to influence a single developer to improve documenting efforts. That was a major reason why I eventually left the company.&lt;p&gt;I continue to be a believer in taking your time to write good commit messages, I have yet to collect dividends from it however.</text></comment>
<story><title>Linus Torvalds: &apos;I Do No Coding Any More&apos;</title><url>https://linux.slashdot.org/story/20/07/03/2133201/linus-torvalds-i-do-no-coding-any-more</url></story><parent_chain><item><author>dasil003</author><text>&amp;gt; &lt;i&gt;commit messages to me are almost as important as the code change itself&lt;/i&gt;&lt;p&gt;This is high on my list of code craftsmanship points.  It&amp;#x27;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 &amp;quot;is crap&amp;quot;, but more often than not I&amp;#x27;d wager this is just a result of the context at the time not being known or appreciated.  Frankly, all code we write is heavily governed by context we take for granted at the time, but is in precious short supply 1, 5, 10 years later.  If you come back with a different use case later, the original code may very well be unsuited for that purpose.  We can argue all day about good judgement and YAGNI, but at the end of the day no one can see all ends, therefore the best we can do is document clearly why we did what we did.&lt;p&gt;Taking the time to rebase, cleanup, and explain your changes in detail will pay huge dividends for any long-lived project.  I&amp;#x27;ve literally had successors write me a thank you note for a commit message from over a decade ago because I take this so seriously.</text></item></parent_chain><comment><author>justapassenger</author><text>This so, so much.&lt;p&gt;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.&lt;p&gt;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 at least understand it. And you can’t work effectively on something you don’t understand.&lt;p&gt;Not having this context is reason for so many rewrites. Developer thinks a solution is supper crappy, goes to rewrite it, with grand vision. Only to learn along the way about all the edge cases and reasons for hacks.</text></comment>