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?

Forcing every team in the company to use the same project management framework because consultants who never created great software claimed it's a panacea. Interesting decision.

How long does it take to fix a Linux kernel bug? Anywhere from a day to 20 years to never. It's either done as soon as possible, or it's done when it's done and that works for the best software projects.

Estimating is not hard, it's snake oil. That's how you end up paying $100M for burndown charts and a government website that doesn't work.

Technical knowledge should be a necessary but not sufficient condition to become an engineering manager. A layman can't take a two day course with no exam and become a managing partner at a law firm. Why is that sufficient to become a micromanager in an enterprise software project?

That's yearly planning. If estimation means giving your best effort to complete a project over the next year then that's not a problem. When you start micromanaging on a biweekly basis with daily status updates then it becomes a real problem.

How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.

Planning too often is also a problem. You should not do it more often than every three to six months.

There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.

Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.

The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.

People know when they are reciting something they have memorized. Do language models not remember having memorized what they're writing?

They didn't improve on human truck drivers yet.

The claim that large language models would replace software engineers this year is aging very badly.

Have "AGI" outperform truck drivers first. They said autonomous trucks would replace all truck drivers by 2018.

Who claimed management consultants are not stochastic parrots?

The software engineers working on the best projects don't follow "scrum" frameworks. Where are the story velocity ticket points in Linux kernel development?