Hacker News Reader

Comment by PUSH_AX | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

Fine, but none of that is in a normal commit message, lets be real...

Which circles back to why it's important for leadership to tackle this

Yes, but not in the form of commit messages, the parent comment described things better suited to jira tickets, documentation etc.

It feels like we're trying really hard to stretch the utility of commit messages here...

Mainly I was pushing back on: the code is the "truth"

I don't feel that is an accurate statement for any complex system.

I don't like complex systems, and I work hard not to create them.

Sure but code can't capture everything. Maybe with enough comments I guess, but not code alone. For example, code won't tell you that this feature was timeboxed hence this edgecase was not supported

And a commit message would convey that?

It could, or maybe the ticket does.

Having dumb or nonexistent commitment messages has 0% chance of communicating anything. If someone has at least made an effort, a future someone will be able to identify some of the following:

1. What project in general the change was associated with (it may not be obvious from the files changed in this single commit) which can indeed tell you how well it was spec’d- maybe you’ll even find the technical plan.

2. Possibly a hint of how the author intended it to work, or a clue about their misunderstanding. For example, the commit may have changed a function to accept a null argument to “solve” some other problem, but now you know that null passing through here is harmful, well thanks to the commit info, you know that you have to account for the problem that dev was “solving” if you don’t allow the null here. Without that you’d just revert the change and cause the other bug to regress.

You'll at least need the discipline to include the ticket ID in the message. Links to documentation are ok, but they will likely rot and even if they don't the content may change such that it no longer accurately reflects the commit changes.

Yes, we are on our third ticketing system on our team with dead refs to old issues. PR without a commit documenting why you need a change does not normally get approved and helps a lot also at present and future review time. Lots of value for new devs to see how thinking went and why something exist and not something else etc.

Documenting it also forces people to think why they are adding a change in the first place. Code added without purpose becomes dead weight and tech debt.

So rather than commit messages that stay in the repo you want the information in a place where its lost by the next buck tracker migration?

Look, I'll make this easy to understand. The parent comment that this stems from said:

> It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.

If you're advocating this should all go in commit messages then I don't know what to say that I haven't already, it objectively doesn't belong there. The end.

I think we’re advocating for is that it contains a sufficient amount of context. Ideally it’s like “XYZ-123: Enable multi-foo support for Bar”

Links to ticket IDs are good, and good leaders don’t let old ticket links break on bugtracker migration.

A sentence or so to let future devs know what this change meant to do or at least what initiative it was intended to support, is also good. If future devs (even future YOU) don’t know what you were trying to do, they might revert a change which, without context, looks like a mistake.

Doing both ticket link + text is ideal because someone might screw up the ticket system, and a sentence on its own can be ambiguous.

Doing neither, on purpose, is just willful stupidity. Don’t even bother with Git if you want your commits, the ones that end up in “dev” I mean, to all just say “wip,” “asdf,” and “hope it works now.”

And what of the original author is not there anymore?

The world will not end. I’ll get there.

The code is the present truth, the commit messages can inform you about how it got turned into this truth. Interestingly, I recently wrote a short article about this: https://agateau.com/2026/on-commit-messages/

Your argument on conventional commits is something I've come to agree with. There are even tools that can generate release notes from conventional commits, and they are premised on the same mistake.

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

You're thinking like someone with a mature understanding of version control. Plenty of developers seem set on going their whole careers using git like beginners.

That sounds clever until you remember tools exist to solve actual problems.

Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?

Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4]

If enough of the following apply strongly enough to your project:

* Very small codebase

* A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review

* Not doing anything technically challenging

* You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature

then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane.

I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6]

> Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop

I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. We'd expect the same from a competent carpenter or cook.

[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=log

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[2] https://git.ffmpeg.org/gitweb/ffmpeg.git/log

[3] https://github.com/openjdk/jdk/commits/master/src/hotspot

[4] https://github.com/openssl/openssl/commits/master/

[5] https://spinroot.com/gerard/pdf/P10.pdf The Power of Ten - Rules for Developing Safety Critical Code

[6] https://tigerstyle.dev/

> I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work.

This is classic dogmatics over pragmatics.

The carpenter understands how to use every tool, they are just pragmatic about its use.

Again, in my experience, that isn't it. It's like NASA's rules. People who write garbage commit messages and have a chaotic and unconsidered version control workflow, generally lack the skill to do otherwise. As they lack version control skills, they haven't had the opportunity to internalise the benefits. Those with the skill to make disciplined use of version control tend to do so on every project, as the effort required is modest and is repaid even on minor projects.

We're talking about low-hanging fruit here. It's not like adopting the MISRA C programming style, which really does severely restrict the programmer.

Becoming a pragmatic engineer takes time, you’ll get there one day. Best of luck.

Sloppy use of version control doesn't make you more effective. It just doesn't work that way.

Torvalds himself writes up proper commit messages even for his toy projects. [0][1] I really doubt it takes him much time or effort. You really think he's not pragmatic?

[0] https://github.com/torvalds/GuitarPedal/commits/main/?after=...

[1] https://github.com/torvalds/test-tlb/commits/master/

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.

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).

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

Reply on news.ycombinator.com