Why do PMs always think that comments/commit messages > the actual code?

If I need to know why it's coded that way, I need to check the code.

I get you want to know what's going on, but seriously, don't make me rewrite the code in English. You already know the ticket it's for and have the summary as the PR message (especially for code that the character changes can be counted on 1 hand)

I never had a PM who reads commit messages.
Some of those probably wouldn’t even know what a commit message is.

This one has complained at a retro about "useless" commit messages because a colleague accidentally re-used the same commit message from a different branch when fixing a typo (intelij defaults to keeping the last message in the commit box)

Oh and squash and merge is enforced, so that commit message is "lost" anyway

I also never had a PM who tries to have any detailed opinion about the code.

"squash and merge is enforced"

Wow. Then it's silly to bring that it up in a retro.

"intelij defaults to keeping the last message in the commit box"

Whoa, that sounds like a nightmare. Every time you make a commit in a scenario where you made a previous commit you'll have to clear the text box?

If so - I would make someone in the team spend 10 minutes looking for a setting that could change that. Unless you like it for some reason. Sounds like a potential source for future mistakes.

@jiraTicket It's quite easy to disable (intelij's settings are fully searchable) but I imagine they have it as the default because most people don't care too much about the message. You can even get their AI package to write the commit message for you, and if I had to deal with him too often, I'd be tempted. Luckily, he doesn't/stopped touching the (normal) codebase I work on

@BordedDev "they have it as the default because most people don't care too much about the message"

What 😱 this sounds awful to me.

I don't care about commit messages being perfectly worded (I love squash-and-merge as the github setting) but I care about them not being entirely incorrect. I'm fine with poor commit messages like "h1" or "fix image" but I would be worried if there's a risk the message is "fix image" when they're working on a h1.

I'm kinda starting to think the PM was right to bring this up as an issue in the retro...

If this was my team I'd advocate for enforcing a setting where the commit message box was blank by default.

If I have to take more time filling out shitty bureaucratic processes (call it git policies, tickets, or whatever) than fixing code, the Project *manager* is not doing his job, because he ain't managing shit.

The good managers I had just needed a quick dm/email.

"Is x done? If not, anything blocking you?"

And an equally succinct answer if any extra info needed to be added to the ticket or whatever.

@jiraTicket I agree with the sentiment, but it has only happened once in the ~5 years I have worked with him (the colleague who made the error).

Also the commit message not the PR message

Since you need to select the files to commit manually (mouse) first (or if you right-click on a file and choose to commit, it will focus and highlight the full input field). AFAIK you can't hit commit without manual mouse input (or tab over when you have the input in focus). It would be nice if it showed a warning though if it detected no input

@jestdotty I love having conversations about code/tools/methodologies/I think this would be cool, and have had them. The problem comes in when they choose to disagree with a sentence you said in the beginning, even though you address that direct concern in the next sentences.

e.g. This fixes problem X. It does it by doing Y. Considered doing it using A, B and C but problems QWE meant Y was the only feasible solution

"Why didn't you do B"

I do appreciate the conversation, what I don't appreciate when it holds up a PR for 3 days (human testing only happens post-merge 🥲) that sales is champing at the bit to get to customers/demo to CEO

var the_variable_for_the_data = function_call_to_get_the_data(some_other_autistic_fuck_named_variable)

@BordedDev "only happened once in the ~5 years I have worked with him"

Oh! Then I'd say it's a non-issue 😊

(But this is a good example of the type of thing you might have to mention to people complaining about it. If I had recently joined your team as a dev and saw that everyone's editor were configured like this I would imagine this would be a huge potential risk. Before I was told people have used this for 5 years without issues)

@jestdotty The problem is not the detail as far as I can tell, if I don't mention that I didn't do B, then the question comes of “why didn't you do it like this <B>”

@Demolishun that can still get you the "why didn't you add a comment?!??"