[ryandrake]

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.

[ramijames]

Indeed. If you can't spend two minutes (MAX) writing a sentence or two explaining what the commit is for, then what are we doing as developers? Commits are for future you and your future team. They are a tool. Please, use them.

[lossyalgo]

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.

[zimpenfish]

> if our pull requests would be approved within a week

A week? LUXURY. I'd be happy to get PRs approved without a week of fighting over stupid trivial nonsense[0]

[0] [flashbacks to the "which way of defining Perl constants is faster" week of hell]

[rcfox]

Maybe you need to make shorter PRs?

[lossyalgo]

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]

Why can code even go in with breaking tests? They shouldn't even have the power to do that.

[lossyalgo]

Because each job only runs once in the middle of the night when it detects any changes. Also a lot of our tests are very finicky and need to be restarted multiple times before they run successfully, so a failing test isn't necessarily an indication of bad code. On top of that, a lot of our tests are not actually testing anything useful, they are merely fulfilling the customer requirements from specifications - the only useful test for a lot of these requirements are full system tests, which are not easily automated since there are a lot of complex interconnected systems involved with expensive physical hardware that would not be easy to fake.

[godelski]

The same goes for code comments though people are much more vocal about their disdain. It's ironic given how frequent AI is used to generate docs. But docs are much better written by the person who wrote the code, the person who has all the context.

These things never take much time but people dismiss them because of that. Because each commit and each comment in isolation isn't very valuable but they are very helpful in aggregate. I'm not sure why this bias exists though, since the same is true for lines of code. It's also true about a ton of things. All the little things add up. Just because it's little now doesn't mean it's not important

[scottyah]

Some of my favorite are the perhaps well-meaning but totally misguided log of what files they changed.

[asdfman123]

> I'd start to wonder what else the developers here do carelessly

More likely you'd already know by this point because it would be staring you in the face