[samatman]

Cargo-culting someone else's process is a bad way to develop good process for your specific team and its needs.

You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all.

[ResearchCode]

What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.

[khazhoux]

> What specific needs are met by daily status updates?

You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager.

In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity of spoken conversation instead of Slack, and also there’s a non-zero amount of friendly casual conversation.

Don’t force teams to have standups, but also don’t assume a team won’t like it.

[ResearchCode]

They just recommended cross-checking status updates in "stand up" meetings with commit history to catch engineers underperforming. That is (1) (2) and (3).

[khazhoux]

A manager has a duty to "catch" (as you put it) underperformers, to help them improve.

If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming about it. They'll represent their work as very challenging (which it is, to them), meanwhile others on the team are objectively better and faster at figuring out solutions and not getting stuck, and they understand the codebase better, and the architecture, and so on. The manager has a duty to spot when this is happening, and engage with the engineer immediately to figure out what's going on and try to help them.

Engineer managers should themselves be strong engineers (and in every company I've worked at, this has been the case up the senior leadership chain), so that they can form a realistic, fair, and reasonable assessment of whether there's a discrepancy between how an engineer represents their work, versus what is shown in the actual commit history.

[ResearchCode]

The engineer did not choose to represent themselves in weird daily show-and-tell meetings. The commit history is there regardless. You could just look at that.

[samatman]

> Professionals outside of software don't do that.

How do you know this? Have you done an exhaustive search?

For one example, are you quite certain that no part of any military ever does this?

What about every factory?

[ResearchCode]

You are not answering my question. No, you ask your acquaintances who work in law, finance or medicine. Neither does academia have any "stand up". What specific needs do CRUD software projects have that are met by infantilizing daily status reports? What needs for daily status reports do these projects have that the Linux kernel doesn't?

[jen20]

> Professionals outside of software don't do that.

What, and I mean this in the nicest way possible, the everliving fuck are you talking about?

Professionals do this constantly. Go sit in an ER and watch the hand off between shifts. Go see any serious manufacturing facility and see them review daily everything that happened the previous day. Go see an effective sales org in action.

The scrumbags may have ruined software, but that certainly isn’t the world.

You make your not entirely unreasonable points sound like the output of a zealot.

[ResearchCode]

"Stand up" meetings are not hand offs in the ER. Continuous integration with automated testing is.

Why are there no laymen agile coaches at law firms, and no "today I did this, today I did that" breakfast meetings in finance, or in CS academia? Other professionals don't accept this kind of infantilization.