Il fondatore ha risposto che stanno reagendo in modo eccessivo, e che ha una fiducia assoluta nelle capacità del nuovo lead, sulla base del suo CV e del colloquio, ed è proprio per questo che ha assegnato a questa persona il ruolo di lead developer in primo luogo.

Il capo ha parlato. Non è un governo o un partito politico. Non si può buttare fuori nessuno o guidare un'insurrezione.

Se non si è disposti ad affrontarlo, si ha davvero una sola possibilità. Potete riunirvi e minacciare di ritirarvi a meno che non succeda qualcosa.

Dico che potete, non che dovreste. Ci sono ottime probabilità che non finisca bene. In pratica stai cercando di metterti davanti al capo che ha preso la sua decisione e ai responsabili non piace che vengano messi in discussione.

Suppongo che la cosa “corretta” da dire sia trovare tecniche che lo incoraggino a vedere il tuo modo di pensare. Ma non ho intenzione di farlo. Sono uno sviluppatore senior di 30 anni e posso dirvi che sono diventato in gran parte impostato nei miei modi fondamentali. No, non sono un luddista come questo ragazzo e sì, accetto suggerimenti. Abbraccio le nuove tecnologie e così via. Questo ragazzo si sbaglia chiaramente su un sacco di cose. Tuttavia, quello che posso dirvi è che quando sono fissato su qualcosa e sono convinto di prendere la decisione giusta, mi attengo ad essa. Non prendo bene le minacce e la coercizione o la manipolazione è ancora peggio.

Il mio punto è che è convinto di essere “Gesù programmatore” (che è un triste atteggiamento sfortunato) e non lo cambierai mai, non in questa fase della sua carriera. È convinto di avere ragione e pensa che la sua esperienza lo supporti. Purtroppo, anche il capo lo pensa.

Onestamente, probabilmente non vale la pena di stressare te e la tua squadra. Suggerirei a ciascuno di voi di iniziare a cercare un nuovo lavoro e di andarvene quando ne avrete trovato uno. Quando una persona se ne va, assicuratevi che dica al capo il perché. Alla fine potrebbe farsi un'idea. Anche allora, non è una garanzia.

RUN Seriamente, non so perché qualcuno vorrebbe essere lì. Chiedetevi: c'è qualcosa in quello che ci avete detto che non sia un destino per il prodotto? Sono sicuro che lo sapete. Metto in dubbio l'intelligenza di base del fondatore per questo. Gli sviluppatori di solito fanno dei pessimi project/program manager. Si tratta di un insieme di competenze a parte e devono trovare un equilibrio tra loro. È come dire “non abbiamo bisogno di tester separati, i test degli sviluppatori funzionano benissimo”. Entrambe sono ricette per il disastro. Buona fortuna. Dico sul serio.

La descrizione della situazione da parte dell'OP è probabilmente unilaterale. Va bene così.

Sono un anziano sviluppatore (~54 yo) portato in un'azienda per non governare, ma per fornire un po’ di esperienza. (Il capo dell'IT in realtà ha detto “capelli grigi”, lol.) Lo staff di sviluppo era molto più abile, a conti fatti, di qualsiasi altro team con cui avessi lavorato in precedenza. Mi hanno insegnato molto, soprattutto sull'umiltà! Ma abbiamo trovato dei posti dove la loro stregoneria tecnologica non risolveva i problemi e in alcuni casi li nascondeva, peggiorandoli alla fine. È qui che sono stato in grado di dare il mio contributo.

Il vostro piombo sembra fortemente autocratico. Sembra che gli sia stato dato un mandato dal proprietario. Il proprietario è insoddisfatto dello staff dello sviluppo e ha fatto entrare questo tipo “duro e senza fronzoli” per migliorare la velocità di consegna.

Prima di tutto, guardate il vostro staff. Avete dei deboli - sviluppatori che non “vedono Matrix”? Se sì, trovategli nuove posizioni all'interno dell'azienda o date loro una buona referenza per un datore di lavoro che ha bisogno delle loro competenze uniche.

Odia gli IDE

Ne conosco alcuni che lo fanno. Mi fa roteare gli occhi, ma alla fine non mi interessa. Se la gente produce usando vi, allora va bene. Amo le mie IDE.

Non rifatta il codice, e non si preoccupa dello stile (che è incoerente nel suo codice)

Bandiera rossa sulla prima parte. È un copy-paster? Sono anche colpevole di non curarmi dello stile, ma questo perché uso il mio IDE per rendere immediatamente il mio codice Python PEP8 conforme. Ma non usa un IDE…

Come nota a margine, lo stile è stato precedentemente controllato da una build notturna, che ha iniziato a fallire dall'arrivo del nuovo lead.

Rifiuta l'idea di una build notturna, così come i test automatizzati. Secondo lui, “qualsiasi sviluppatore professionista testa il suo codice comunque a mano, quindi non c'è motivo di perdere tempo a scrivere test automatizzati”. Anche la costruzione notturna è una perdita di tempo, secondo lui.

Anche questo fa scattare un campanello d'allarme, ma per motivi diversi da quelli che ci si potrebbe aspettare. Prima che questo tizio venisse assunto, quante volte al proprietario è stato detto che non poteva fare X (dare una dimostrazione, usare il sistema, ecc.) perché la costruzione notturna non è riuscita? E se il proprietario percepisce che il problema è la costruzione notturna? Cosa pensi che direbbe al Lead di fare?

Ma ho delle preoccupazioni sull'atteggiamento del Lead; i test automatizzati sono incredibili. Come prima, il capo potrebbe non capire il valore dei test, ma di sicuro sa che è l'Y% dello stipendio dello staff del Dev a pagarli. Quando sono arrivato nella mia attuale azienda, la “mafia della copertura del 100% dei test” aveva preso in carico lo staff di sviluppo e ha fatto lievitare i costi. Una mela marcia in seguito e lo staff di dev stava facendo di nuovo le fusa.

Pensa che il controllo delle versioni sia per lo più inutile…

Questa è una bandiera rossa di altissimo livello. Si sbaglia il più possibile. Si sta comportando in modo irresponsabile con i soldi del proprietario.

Sopravvaluta l'importanza dell'ottimizzazione del codice.

Ai tempi, l'ottimizzazione del codice poteva fare la differenza. Ora le macchine sono così veloci che è meno importante. Ora dobbiamo invece preoccuparci delle prestazioni del database e del throughput della rete. Ma la sua abitudine di “ottimizzazione del codice” è un'abitudine difficile da rompere, credetemi. Devo fare in modo di non preottimizzarmi. Almeno il suo comportamento in questo caso non è distruttivo, se non per il tempo impiegato. (Hai i numeri per la sua “metà del suo tempo” o è un'iperbole? Se stai criticando il tuo supervisore, nessuna iperbole può essere ammessa. Devi essere patologicamente obiettivo).)

Scrive tutto l'SQL a mano, e rifiuta l'idea di un ORM.

Colpevole! Non capisco la paura della gente per l'SQL. Non capisco seppellire l'SQL, che è semplice, sotto strati di ORM che offusca. Non posso aiutarti qui :-D Ma per favore, scarica tutto il tuo SQL in un unico posto - non distribuirlo tutto nel tuo codice.

e due dei cinque sviluppatori non hanno mai usato l'SQL prima.

Questo è inaccettabile. Siamo nel 2016. Hanno bisogno di competenze.

Rifiuta i framework e le librerie di terze parti, considerando che è molto più facile scrivere roba da zero.

Non potrebbe essere più sbagliato. Dubito che la sua azienda sia così speciale che le sue utilità debbano essere scritte internamente. Avevamo alcuni sviluppatori che abbracciavano strumenti di terze parti - fino a quando non hanno fatto qualcosa che non piaceva allo sviluppo. Era una scusa per buttare via lo strumento e scrivere il proprio. Questo non fa altro che aumentare il carico di lavoro dello staff dello sviluppo, rallentandolo ulteriormente. Questo codice inutile è costoso da scrivere, testare, eseguire il debug e mantenere. Abbiamo speso così tanti soldi per -zero- benefici. Questi sviluppatori se ne sono andati.

Ha deciso di abbandonare tutte le librerie JavaScript e i framework ad eccezione di jQuery, sostenendo che quando ha iniziato a programmare in JavaScript quindici anni fa, non c'erano framework, e la vita era molto più facile.

Questo non è così chiaro. La ragione è che la vita era molto più facile 15 anni fa è che la domanda d'affari era molto più semplice. Ecco da dove è venuto il problema. Il web è stato inventato come sistema batch (compilare un modulo, inviarlo, ottenere una risposta, ripetere) e ora stiamo cercando di scrivere applicazioni web che si comportano come applicazioni desktop. La sua osservazione è giusta, le cose sono difficili ora. Ma non si rende conto del perché. La complessità degli strumenti è la risposta a una domanda di business più complicata. Così fa scelte sbagliate.

Stiamo usando AngularJS e sembra essere decente. Come tutti gli strumenti potenti, può essere usato per il bene o per il male.

Pensa che i dispositivi mobili (compresi i tablet) siano solo una montatura, quindi non c'è motivo di perdere tempo prezioso per garantire la compatibilità del sito con questi dispositivi e per fare un design reattivo. Il prodotto è un'applicazione web pubblica che non ci si aspetta che venga utilizzata molto dai dispositivi mobili.

Si sbaglia di nuovo. Non sono un'illusione. Sono qui per restare perché sono utili. Ma il business non ne ha bisogno. Non sviluppate cose di cui non avete bisogno. È costoso.

Il design reattivo, tuttavia, potrebbe essere molto interessante da avere per questa app,…

È così interessante che pagheresti personalmente per lo sviluppo? Se questa è una buona idea, dovreste essere in grado di vendere l'idea al proprietario. Altrimenti, non spendeteci un centesimo.

Chiede al team di smettere di usare internet (specialmente StackOverflow) e di affidarsi al cervello, alla documentazione offline (non sapevo nemmeno che Microsoft vendesse ancora CD MSDN!) e ai libri.

Si sbaglia. Internet è ottimo per questo. Se lo staff di Dev sta copiando da Stackoverflow senza capire come funziona il codice, allora anche loro si sbagliano. C'è tempo per la formazione e il miglioramento personale nel programma di sviluppo? È difficile non copiare-incollare roboticamente quando si è sempre sotto tiro.

Anche se ho informazioni limitate, ci sono molti problemi qui. Sembra che il proprietario non abbia ottenuto il codice che sta pagando così velocemente come si aspetta. Sembra che abbia sentito un sacco di scuse su cose di cui non gli importa nulla; è concentrato sul risultato. Se ho ragione, ha una ferita autoinflitta e l'ha riaperta più di una volta. Questo piombo è la soluzione del proprietario al problema che lo staff del Dev ha posto, e date le sue informazioni limitate, è comprensibile.

Scommetto anche che stai gestendo un negozio non agile e hai una definizione dei requisiti scadente che cambia con il vento. Non c'è uno strato di isolamento tra lo staff dello sviluppo e il proprietario. Ad eccezione di questo Lead.

Ora, cosa potete fare?

1) Istruire il lead che l'uso di test automatizzati e la gestione del codice è la strada da seguire. Potrebbe essere necessario del tempo per guadagnare credibilità con lui - probabilmente il proprietario gli ha detto che il personale è difettoso. Vedete se riuscite ad impedirgli di fare mandati radicali come “cancellare tutte quelle inutili stronzate di test e riutilizzare il server SVN”. Questo vi darà il tempo di mostrare il valore.

2) Continuare ad usare la gestione del codice a livello personale. Almeno così potrete recuperare dai vostri errori. Non ditegli che lo state facendo, ma non mentitegli nemmeno.

3) Continuate a eseguire test automatizzati (test unitari, se non altro) a livello personale. Come prima, non menzionatelo, ma non nascondeteglielo.

4) Lavorate con il Piombo per determinare quali sono i problemi effettivamente percepiti. Siate di mentalità aperta; scommetto che ci sono problemi reali con il personale. Lavorare con il piombo per affrontare i problemi, non i sintomi.

5) Discutere con il piombo vari argomenti di sviluppo, come i benefici della cascata e dell'agilità. Nessuno dei due è perfetto. Ponetegli domande come: “In quali circostanze i test automatizzati sarebbero utili”? Se dà una risposta dubbia, chiedetegli quanto le aziende di successo come Google sono riuscite a prosperare nonostante ciò.

Quindi potete vedere che sono tutto preso dal coinvolgimento del Lead e vedere dove sta la sua testa. Costruire la fiducia. Concordare su questioni e sintomi. Non è sempre facile, soprattutto quando senti che è come Godzilla e che sta facendo a pezzi il tuo lavoro.

C'è la possibilità che non riesca a scendere a compromessi. Schiaccerà i test automatizzati. La gestione del codice è per le persone disattente. My Way o l'Autostrada.

Se è arrivato a questo punto, però, sarà il momento di andarsene. Lavorare in un negozio senza strumenti, e intendo dire software e strumenti di ingegneria del software - non costruisce il vostro curriculum. Comincerete a marcire nello stesso modo in cui è marcio il Piombo. In questo caso, andate avanti.

venticinque anni in IT […] cambiare il suo atteggiamento

Non funzionerà, mi dispiace.

Il tuo vero problema non è l'incompetente lead developer. Questo problema è insignificante rispetto al problema reale che descrivete:

Il vostro fondatore si fida più di uno sconosciuto incompetente che dei suoi attuali dipendenti.

Dovete capire come il team ha perso la sua fiducia e come riconquistarla. Questo sarebbe stato più facile se fosse stato fatto prima che lo sconosciuto venisse assunto. Ora questo è difficile, perché ogni buon lavoro sarà attribuito al nuovo capo squadra, e ogni lavoro scadente sarà attribuito a tutti voi - quindi non si può rimediare lavorando più duramente.

Ci sono solo 2 cose che mi vengono in mente, per migliorare la situazione in questo lavoro:

1. 1. Trovare un mediatore. Ci sono più fondatori, o qualcosa come i membri del consiglio di amministrazione?
2. Trovare un mediatore. Forse il problema della fiducia è un problema di visibilità. In questo caso, qualsiasi cosa che aiuti la visibilità aiuta. Ad esempio, rendere le dimostrazioni di sprint abbastanza emozionanti e interessanti da far sì che il fondatore partecipi e venga a conoscenza dello stato e dei progressi del team.

* Mentre la maggior parte dei punti sollevati dall'OP non necessariamente rendono lo sconosciuto incompetente, il suo approccio al Controllo di versione e all'Integrazione continua in un team di 5 persone lo fa di certo.

Questa risposta potrebbe essere sfavorevole e considerata grossolana da alcuni ma…

La prima bandiera rossa è For a few years, the founder was unhappy about the technical skills of the employees

I dipendenti hanno tentato di rimediare all'infelicità?

La seconda bandiera rossa è two of the five developers never used SQL before

È difficile creare un sistema efficiente se gli sviluppatori non hanno familiarità con le tecnologie di base e non capiscono veramente cosa sta mascherando l'ORM.

È difficile immaginare che I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a ******. sia stato effettivamente pronunciato, ma lo prenderò in considerazione e vi crederò.

Tuttavia, considerate la prima bandiera rossa che ho menzionato e l’“infelicità” che il fondatore ha dovuto affrontare per anni.

A questo, aggiungo: voi ragazzi conoscete l'infelicità del fondatore da anni?!

Come vi sono state divulgate queste informazioni?

Sono propenso a pensare che questo ragazzo stia facendo precisamente ciò per cui è stato assunto; rimettervi in forma.

Mettervi in forma non significa adottare le cattive pratiche del nuovo ragazzo, ma significa gettarvi fuori dalla vostra zona di benessere per imparare a un livello più profondo.

Per alcuni anni il fondatore non è stato soddisfatto delle competenze tecniche dei dipendenti e ha recentemente assunto un senior developer per il doppio ruolo di responsabile tecnico e project manager. È stato l'unico a fare un colloquio, e l'unico a decidere di assumere questa persona.

Sembra che il fondatore non si fidi di voi.

Il team, tuttavia, è diventato molto meno riconoscente del suo profilo nell'arco di due mesi. Ho avuto l'opportunità di parlare con tre dei cinque membri di questo team, e tutti hanno evidenziato tre questioni:

• Secondo loro, il ragazzo è un idiota, e non ha alcun rispetto per gli altri membri del team. Una sua recente citazione, che parlava con un programmatore junior davanti al team, è molto illustrativa: “Ho lavorato per venticinque anni in questo settore, e tu? Che cosa hai fatto? Sei stato una scimmia di codice per tre anni. Quindi chiudi il becco, idiota! A nessuno interessa la tua opinione, a nessuno interessa la tua opinione”.

Sembra che tu abbia una sola versione della storia. Posso immaginare alcune situazioni in cui potrei aver bisogno di prendere a schiaffi un giovane sapientone, e l'ho fatto. Qual è stata la provocazione?

• In passato, le decisioni venivano prese da tutti i membri della squadra. Quando i membri non erano d'accordo, ne discutevano insieme e si mettevano d'accordo, o almeno spiegavano il ragionamento a chi non era d'accordo.

apparentemente, le pratiche passate non hanno generato i risultati che il fondatore voleva.

Ora, tutte le decisioni importanti sono prese esclusivamente dallo sviluppatore principale. Queste decisioni non possono essere messe in discussione o discusse, anche se tutti e cinque i membri del team trovano che una decisione non ha senso.

Ancora una volta, sembra un voto di sfiducia da parte del fondatore. Ha portato questo tipo di persona per un motivo. Sembra che il motivo sia stato quello di mettere in forma il resto dello staff.

1. Odia gli IDE, l'auto-completamento e le funzioni che hanno lo scopo di aiutare i programmatori a scrivere codice più velocemente, e sostiene che il team dovrebbe usare Notepad++ per essere produttivo. Anche se ha senso in circostanze diverse, è difficile immaginare che gli sviluppatori di C# abbandonino improvvisamente Visual Studio per Notepad++.

IDEs possono rallentare se sei un programmatore veloce. Notepadd ++ è superiore ad alcuni per la codifica rapida. L'idea è che tu scrivi il tuo codice, poi lo lasci cadere nell'IDE per una correzione rapida invece di continue interruzioni.

1. Non rifattorizza il codice, e non si preoccupa dello stile (che è incoerente nel suo stesso codice), il motivo è che “si preoccupa solo delle cose che contano veramente”. Come nota a margine, lo stile è stato precedentemente controllato da una build notturna, che ha iniziato a fallire dall'arrivo del nuovo lead.

Shop standard sono qualcosa di cui discutere con il fondatore, soprattutto perché lo si sta eseguendo attraverso la build notturna. Ma ancora una volta, leggendo tra le righe, sembra che il fondatore non si fidi di te.

1. Rifiuta l'idea di una costruzione notturna, così come i test automatizzati. Secondo lui, “qualsiasi sviluppatore professionista testa il suo codice comunque a mano, quindi non c'è motivo di perdere tempo a scrivere test automatizzati”. Anche la costruzione notturna è una perdita di tempo, secondo lui.

Ha ragione, i test automatici non spiegano la genialità di un pazzo che fa qualcosa che non ha mai voluto fare. Personalmente ho rotto diversi programmi che sono passati attraverso i test automatizzati.

1. Pensa che il controllo di versione sia per lo più inutile, e sembra fraintendere come usarne uno. Questo porta a situazioni in cui sviluppa una funzione da solo per tre o cinque giorni, e quando finalmente commette i suoi cambiamenti, “prende il mio” per tutti i conflitti. Se altri membri del team si lamentano che il loro codice è stato cancellato, li invita a riscriverlo. In diverse occasioni, altri membri hanno fatto lo stesso, cancellando il codice dello sviluppatore principale. Sembrava sorpreso (sembra che non sappia usare svn log o diffs), e fece di nuovo le sue modifiche, lamentandosi che “erano misteriosamente persi” e incolpando SVN per aver fatto un casino.

Tutti hanno colpa qui. Non c'è nessuno che fa il backup? Se ha problemi con il controllo delle versioni, è responsabilità del team lavorare in squadra e non solo dargli filo da torcere.

1. Egli esagera l'importanza dell'ottimizzazione del codice. Il suo approccio è corretto, cioè esegue un profiler, determina un collo di bottiglia e lo risolve; il problema è che non ci sono requisiti non funzionali di performance, e nessun elemento che indichi che gli utenti possano considerare l'applicazione come lenta (e ospitata su VM di sviluppo di basso livello, l'applicazione sembra molto reattiva). Egli, d'altra parte, passa praticamente la metà del tempo ad ottimizzare il codice.

Non c'è modo di esagerare l'importanza dell'ottimizzazione del codice. Lo scopo dell'ottimizzazione del codice non è quello di assicurarsi che funzioni correttamente oggi lo scopo è quello di ottimizzarlo in modo che non risolvete qualche problema a tre anni di distanza che si sarebbe potuto evitare con l'ottimizzazione del codice.

Se vi interessa solo che gli utenti siano felici oggi, domani li farete bussare alla vostra porta.

1. Scrive tutto l'SQL a mano, e rifiuta l'idea di un ORM. Si noti che il prodotto attuale è basato sull'ORM Entity Framework di Microsoft, e due dei cinque sviluppatori non hanno mai usato l'SQL prima.

Due dei cinque sviluppatori dovrebbero essere licenziati allora. Se ci si affida a un ORM, non si potrà mai arrivare sotto il cofano e aggiustare le cose manualmente. Comincio a capire perché ha chiamato qualcuno “scimmia di codice” in preda alla frustrazione. Gli ORM vanno bene e sono buoni, ma bisogna capire l'SQL se si vuole andare oltre le limitazioni di un ORM.

1. Rifiuta i framework e le librerie di terze parti, considerando che è molto più facile scrivere roba da zero. Ha deciso di abbandonare tutte le librerie e i framework JavaScript tranne jQuery, sostenendo che quando ha iniziato a programmare in JavaScript quindici anni fa, non c'erano framework, e la vita era molto più facile.

Ha ragione. I framework e le librerie di terze parti hanno delle limitazioni, e se non si capisce abbastanza per andare a sistemarli da soli, non si capisce il codice. Un'argomentazione può essere fatta in entrambi i casi. Se, tuttavia, nessuno del team è in grado di codificare senza usare i framework, allora avete un team molto debole.

1. Pensa che i dispositivi mobili (inclusi i tablet) siano solo una montatura, quindi non c'è motivo di perdere tempo prezioso per garantire la compatibilità del sito con quei dispositivi e per fare un design reattivo. Il prodotto è un'applicazione web pubblica che non ci si aspetta che venga utilizzata molto dai dispositivi mobili. Il responsive design, tuttavia, potrebbe essere molto interessante da avere per questa applicazione, dato che anche sui desktop, sarà visualizzato sia su monitor da 19 pollici che su quelli ad alta risoluzione di grandi dimensioni.

Da tutto quello che hai detto, sembra che sia stato portato in casa pulita. Se i dispositivi mobili non sono uno dei principali protagonisti dell'applicazione (o delle applicazioni), passare troppo tempo è uno spreco. Mentre potrebbe essere un “bello da avere” su un desktop, un “bello da avere” non è una necessità per il rollout.

1. Chiede al team di smettere di usare internet (specialmente StackOverflow) e di affidarsi al cervello, alla documentazione offline (non sapevo nemmeno che la Microsoft vendesse ancora CD MSDN!) e ai libri.

Buon per lui. Sembra che voglia sapere chi può fare i propri compiti e chi ha imbrogliato.

I membri del team si sono lamentati con il fondatore dell'azienda per la loro nuova guida su questi tre temi. Il fondatore ha risposto che stanno reagendo in modo eccessivo e che ha una fiducia assoluta nelle capacità del nuovo lead, sulla base del suo CV e del colloquio, ed è proprio per questo che ha assegnato a questa persona il ruolo di lead developer in primo luogo.

Cosa dovrebbe fare il team per:

• O buttare il lead fuori dal team o dall'azienda,

• O costringerlo a cambiare il suo atteggiamento verso il team?

Che ne dite di lavorare con lui e non sabotare ogni sua mossa?

In tutta onestà, sembra che sia stato portato a fare pulizia, visto quello che avete pubblicato, sembra più che giustificato.

Il proprietario NON è soddisfatto della vostra prestazione. Sarebbe d'obbligo seguire i consigli di questo tizio per quello che vale. Noi reliquie abbiamo un po’ di esperienza e sappiamo quello che i libri non vi insegneranno mai. Eppure, piuttosto che vederla come un'opportunità per imparare e crescere, il vostro team sta avendo un'enorme crisi isterica.

Quindi non so fino a che punto i membri del vostro team si siano lamentati con il vostro capo per il capo. Ma avete avuto una buona conversazione a tavola con loro? Spiegate al vostro capo i problemi che state avendo con il capo e lasciategli la sua versione della storia.

L'abbandono dovrebbe essere l'ultima risorsa.

Il proprietario deve assumere un responsabile del personale

Altre risposte hanno accennato a questo, ma l'elefante nella stanza è che il proprietario (comprensibilmente) sembra avere difficoltà a svolgere con successo funzioni di personale come l'assunzione, l'addestramento, il licenziamento, ecc. Un esempio: il proprietario assume un team di personale non molto efficiente, lo sopporta per anni, poi assume un veterano di 25 anni per sistemare le cose, poi assume un consulente quando il veterano di 25 anni non è in grado di sistemare le cose. Il proprietario non sembra sapere come gestire il lato del personale. Va bene, ci sono persone che lo fanno per vivere, ed è per questo che la maggior parte delle organizzazioni ha dei manager. Il proprietario deve assumere una sola persona. Questo libererà il proprietario dalla necessità di concentrarsi sul lato strategico dell'azienda, quindi è una vittoria. Forse l'OP potrebbe aiutare con i colloqui (dopo tutto, il proprietario sembra aver bisogno di aiuto a questo proposito)?

Una “ruga” che non ho ancora visto qui. È abbastanza comune per le persone con molta esperienza mettersi sulla difensiva per non essere al passo con gli sviluppi attuali. Ero solito fare lo stesso con le persone che parlavano di quanto fosse orribile il VB6 in relazione al meraviglioso .Net, quando quelle persone non facevano altro che ripetere cose che avevano sentito sul VB6 e non ne sapevano molto.

Come dice lei, molte delle cose che il leader dice sono giuste. Ma questo non significa che lo siano tutte, come dice lei. Forse il signor 25 anni può aprire la sua mente e sintetizzare il suo approccio con il meglio dello status quo, ma non se ha paura di essere meno che perfetto e nega di avere paura. Per quanto mi riguarda, questo è il vero problema. Ci possono essere altri problemi con i juniores (sulla difensiva per la loro mancanza di competenza, per esempio), ma questo sembra essere il problema di fondo.

Se tutti si riuniscono e affrontano le loro paure in modo aperto e onesto, allora dovrebbero cominciare a muoversi in una direzione più positiva. Non posso dire che sembri un'alta probabilità, ma è ciò che va fatto.

1. L'intero team ha parlato con questo sviluppatore e ha cercato di spiegare i vantaggi di cose come il controllo di versione e gli IDE? Una franca discussione in massa può aiutare

2. Sono d'accordo che insultare gli altri sviluppatori non è professionale e questo dovrebbe essere spiegato con forza. Chiedetegli se è contento se gli altri adottano lo stesso tono

3. 1. Chiedetegli se sta subendo uno stress domestico o se ha un problema di salute come il diabete che lo rende irritabile. 4. Chiedetegli se è contento di diventare vecchio e un vecchio imbecille scontroso con la mente atrofizzante mentre non impara nulla di nuovo

4. Se tutto il resto non riesce, dite che tutti i suoi errori saranno documentati per salvare la vostra pelle e le conversazioni con lui potranno essere registrate