Your source code is worthless

Let’s face it, we were still a fast-moving startup, even if the above anecdote might give you the opposite picture. Our code was still changing drastically every couple weeks. Changes of the entire architecture or complete re-writes of components were not uncommon, as is usual for some early stage startups. And as you might expect in such a situation, the code wasn’t of the highest quality either: Half the time, the build would be broken. Testing and documentation were basically non-existent. It was unlikely that anyone from outside the team would even have gotten the thing up and running. Even if they did, it would be outdated a moment later.

L'impact désastreux de la soi-disant rationalisation de la gestion : le management se concentre sur quelques chiffres qui deviennent donc les objectifs de fait, au détriment des vrais objectifs de la recherche.

When a measure becomes a target, it ceases to be a good measure.

C'est la Loi de Goodhart

+1

Il y a un espèce de mythe autour du «daily stand-up», et dans de nombreuses boites il se retrouve utilisé à toutes les sauces de manière totalement inutile.

Les situations où un «daily stand-up» est inutile voire nuisible sont bien résumées dans l'article :

• Everyone is working on their own tasks / user stories, with very little need for coordination outside of the regular sprint meetings. This can cause a host of other problems, but you probably do not need a daily standup meeting.
• People are not even working on the same project. Everyone on the "team" is on a different project, e.g. people in an agency working for different customers. So your team is not even a team!
• Your team is working closely together all the time. They are co-located, and they always work together on a single user story. Everyone already knows what everybody else is doing, so you do not need a daily meeting where everyone is stating the obvious.

Je soupçonne que la raison principale pour laquelle la majorité des boites qui font des «stand-up» en font, c'est parce que ça donne une impression de contrôle au management.

It is mainly used for reporting the progress to a manager

C'est pas bête comme remarque, c'est effectivement assez dur d'avoir des commentaires pertinents. Demander des conseils peut aider les gens à se lâcher.

Et aussi : https://www.linkedin.com/pulse/20130816200159-131079-employee-retention-now-a-big-issue-why-the-tide-has-turned

via: https://medium.com/latticehq/how-much-does-employee-turnover-really-cost-d61df5eed151

So if the cost of a developer who does negative work is so high, how do they get hired? Part of it can be explained by an interview process that needs improvement, but a less talked about part is the temptation to lower hiring standards.
Sometimes a company is in a situation where a lot of work needs to be done very quickly. If there are not enough developers in the company to accomplish that goal, then more developers need to be hired. Since developers have the advantage in the job market today, it can take quite a bit of time to make a good hire. That is when the temptation to lower hiring standards appears. When the amount of work is overwhelming, some people hire in a panic. They think having more bodies in the office can only contribute to more work getting done.
That is far from the truth. Not all developers will bring positive value to your team. I understand the pressure of tight timelines, but hiring in desperation won’t solve that problem. It’ll make it worse. Bad developers will not only slow you down, but they can cause your great developers to leave your company.

Ça me rappel vaguement quelque-chose...