Linus Torvalds durissimo su Elon Musk: 'troppo stupido' per lavorare in un'azienda tecnologica

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/web/li...ca_147200.html

In un recente video di Linus Tech Tips, Linus Torvalds ha criticato duramente l'idea di valutare gli sviluppatori contando le linee di codice prodotte, definendola una pratica incompetente. Il commento, collegato indirettamente alle richieste imposte da Elon Musk in Twitter dopo l'acquisizione, è rapidamente diventato virale online.

Click sul link per visualizzare la notizia.

[Fantapollo]

Poi pero' non ha proposto metriche migliori.

Come sempre, i sinistri detestano ogni sistema di valutazione.

[uazzamerican]

Originariamente inviato da Fantapollo

Poi pero' non ha proposto metriche migliori.

Come sempre, i sinistri detestano ogni sistema di valutazione.

Quando leggo questi commenti mi ricordo il motivo per cui meritiamo l’ estinzione.

Tutti allo stadio col bandierone dai! Chissenefrega

[metrino]

Originariamente inviato da Fantapollo

Poi pero' non ha proposto metriche migliori.

Come sempre, i sinistri detestano ogni sistema di valutazione.

Se non sai di cosa stai parlando sarebbe opportuno trattenersi dal commentare.

Io sono (anche ) uno sviluppatore.
Negli anni ho rimosso decine di righe di codice che oltre a essere illeggibili erano altamente inefficienti, query che duravano 1 ora invece che pochi minuti sostituire con query molto più piccole ed efficaci. Secondo quella metrica io sarei da licenziare e quello che ha scritto il codice schifoso da premiare. Quindi se uno dice che questa metrica è idiota, per me ha ragione a prescindere dal fatto che si dia un'alternativa. Fa più danni che stare senza.

Detto ciò secondo me dipende dalla disfunzione di Musk, deve per forza ridurre i problemi a situazioni molto semplici perché non ce la fa a concentrarsi troppo su una cosa.
Probabilmente ha sempre avuto alle sue dipendenze gente che riusciva a gestire problemi complessi e astratti , al posto suo. Le semplificazioni servono fino ad un certo punto, per semplificare un problema complesso il trucco è dividerlo in problemi più piccoli non semplificarlo a tal punto che non rappresenta più la realtà.

Sul lavoro i KPI sono gli obiettivi , da realizzare nei tempi previsti e senza troppi bug. Se.la gente per rispettare gli obiettivi deve fare troppi straordinari o consegna un codice pieno di errori o lo consegna con forte ritardo , c'è un problema.
Se questa cosa si ripete vuol dire che il problema sta nell'organizzazione del lavoro, quindi del team leader.
Se il problema si ripete su più team il problema è del capo reparto e così via. Apparentemente facile, semplificato solo per spiegarlo, ma questo è

[barzokk]

Originariamente inviato da Redazione di Hardware Upgrade

Di recente, un'importante azienda tecnologica ha chiesto agli sviluppatori di indicare quante righe di codice avessero scritto e, se non fossero state sufficienti, sarebbero stati licenziati.

ma è vera questa cosa ?

Cristo che immenso ******



EDIT: Mi sono autocensurato

[barzokk]

Originariamente inviato da metrino

Se non sai di cosa stai parlando sarebbe opportuno trattenersi dal commentare.

Io sono (anche ) uno sviluppatore.
Negli anni ho rimosso decine di righe di codice che oltre a essere illeggibili erano altamente inefficienti, query che duravano 1 ora invece che pochi minuti sostituire con query molto più piccole ed efficaci. Secondo quella metrica io sarei da licenziare e quello che ha scritto il codice schifoso da premiare. Quindi se uno dice che questa metrica è idiota, per me ha ragione a prescindere dal fatto che si dia un'alternativa. Fa più danni che stare senza.

Detto ciò secondo me dipende dalla disfunzione di Musk, deve per forza ridurre i problemi a situazioni molto semplici perché non ce la fa a concentrarsi troppo su una cosa.
Probabilmente ha sempre avuto alle sue dipendenze gente che riusciva a gestire problemi complessi e astratti , al posto suo. Le semplificazioni servono fino ad un certo punto, per semplificare un problema complesso il trucco è dividerlo in problemi più piccoli non semplificarlo a tal punto che non rappresenta più la realtà.

Sul lavoro i KPI sono gli obiettivi , da realizzare nei tempi previsti e senza troppi bug. Se.la gente per rispettare gli obiettivi deve fare troppi straordinari o consegna un codice pieno di errori o lo consegna con forte ritardo , c'è un problema.
Se questa cosa si ripete vuol dire che il problema sta nell'organizzazione del lavoro, quindi del team leader.
Se il problema si ripete su più team il problema è del capo reparto e così via. Apparentemente facile, semplificato solo per spiegarlo, ma questo è

io riempirei il codice di NOP, tanto è così incompetente che non se ne accorge, e mi dà pure un aumento

PS: per i muskiani che ovviamente non sanno cosa è un NOP:
https://en.wikipedia.org/wiki/NOP_(code)

[mozzarello]

Il lavoro deve essere pagato a risultati:

"mi serve questo, quanto ci metteresti"
"3 mesi"
"troppo"
"potrei farcela in 2"
"ok, quando arriva funzionante ti pago"

Così si premia il merito e si lascia completa gestione del proprio tempo al lavoratore

Ma chiaramente i lavoratori non vogliono perché preferiscono essere pagati per dormire (cit. Matrix Reloaded) e i datori di lavoro sono troppo stupidi per capire che tenere la gente legata a una scrivania è peggio.

Detto questo Musk ha fatto troppi soldi per essere stupido, quando dice qualcosa lo fa sempre per un motivo preciso, anche se il "vil popoletto" non lo capisce.

[demonsmaycry84]

il lavoro nel 2025 si basa sul colpire risultati in un dato tempo...poi nella mente dei titolari si traduce in un volerlo pagare ad ore perche' conviene a loro ed e' mentalmente in linea con le capacita' dell imprenditore medio italiano.
Se con 3 righe di codice riesco a fare miracoli e gioco per 11 mesi senza fare nulla ma colpisco il progetto allora forse non e' colpa mia ma di un manage incompetente che non riesce a capire il livello delle cose.
Va bene inviare qualcosa che dimostri che qualcuno lavora e non gioca imboscato pero' la solita cosa va chiesto ai dirigenti che lo hanno permesso.

[Gnubbolo]

twitter deve diventare il mezzo ufficiale di comunicazione della politica, degli enti pubblici e statali, deve essere autorevole.. quando c'era al potere la cricca, hanno sospeso la pagina del Re della Thailandia se ricordo bene.. non esiste proprio.
i femboy che postano le pics del pisello vadano su onlyfans, non c'è più posto per lor#

[Unrue]

Non c'è problema, basta usare l'assembly ed il numero di righe esplode

[alien321]

Originariamente inviato da uazzamerican

Quando leggo questi commenti mi ricordo il motivo per cui meritiamo l’ estinzione.

Vai avanti tu.....

In ogni caso, in ambito aziendale è un parametro che viene valutato. È giusto? Parzialmente si e infatti non è l'unico parametro.

Cmq il tutto era super pilotato per far dire a Linus quella frase dato che la situazione
in cui Elon ha detta quella frase era specifica e in un contesto ben preciso.

[io78bis]

Originariamente inviato da metrino

Se non sai di cosa stai parlando sarebbe opportuno trattenersi dal commentare.

Sul lavoro i KPI sono gli obiettivi , da realizzare nei tempi previsti e senza troppi bug. Se.la gente per rispettare gli obiettivi deve fare troppi straordinari o consegna un codice pieno di errori o lo consegna con forte ritardo , c'è un problema.
Se questa cosa si ripete vuol dire che il problema sta nell'organizzazione del lavoro, quindi del team leader.
Se il problema si ripete su più team il problema è del capo reparto e così via.

La spiegazione migliore +1000

[matrix83]

Originariamente inviato da Fantapollo

Poi pero' non ha proposto metriche migliori.

Come sempre, i sinistri detestano ogni sistema di valutazione.

A volte è meglio stare zitti piuttosto che commentare e dimostrare di essere un co....

Originariamente inviato da alien321

Vai avanti tu.....
In ogni caso, in ambito aziendale è un parametro che viene valutato. È giusto? Parzialmente si e infatti non è l'unico parametro.

In quale ambito aziendale? Con questa risposta credo che tu non abbia mai lavorato in nessuna azienda del settore. I nessuna azienda viene usato come parametro. In azienda si lavora per obiettivi come KPI.

[supertigrotto]

Musk ha ottime intuizioni ma non è un tecnico,Jobs era un beta tester non un elettronico/programmatore,quello lo era Wozniak e Gates.
Musk è il nuovo Jobs,nessuna competenza tecnica ma ha i soldi,tesla non è una sua creatura, è una azienda che ha rilevato e migliorato.
Quando la gente crede che sia lui a progettare le tesla,i razzi space X e altro,succede questo.
Torvalds in questo caso ha ragione.
Ricordo uno dei miei primi programmi a scuola,linee e linee di codice, funzionava pure,arriva il professore con la metà se non meno di linee di codice ha fatto funzionare il tutto e meglio,da lì ho capito cosa era l'ottimizzazione e la differenza di bravura fra un programmatore scarso e uno bravo e con esperienza.

[mozzarello]

Originariamente inviato da supertigrotto

Musk ha ottime intuizioni ma non è un tecnico,Jobs era un beta tester non un elettronico/programmatore,quello lo era Wozniak e Gates.
Musk è il nuovo Jobs,nessuna competenza tecnica ma ha i soldi,tesla non è una sua creatura, è una azienda che ha rilevato e migliorato.
Quando la gente crede che sia lui a progettare le tesla,i razzi space X e altro,succede questo.
Torvalds in questo caso ha ragione.
Ricordo uno dei miei primi programmi a scuola,linee e linee di codice, funzionava pure,arriva il professore con la metà se non meno di linee di codice ha fatto funzionare il tutto e meglio,da lì ho capito cosa era l'ottimizzazione e la differenza di bravura fra un programmatore scarso e uno bravo e con esperienza.

Rule of Three
- When you’re doing something for the first time, just get it done.
- When you’re doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
- When you’re doing something for the third time, start refactoring.

MAI ottimizzare qualcosa che funziona se non è critico farlo. MAI

[An.tani]

Originariamente inviato da supertigrotto

Jobs era un beta tester non un elettronico/programmatore

Jobs era un esperto di marketing con una superficiale infarinatura tecnica.

[TheDarkAngel]

Originariamente inviato da Redazione di Hardware Upgrade

Link alla notizia: https://www.hwupgrade.it/news/web/li...ca_147200.html

In un recente video di Linus Tech Tips, Linus Torvalds ha criticato duramente l'idea di valutare gli sviluppatori contando le linee di codice prodotte, definendola una pratica incompetente. Il commento, collegato indirettamente alle richieste imposte da Elon Musk in Twitter dopo l'acquisizione, è rapidamente diventato virale online.

Click sul link per visualizzare la notizia.

Torvalds è sempre una garanzia, poche parole e mai fuori posto. Sicuramente il GOAT.

[CrapaDiLegno]

Originariamente inviato da alien321

In ogni caso, in ambito aziendale è un parametro che viene valutato. È giusto? Parzialmente si e infatti non è l'unico parametro.

Davvero? Dimmi in che azienda lavori che la metto subito nella lista nera.
Non c'è davvero nessun motivo intelligente per usare quella metrica per misurare qualcosa. Anzi, ci sono mille motivi per ritenerla più dannosa che altro.
Se in azienda la state usando significa che chi ha deciso è un gran cojone che non merita il posto che occupa.

Questa cosa della valutazione non è certo nuova.
Anni fa ho lavorato per una delle più grandi aziende di ricerca e sviluppo qui in Italia.
Ovviamente si avvalevano di tutta una serie di aziende internazionali di consulenza per fare qualunque cosa. Gli assunti in azienda erano manager o supervisori, di fare qualcosa reale e pratico loro era ovviamente una umiliazione.
Un giorno c'è una mega riunione tra i capoccioni fancazzisti e tutti i team di sviluppo. A presiedere la riunione un bel team di indiani, indiani che erano presenti anche come un team di sviluppo (e non vi racconto cosa combinavano).
Quindi viene fatta tutta la spiegazione su come lavorare con gli strumenti interni (usavano roba che neanche nella preistoria, ma vabbè), Tricche e ballacche, acronimi a gogo, tabelle con disegni esplicativi, insomma la solita tiritera inutile montata in due ore di paroloni e super concetti che sembrava che stessimo iniziando a sviluppare per la NASA (ma nominare GIT era come bestemmiare).
Poi arriva il momento di dire come saremmo stati valutati nel nostro lavoro di sviluppatori... e indovinate un po'? Già, con il numero di linee scritte!.
E' partita una risata generale che neanche al teatro di Zelig.
La tizia indiana si è immediatamente vergognata di quanto stesse cercando inutilmente di spiegare, e nella baraonda in corso ha chiesto aiuto ai manager aziendali presenti che hanno subito capito che insistere sulla cosa era da dementi proprio.

Cosa cazzo vuol dire numero di linee scritte se magari per trovare un baco passo 4 giorni a rivedere il codice scritto da altri per poi magari dove togliere o mettere una sola riga, o un +1 o un /2?
Io sarei da licenziare mentre quello che ha scritto le 10.000 linee di codice in cui fare slalom tra tremila sottochiamate e variabili globali come se piovesse o strutture super annidate dove i membri si chiamano m,n, mmo, nnp, ttr, ccv, mcchs (MaCheCazzoHaiScritto) sarebbe da premiare?
Evidentemente nelle aziende in cui vige questo tipo di valutazione scrivono SW un tanto al chilo. Va giusto bene in India dove produco SW immondizia a tonnellate che poi va risistemato completamente quando viene consegnato.
Ma capo perché continuate a dare la voro agli indiani che poi dobbiamo riscrivere la metà del codice perché metà delle cose non funzionano?
Perché con il vostro stipendio ne paghiamo 3 di loro.
Si ma capo, 3 di loro non valgono metà di uno di noi, non è il numero che fa la differenza!
Alla fine dopo qualche anno di codice un tanto al chilo, dove probabilmente in India venivano pagati proprio per numero di linee, hanno finalmente smesso di dare loro lavoro. Ovviamente era troppo tardi, la concorrenza era già anni luce avanti negli sviluppi di cose che lì manco avevano ancora visto, forse perché non facevano della quantità la loro metrica.

[An.tani]

Originariamente inviato da mozzarello

Il lavoro deve essere pagato a risultati:

"mi serve questo, quanto ci metteresti"
"3 mesi"
"troppo"
"potrei farcela in 2"
"ok, quando arriva funzionante ti pago"

Così si premia il merito e si lascia completa gestione del proprio tempo al lavoratore

Certo, quanto descrivi è il desiderata di ogni imPRENDITORE, riversare il rischio d'impresa sui propri dipendenti

va bene se parliamo di un libero professionista che ti stacca fattura ma ovviamente lui ricaricherà su di te il fatto che

deve usare mezzi propri
deve lavorare 2 mesi senza vedere un becco di un quattrino
la fattura sarà a 30 giorni che ovviamente tu pagherai se va bene a 45, più probabile a 60

[barzokk]

Originariamente inviato da CrapaDiLegno

Davvero? Dimmi in che azienda lavori che la metto subito nella lista nera.
Non c'è davvero nessun motivo intelligente per usare quella metrica per misurare qualcosa. Anzi, ci sono mille motivi per ritenerla più dannosa che altro.
Se in azienda la state usando significa che chi ha deciso è un gran cojone che non merita il posto che occupa.

Questa cosa della valutazione non è certo nuova.
Anni fa ho lavorato per una delle più grandi aziende di ricerca e sviluppo qui in Italia.
Ovviamente si avvalevano di tutta una serie di aziende internazionali di consulenza per fare qualunque cosa. Gli assunti in azienda erano manager o supervisori, di fare qualcosa reale e pratico loro era ovviamente una umiliazione.
Un giorno c'è una mega riunione tra i capoccioni fancazzisti e tutti i team di sviluppo. A presiedere la riunione un bel team di indiani, indiani che erano presenti anche come un team di sviluppo (e non vi racconto cosa combinavano).
Quindi viene fatta tutta la spiegazione su come lavorare con gli strumenti interni (usavano roba che neanche nella preistoria, ma vabbè), Tricche e ballacche, acronimi a gogo, tabelle con disegni esplicativi, insomma la solita tiritera inutile montata in due ore di paroloni e super concetti che sembrava che stessimo iniziando a sviluppare per la NASA (ma nominare GIT era come bestemmiare).
Poi arriva il momento di dire come saremmo stati valutati nel nostro lavoro di sviluppatori... e indovinate un po'? Già, con il numero di linee scritte!.
E' partita una risata generale che neanche al teatro di Zelig.
La tizia indiana si è immediatamente vergognata di quanto stesse cercando inutilmente di spiegare, e nella baraonda in corso ha chiesto aiuto ai manager aziendali presenti che hanno subito capito che insistere sulla cosa era da dementi proprio.

Cosa cazzo vuol dire numero di linee scritte se magari per trovare un baco passo 4 giorni a rivedere il codice scritto da altri per poi magari dove togliere o mettere una sola riga, o un +1 o un /2?
Io sarei da licenziare mentre quello che ha scritto le 10.000 linee di codice in cui fare slalom tra tremila sottochiamate e variabili globali come se piovesse o strutture super annidate dove i membri si chiamano m,n, mmo, nnp, ttr, ccv, mcchs (MaCheCazzoHaiScritto) sarebbe da premiare?
Evidentemente nelle aziende in cui vige questo tipo di valutazione scrivono SW un tanto al chilo. Va giusto bene in India dove produco SW immondizia a tonnellate che poi va risistemato completamente quando viene consegnato.
Ma capo perché continuate a dare la voro agli indiani che poi dobbiamo riscrivere la metà del codice perché metà delle cose non funzionano?
Perché con il vostro stipendio ne paghiamo 3 di loro.
Si ma capo, 3 di loro non valgono metà di uno di noi, non è il numero che fa la differenza!
Alla fine dopo qualche anno di codice un tanto al chilo, dove probabilmente in India venivano pagati proprio per numero di linee, hanno finalmente smesso di dare loro lavoro. Ovviamente era troppo tardi, la concorrenza era già anni luce avanti negli sviluppi di cose che lì manco avevano ancora visto, forse perché non facevano della quantità la loro metrica.

it's funny 'cause it's true