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.

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

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

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?

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.

It sounds like you could just read their code and the meeting was unnecessary. Linux kernel developers are distributed but don't do daily status update meetings.

Daily status updates are not useful. Linux kernel developers don't do them. I trust that nothing is stopping your engineers from having a chat and that their manager doesn't need to schedule their chats for them.

If six months of daily meetings did not lead anywhere then cancel those meetings.

> Why have they reported at every standup the last six months

Every what?

Does French law mandate trial periods or 3 month notice periods? You can usually negotiate those away. Reference checks or trial period but you should really not require both, that's an employer problem.

Europe pays lower than the US but pays better than other regions. There are many countries with low pay and poor labor rights. We should try to have high pay and better labor rights.

There is no proof that cargo cult agile improves efficiency or reduces costs but many companies do it regardless.

Your managers should be former or current software engineers who can evaluate the technical merits of a rewrite.

Kanban is just a todo list in English and all sorts of professionals use todo lists.

You write the check once a year and plan projects no shorter than three months.

Software engineers are not assembly line laborers developing x cogs per hour either. There is no evidence that micromanaging software projects works.

Tenured mathematicians are immune to deadlines, and non-tenured ones don't "story point" conjectures. Your PI does not usually make you submit daily status reports. Targeting a submission date three to six months ahead and trying again if it doesn't work out is a framework that would work in software engineering too.

That attitude works well in other professions. If you want to become a managing partner at a law form you are expected to have chops. Why should software engineers accept micromanagement by laymen?