6 ms·

This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leader

This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.

PUSH_AX 6mo ago
I think it's a stretch to measure leadership quality on something so minor, a lot of teams find them pretty useless no matter how good they are.
- freedomben 6mo ago
  It's a stretch to lay at the CTOs feet, but not the team lead or even Head/VP of Engineering IMHO. It's also easy to "enforce" if you're already doing peer review (which you definitely should be, even if not required for compliance).
- two_tasty 6mo ago
  I partially disagree. Technical leadership at the micro/mid level should be able to set and enforce standards like "you must have semi-meaningful or meaningful commit messages." If and only if they set those standards, and the team does not follow them, then we can say that either the leadership is lacking, or there is a structural barrier/disincentive to following the rules. Within that framework, I do think using process-smells like this is valid for judging technical leadership. To the point of other commenters however, I wouldn't lay something this micro at the foot of the CTO in all but the smallest of organizations.
- munksbeer 6mo ago
  I don't agree. These things actually matter. A developer who isn't told otherwise is just going to do whatever they feel like, so if there is nothing or no-one enforcing the standards, then the failure isn't on the individual developer, it is on the team lead. Someone needs to be setting the standards. In the company I work for, there is a team that has isolated itself to some extent from other teams and works at a furious pace to keep their particular section of the business happy. We're lucky enough that they spun up their own repo to do their work on, so they don't actually impact other teams, but if the quality of the commit messages is anything to go by, I am 100% certain they're going to end up in a huge mess, if they aren't already. The team lead encourages this, and certainly doesn't care about commit messages etc. Developers who care about other developers tend to write better quality code, because they care what other developers think of them. If you care about other developers, you will most likely write decent quality commit messages too. I have seen over many years the types of developers who only care about moving their own code into production as fast as possible and getting to the next thing. There is a very high correlation with a mess at the end, which they inevitably won't have to tidy up because they'll be doing the next thing. These types of developers hate owning stuff in production, so they don't do it, so they don't actually care how maintainable their "clever" code is. I am very certain that a number of people reading this will be those types of developers.
  - alt_422568 6mo ago
    This sounds a lot like the tactical tornado archetype. From A Philosophy of Software Design by John Ousterhout: > Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.
- xp84 6mo ago
  Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear. As a manager, one of the first things I do is make sure that the PR titles (the PR text becomes the commit messages in squash-merging workflows) at minimum begin with a ticket number. Then we can later read both the intention and the commentary on it.
  - PUSH_AX 6mo ago
    > Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? Personally no, the code is the "truth". If I need more I'm going to open a dialog with the author, not spend time trying to interpret a 7 word commit message, "good" or otherwise.
    - macintux 6mo ago
      The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code. And for old enough code, the author may not be available, or more likely doesn't remember.
      - PUSH_AX 6mo ago
        Fine, but none of that is in a normal commit message, lets be real...
        mgfist 6mo ago
        Which circles back to why it's important for leadership to tackle this
        PUSH_AX 6mo ago
- hulitu 6mo ago
  > a lot of teams find them pretty useless They are useless: Google Messages bothers me to upgrade to a new version. I read the changelog: "Bug fixes and performance improvements". Last time they did it it was full of bugs. Really Google: come back when you actually fixed something.
deleted 6mo ago
[deleted]
ryandrake 6mo ago
Yes, and a culture problem, too. I guess I've been blessed that I've mostly only worked for "grown up" companies, but I've never encountered a workplace where people didn't write useful commit messages. At least one line description of the work done, but often multiple lines of valuable context. Only the junior devs had to be told to do it, but once they got into the habit, everyone understood why we do it and it was no big deal. If I joined a company where people committed their code with "stuff" or "made some changes" or "asdfhlfo;ejfo;ae," that would be a red flag that I might have joined the wrong company, and I'd start to wonder what else the developers here do carelessly.
- lossyalgo 6mo ago
  Good commit messages would be nice but honestly I would be over the moon if our pull requests would be approved within a week without having to ping one or more people.
  - rcfox 6mo ago
    Maybe you need to make shorter PRs?
    - lossyalgo 6mo ago
      haha as if. I mostly do bugfixes, small features, and otherwise most of my PRs are just unit text fixes so that our CI jobs run again (because my colleagues don't seem to care about breaking tests, so I get to fix everyone's tests, so that QA doesn't go postal). To put it into numbers: my PRs are usually less than 5 files changed, and very little changes in those files.
      - 946789987649 6mo ago
        Why can code even go in with breaking tests? They shouldn't even have the power to do that.
        6mo ago
berkes 6mo ago
I once tutored an intern. Who thought he was The Best Programmer On Earth (didn't we all at that age?). He refused to use revision control, it slowed him down. So we told him to commit at least once every day, with a relevant commit message, or else fail his internship. He worked 21 more days. There were 21 commits: "17:00, time to go home".
- vntok 6mo ago
  This reads like the intern was left to his own devices and his output not checked at all for three weeks straight. Actual tutoring would have surfaced the issue after 1 or 2 days tops.
  - berkes 6mo ago
    Oh, but I had a daily sit down and addressed this and other issues several times. The problem was, as I mentioned, "he though he was the best developer ever". stubborn as hell. And pushed back against anything he wasn't used to, anything that wasn't his usual "ssh or ftp into prod and change stuff until it works" because he thought this was the only method that worked. This was my first encounter with a self-proclaimed "10x" developer before that term existed. Someone who - as seen by far off management - seemingly have a high output, but in reality just create a trail of tech-debt and work for the rest of the team.
    - mixmastamyk 6mo ago
      Dismissed.
drums8787 6mo ago
I particularly love when the “CTO” is also the main offender.
- jillesvangurp 6mo ago
  I am a CTO and I actually have very little patience for people that obsess over minor formatting issues (use a linter if you care), commit messages, and other fringe issues. If that's the biggest issue you have in a team, amazing. You are doing great. But you probably have bigger issues. The focus of the CTO is on the big picture stuff. Like staying on top of technical debt and correcting people when they keep on adding more of it. And making sure people learn from their mistakes, focus on the important things first, etc. The thing with commit messages is that they are mostly never going to get a lot of scrutiny. But there are exceptions to this; especially if there are audits involved or external contributors. And of course when making a pull request to an OSS project, it is good form to make a bit of an effort. It depends on the context. I tend to focus more on diffs and pull requests. Not on the cryptic one liners that may or may not describe some of the changes. The right unit of change is a pull request, not individual commits. And all this of course was when I was still able to keep on top of the massive volume of change. With AI that's simply no longer the case and the volume of change is only going to increase over time. Human reviews are now the main bottleneck to getting code merged. AIs probably should be doing a lot of the reviewing, gatekeeping testing, vetting, etc. Especially when AIs also produce most of the change. It's likely a lot of things will slip through unless you get your house in order on guard rails and process that your AI agents need to follow. As a CTO, guarding quality without becoming a human bottleneck is now the main challenge and removing bottlenecks responsibly is part of the job. BTW. making AI tools write good commit messages is actually be a bit expensive. Many AI tools default to just summarizing the first message of a chat session under the assumption that just one thing changed over the course of a session. Making the AI look at the actual diff is of course possible and not that hard (just ask). And it definitely yields better descriptions when you do that. But it also takes more time and the token cost goes up as well. I'm not sure that's actually worth the expense in tokens. I tend to not bother with this. But again; depends on the context.
  - sunnyps 6mo ago
hbn 6mo ago
One of the best developers I work with commits everything with the message "changes" (This is not an endorsement to do that, he's a good developer in spite of his shitty commit messages)
- mewpmewp2 6mo ago
  Obviously a very unpopular opinion, but I guess for my own sake it's hard to write commit messages, because for me it's that I have never really even found use of other people commit messages, and I rarely even attempt to. Ultimately code is code and I don't care about how it got to how it is. I got same issue with documentation and comments or really anything that isn't building stuff. I don't like writing it, don't like reading it either... ADHD? So, before AI came and saved me from writing commit messages I had alias that ran the whole git add . && git commit -m ... && git push with a fixed commit message. But of course we had squashing so PR title was the one to eventually go there, so maybe that part is fine. But all my side projects had just that.
  - titanomachy 6mo ago
    As long as there’s some record, whether it’s PR or commit. At Google and Meta there’s no distinction, each commit is a PR (approximately) and has a description and discussion linked to it. I’ve found this really valuable for understanding a piece of code, maybe it’s just five lines but of there’s 200 words of discussion giving you more context on why it is that way.
  - wsve 6mo ago
    Yeah I also don't really write commit messages. If your pull request becomes associated with that commit, and the history gets squashed, then that one commit becomes a link to the pull request where all the necessary info is. I just write "commit" for all my messages.
    - skydhash 6mo ago
      On my local copy of the repo, commits are notes to myself. I don't use the `--message` switch. I let git bring up my $EDITOR where I type what I did since the last commit. This helps when I'm writing the PR description and when I'm rebasing the branch on top of the main trunk. And then some time, I need to do a bit of git-fu and split the changes into different PRs. Hard to do this with generic messages. But I use magit and I can commit specific lines and hunks as easily as files. That helps with managing changes to meaningfully group them.
ygouzerh 6mo ago
It can be even enforced using hooks/pipelines that will check that the message follow Conventional Commits as well
- account42 6mo ago
  > Conventional Commits I though we were talking about good commit messages.

This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.

PUSH_AX 6mo ago

I think it's a stretch to measure leadership quality on something so minor, a lot of teams find them pretty useless no matter how good they are.

freedomben 6mo ago
It's a stretch to lay at the CTOs feet, but not the team lead or even Head/VP of Engineering IMHO. It's also easy to "enforce" if you're already doing peer review (which you definitely should be, even if not required for compliance).
two_tasty 6mo ago
I partially disagree. Technical leadership at the micro/mid level should be able to set and enforce standards like "you must have semi-meaningful or meaningful commit messages." If and only if they set those standards, and the team does not follow them, then we can say that either the leadership is lacking, or there is a structural barrier/disincentive to following the rules. Within that framework, I do think using process-smells like this is valid for judging technical leadership. To the point of other commenters however, I wouldn't lay something this micro at the foot of the CTO in all but the smallest of organizations.
munksbeer 6mo ago
I don't agree. These things actually matter. A developer who isn't told otherwise is just going to do whatever they feel like, so if there is nothing or no-one enforcing the standards, then the failure isn't on the individual developer, it is on the team lead. Someone needs to be setting the standards. In the company I work for, there is a team that has isolated itself to some extent from other teams and works at a furious pace to keep their particular section of the business happy. We're lucky enough that they spun up their own repo to do their work on, so they don't actually impact other teams, but if the quality of the commit messages is anything to go by, I am 100% certain they're going to end up in a huge mess, if they aren't already. The team lead encourages this, and certainly doesn't care about commit messages etc. Developers who care about other developers tend to write better quality code, because they care what other developers think of them. If you care about other developers, you will most likely write decent quality commit messages too. I have seen over many years the types of developers who only care about moving their own code into production as fast as possible and getting to the next thing. There is a very high correlation with a mess at the end, which they inevitably won't have to tidy up because they'll be doing the next thing. These types of developers hate owning stuff in production, so they don't do it, so they don't actually care how maintainable their "clever" code is. I am very certain that a number of people reading this will be those types of developers.
- alt_422568 6mo ago
  This sounds a lot like the tactical tornado archetype. From A Philosophy of Software Design by John Ousterhout: > Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.
xp84 6mo ago
Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear. As a manager, one of the first things I do is make sure that the PR titles (the PR text becomes the commit messages in squash-merging workflows) at minimum begin with a ticket number. Then we can later read both the intention and the commentary on it.
- PUSH_AX 6mo ago
  > Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? Personally no, the code is the "truth". If I need more I'm going to open a dialog with the author, not spend time trying to interpret a 7 word commit message, "good" or otherwise.
  - macintux 6mo ago
    The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code. And for old enough code, the author may not be available, or more likely doesn't remember.
    - PUSH_AX 6mo ago
      Fine, but none of that is in a normal commit message, lets be real...
      - mgfist 6mo ago
        Which circles back to why it's important for leadership to tackle this
        PUSH_AX 6mo ago
hulitu 6mo ago
> a lot of teams find them pretty useless They are useless: Google Messages bothers me to upgrade to a new version. I read the changelog: "Bug fixes and performance improvements". Last time they did it it was full of bugs. Really Google: come back when you actually fixed something.

deleted 6mo ago

[deleted]

ryandrake 6mo ago

Yes, and a culture problem, too. I guess I've been blessed that I've mostly only worked for "grown up" companies, but I've never encountered a workplace where people didn't write useful commit messages. At least one line description of the work done, but often multiple lines of valuable context. Only the junior devs had to be told to do it, but once they got into the habit, everyone understood why we do it and it was no big deal. If I joined a company where people committed their code with "stuff" or "made some changes" or "asdfhlfo;ejfo;ae," that would be a red flag that I might have joined the wrong company, and I'd start to wonder what else the developers here do carelessly.

lossyalgo 6mo ago
Good commit messages would be nice but honestly I would be over the moon if our pull requests would be approved within a week without having to ping one or more people.
- rcfox 6mo ago
  Maybe you need to make shorter PRs?
  - lossyalgo 6mo ago
    haha as if. I mostly do bugfixes, small features, and otherwise most of my PRs are just unit text fixes so that our CI jobs run again (because my colleagues don't seem to care about breaking tests, so I get to fix everyone's tests, so that QA doesn't go postal). To put it into numbers: my PRs are usually less than 5 files changed, and very little changes in those files.
    - 946789987649 6mo ago
      Why can code even go in with breaking tests? They shouldn't even have the power to do that.
      - 6mo ago

berkes 6mo ago

I once tutored an intern. Who thought he was The Best Programmer On Earth (didn't we all at that age?). He refused to use revision control, it slowed him down. So we told him to commit at least once every day, with a relevant commit message, or else fail his internship. He worked 21 more days. There were 21 commits: "17:00, time to go home".

vntok 6mo ago
This reads like the intern was left to his own devices and his output not checked at all for three weeks straight. Actual tutoring would have surfaced the issue after 1 or 2 days tops.
- berkes 6mo ago
  Oh, but I had a daily sit down and addressed this and other issues several times. The problem was, as I mentioned, "he though he was the best developer ever". stubborn as hell. And pushed back against anything he wasn't used to, anything that wasn't his usual "ssh or ftp into prod and change stuff until it works" because he thought this was the only method that worked. This was my first encounter with a self-proclaimed "10x" developer before that term existed. Someone who - as seen by far off management - seemingly have a high output, but in reality just create a trail of tech-debt and work for the rest of the team.
  - mixmastamyk 6mo ago
    Dismissed.

drums8787 6mo ago

I particularly love when the “CTO” is also the main offender.

jillesvangurp 6mo ago
I am a CTO and I actually have very little patience for people that obsess over minor formatting issues (use a linter if you care), commit messages, and other fringe issues. If that's the biggest issue you have in a team, amazing. You are doing great. But you probably have bigger issues. The focus of the CTO is on the big picture stuff. Like staying on top of technical debt and correcting people when they keep on adding more of it. And making sure people learn from their mistakes, focus on the important things first, etc. The thing with commit messages is that they are mostly never going to get a lot of scrutiny. But there are exceptions to this; especially if there are audits involved or external contributors. And of course when making a pull request to an OSS project, it is good form to make a bit of an effort. It depends on the context. I tend to focus more on diffs and pull requests. Not on the cryptic one liners that may or may not describe some of the changes. The right unit of change is a pull request, not individual commits. And all this of course was when I was still able to keep on top of the massive volume of change. With AI that's simply no longer the case and the volume of change is only going to increase over time. Human reviews are now the main bottleneck to getting code merged. AIs probably should be doing a lot of the reviewing, gatekeeping testing, vetting, etc. Especially when AIs also produce most of the change. It's likely a lot of things will slip through unless you get your house in order on guard rails and process that your AI agents need to follow. As a CTO, guarding quality without becoming a human bottleneck is now the main challenge and removing bottlenecks responsibly is part of the job. BTW. making AI tools write good commit messages is actually be a bit expensive. Many AI tools default to just summarizing the first message of a chat session under the assumption that just one thing changed over the course of a session. Making the AI look at the actual diff is of course possible and not that hard (just ask). And it definitely yields better descriptions when you do that. But it also takes more time and the token cost goes up as well. I'm not sure that's actually worth the expense in tokens. I tend to not bother with this. But again; depends on the context.
- sunnyps 6mo ago

hbn 6mo ago

One of the best developers I work with commits everything with the message "changes" (This is not an endorsement to do that, he's a good developer in spite of his shitty commit messages)

mewpmewp2 6mo ago
Obviously a very unpopular opinion, but I guess for my own sake it's hard to write commit messages, because for me it's that I have never really even found use of other people commit messages, and I rarely even attempt to. Ultimately code is code and I don't care about how it got to how it is. I got same issue with documentation and comments or really anything that isn't building stuff. I don't like writing it, don't like reading it either... ADHD? So, before AI came and saved me from writing commit messages I had alias that ran the whole git add . && git commit -m ... && git push with a fixed commit message. But of course we had squashing so PR title was the one to eventually go there, so maybe that part is fine. But all my side projects had just that.
- titanomachy 6mo ago
  As long as there’s some record, whether it’s PR or commit. At Google and Meta there’s no distinction, each commit is a PR (approximately) and has a description and discussion linked to it. I’ve found this really valuable for understanding a piece of code, maybe it’s just five lines but of there’s 200 words of discussion giving you more context on why it is that way.
- wsve 6mo ago
  Yeah I also don't really write commit messages. If your pull request becomes associated with that commit, and the history gets squashed, then that one commit becomes a link to the pull request where all the necessary info is. I just write "commit" for all my messages.
  - skydhash 6mo ago
    On my local copy of the repo, commits are notes to myself. I don't use the `--message` switch. I let git bring up my $EDITOR where I type what I did since the last commit. This helps when I'm writing the PR description and when I'm rebasing the branch on top of the main trunk. And then some time, I need to do a bit of git-fu and split the changes into different PRs. Hard to do this with generic messages. But I use magit and I can commit specific lines and hunks as easily as files. That helps with managing changes to meaningfully group them.

ygouzerh 6mo ago

It can be even enforced using hooks/pipelines that will check that the message follow Conventional Commits as well

account42 6mo ago
> Conventional Commits I though we were talking about good commit messages.