> Elon’s engineers were given instructions to follow: they did. It’s how Elon’s companies are operate apparently.
Maybe I've worked different comments to everyone else, but if I was told by my boss to do something like deactivate X, change something to Y, or in this case, fire X% of people, do people really expect employees to not follow it?
This is much more than stupid, people who do educational workshops, training, assist others with their problems, SREs and performance engineers, database maintainers, people who delete code by adding functionality are one of the biggest investment in corporations like Twitter. Firing based on LOC is probably why self-driving Tesla is coming next year https://www.youtube.com/watch?v=o7oZ-AQszEI
The implication is that their instructions were much more detailed than "fire X% of people" and included using LoC as the metric, which nobody questioned.
(Any quantitative measurement of code quality will have too many outliers to be fair. LoC? Of course not. Number of closed PRs? You can't say much without knowing their complexity or severity. Etc. But they had to be quick, not fair.)
That’s probably the bit people find unusual.
Honestly, shouldn't Musk have a lawsuit coming from Telsa shareholders, since he's doing stuff like that?
Tesla's employees must be used to make Tesla successful, not to help the CEO on on some personal investment/project of his.
There are many reasons why in many engineering fields there's a licensing process and exam, but one of the most important ones, from the employee's perspective, is being able to say "No, I can't do that, I would lose my license".
I have tried to learn from my for-real licensed engineer friends what the profession means and emulate them. Without the safety net of a license or a code of ethics, it's mostly a self-indulgent exercise in what might be.
They may disagree and push back, but I am sure I won't be punished. Side effect is that they are used to argue for what they won't and completely ridiculous decisions (like judging by loc) are avoided.
Correct approach would be understand why there are so many people, figure out what is their job and then start removing those who are deemed unnecessary.
i.e. Imagine that you would come to new codebase and start throwing out code which does not appears to do anything and then be surprised that it is not possible to compile or you can't deploy or whole application will start crashing at random intervals.