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.

I love rewriting the code in English

watch them fall asleep, eyes glaze over, and never ask again

I can talk for like hours over a fucking assign statement, tehe

better than their meetings complaining about nothing or repeating themselves for no reason

plus I think in some ways it confers respect because they wouldn't want to be doing my job and I like all this boring calculations stuff. you deal with the people and give me succinct notes, I'll deal with the technology and give succinct notes. beautiful mutualism!

@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

@BordedDev if they're asking "why didnt you do B" you haven't sufficiently went low level enough for their brain to turn off yet

I mean I assume their question is actually annoying. if someone asks why I didn't do X I'm fine with answering why not -- so they have some ability to think through code? that would be respectable and I'd end up teaching them architecture decision making and stuff. but if the answer to their question is that "well it's in the spec" then I would be annoyed. their job is to know the spec better than I do and I don't appreciate having to lift their weight for them

(also technically I'd just say it solves it by Y and wouldn't mention my other tries -- maybe that would minimize the annoying behavior?)

---

if it's holding up PRs I would reduce the amount of communication to only the happy paths. perhaps you're being too detailed and it's making them confused 😝
programmers have to care about edge cases but it's human nature to only do happy paths

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)