Beh, mi dispiace farti scoppiare la bolla, ma se questa è la terza volta che succede, questo esclude quasi che “non sei tu, sono loro”. Il tuo titolo dice che sei stato licenziato per essere “indispensabile” ma a parte questo essere un ossimoro, non è neanche quello che è successo. Sei stato licenziato per aver scritto del codice che i tuoi colleghi non possono capire, il che è un problema critico di prestazioni per un programmatore.

Il buon codice è codice leggibile , cioè un codice facilmente comprensibile, anche per i novizi. Le situazioni in cui si ha bisogno di codice complesso e strettamente scritto, che dovrebbe essere scritto e mantenuto da veri esperti, sono molto rare al giorno d'oggi ed evidentemente non si lavorava per questo tipo di aziende. Quello che descrivete suona più come codice “di fantasia”, che è tipicamente troppo complesso, pieno di trucchi di programmazione esoterica e ci vogliono anni per capire e fare il debug. È un fallimento comune per le persone che sono state formate in modo classico e che di solito si trovano ad affrontare un brusco risveglio una volta entrati in un ambiente produttivo.

Non è uno scherzo, non potrei sopportare che accadesse una quarta volta, mi sta influenzando mentalmente.

Questa linea è importante, perché dimostra che si sente che è il momento di cambiare. Mostra che lo riconosci come uno schema, e vorresti che lo schema si fermasse. Questo desiderio è probabilmente la parte più importante della soluzione. Per risolvere questo tipo di situazioni spesso è necessario cambiare il modo in cui voi stessi pensate. È impossibile che qualcuno lo faccia per te, quindi il tuo desiderio di cambiare sarà l'unica cosa che farà sì che il cambiamento avvenga.

Per alcuni precedenti, mi sono già trovato in situazioni simili “troppo bravo a codificare per il mio lavoro”, anche se mai nella misura da te descritta. Potrei curare il cancro con la metaprogrammazione di modelli in C++, ma molti di quelli con cui lavoro hanno a malapena familiarità con le basi del design orientato agli oggetti. Ho scritto codice che ha abusato di SFINAE e si è spinto proprio contro la formulazione esatta delle specifiche C++, quando molti progetti a cui ho lavorato utilizzavano ancora versioni antiquate e buggy di gcc. Il mio approccio era semplicemente quello di mostrare loro quanto questi strumenti siano stupefacenti, e tutti i problemi che potevano risolvere. Mi piaceva spiegare piccoli consigli di programmazione alla gente, e a loro piaceva molto.

Suona familiare?

“Sì, ma si dovrebbe avere un buon livello di comprensione [del codice di Mik] perché i componenti sono intelligentemente disaccoppiati”.

Considerate questa affermazione da una prospettiva basata sul rischio. Il tuo capo ha bisogno di far andare avanti le cose, a qualsiasi costo. Se te ne vai a caccia di qualche fantastica opportunità di lavoro, il tuo capo deve comunque assicurarsi che il codice venga mantenuto. Quello che il vostro collega ha appena detto è che, se devono sostituirvi, hanno bisogno di trovare un codificatore molto abile, perché chi non è così bravo non sarà in grado di mantenerlo. Questo è un rischio. E se non riescono a trovare uno sviluppatore abbastanza bravo, o non possono permettersi di pagarli abbastanza?

Avrete anche prodotto quello che chiamereste “buon codice”, ma la definizione di “buon codice” dipende molto dal contesto. Quello che è “buon codice” in Google, con i loro modi di pensare all'avanguardia, può essere un pessimo codice per qualcuno che lavora alla FAA, che si preoccupa principalmente dell'affidabilità piuttosto che di stare al passo con l'avanguardia. La definizione di “buon codice” del vostro capo include la capacità di mantenerlo in ogni tipo di situazione, anche senza di voi. Se i vostri colleghi non si sentono a proprio agio nel mantenere il vostro codice, allora siete improvvisamente una affidabilità per l'azienda, perché producete un prodotto che non possono mantenere se decidete di andare altrove.

Da questo punto di vista, si può sostenere che li state costringendo ad accettare la vostra definizione di “buon codice”. Istintivamente, può sembrare una cosa buona, ma è irta di difficoltà, come questo modo di pensare basato sul rischio, a cui forse non avete pensato.

Abbiamo una frase, “mettere il carro davanti ai buoi”. Uno dei molti significati associati ad essa è mettere il contenuto a cui tieni di più (essere in grado di usare le tue tecniche avanzate) sopra le forze che dovrebbero tirarlo in avanti (la comprensione di queste tecniche da parte del tuo collega). Avete scritto il codice in questo stile avanzato, e poi avete incoraggiato gli altri sviluppatori a “mettersi in pari” con questo stile. Questo può essere efficace, ma se vi succede qualcosa prima che “recuperino il ritardo”, l'azienda è improvvisamente a rischio perché nessuno può mantenere il codice.

Come posso evitare questo in futuro?

Risolvere questo problema può essere una cosa terribilmente difficile da fare perché comporta l'approccio al problema in un modo diverso da quello che si è abituati ad affrontare. Invece di scrivere prima il codice in questo stile avanzato, e poi insegnare ai vostri colleghi a pensarla in questo modo, dovreste capovolgerlo. Insegnate ai vostri colleghi ad apprezzare questo stile di codifica e poi iniziate a scrivere codice in questo stile. Può sembrare al contrario, ma è molto più stabile. Dal punto di vista del capo, c'è poco o nessun rischio che il team impari a codificare meglio. Una volta che codificano meglio, lo stile che si vuole sviluppare è improvvisamente meno rischioso.

Nel frattempo, si dovrà scrivere codice che, secondo i vostri standard, è “meno buono”, ma va bene così. Il vostro codice non è il vostro unico prodotto. Il vostro altro prodotto sta aiutando a insegnare agli altri sviluppatori, e il valore di questo può facilmente superare il valore della scrittura di “codice perfetto”.

Naturalmente, può essere difficile capire quando è sicuro scrivere codice nello stile in cui si vuole scrivere. Se fosse facile da capire, l'avreste già capito! Una tecnica potente che si può usare è quella di lasciare che altri spingano per gli stili di codifica avanzati, piuttosto che spingerli da soli. Una cosa è insegnare a qualcuno la differenza tra eredità e composizione. È una cosa completamente diversa insegnargliela abbastanza bene da fargli capire che è favorevole a cambiare la vostra base di codice esistente per essere più chiaro quando la usa. Quest'ultimo caso ti fa capire che non solo ottengono il concetto, Un ideale per insegnare questi concetti è quello di non insegnare nulla. Lasciate che gli studenti scoprano qualcosa e poi indirizzateli in una direzione che la scoperta può andare. Forse uno di loro scoprirà qualcosa di interessante sull'eredità e potrete indirizzarli verso il modello di design dei Visitatori in base a ciò che hanno scoperto. Non date loro solo il Visitor, ma date loro un senso di orientamento in modo che possano uscire e trovare il Visitatore da soli.

È un approccio molto più difficile, e sicuramente vorrete trovare un mezzo felice tra questo e il vostro approccio attuale, ma può essere molto gratificante. Ancora più importante per la vostra risposta, può fornire valore all'azienda senza rischi. Se state fornendo valore a un'azienda e non la mettete a rischio, non sarete praticamente mai licenziati. E nei pochi casi in cui è ancora possibile essere licenziati, il management fornirà una ragione per questo (come ad esempio un rallentamento dell'economia, o un cambiamento di direzione dell'azienda). Se lo fai molto bene, scoprirai che il management invece inizierà a plasmare il tuo percorso, proprio come tu plasmi i tuoi colleghi, e troverai una curiosa tendenza ad aver imparato solo la giusta abilità solo quando ne hanno più bisogno.

Ci sono sempre delle ragioni.

Un precedente datore di lavoro ha fatto questo con un mio collega. Il suo livello di competenza andava ben oltre le nostre capacità. Quindi, è stato licenziato.

Perché questo ha senso?

1. Era l'unico in grado di mantenere il suo codice
2. 2. Non era collaborativo. 3. Non ha seguito gli standard del negozio
3. 4. Mentre consegnava più del necessario, non era una buona cosa
4. Semplice, c'era bisogno di soluzioni invece di soluzioni complesse.

Si dice così spesso che è quasi un cliché, ma bisogna essere “buoni” per il team.

La codifica è solo una parte dell'equazione. Dovete essere persone, comunicativi, umili, umili fino a un certo punto, arroganti quando serve, rispettare gli standard del negozio, andare d'accordo con i vostri colleghi, essere disponibili e rapidi nell'aiutare quando serve.

Tutte queste abilità soft sono importanti, e non averle vi creerà dei problemi.

Un buon codice è facile da capire, anche per i poveri ingegneri. Un consiglio che ho ricevuto spesso è “programma come se la persona che manterrà il tuo codice fosse un programmatore mediocre, e un pericoloso psicopatico che sa dove vivi”.

Ed è vero. Una programmazione troppo intelligente è un male, perché la manutenzione è più lunga quando non si conosce il codice. Nella manutenzione, spesso ci sono incendi ovunque, migliaia di clienti bloccati, e una soluzione più intelligente ed efficiente potrebbe benissimo tenere il manutentore bloccato più a lungo di un codice stupido tipo script pieno di ripetizioni.

Naturalmente, anche il codice completamente stupido è un male. C'è un buon equilibrio tra stupido e geniale: efficiente, e ancora leggibile. È più un'arte che una scienza. Ecco perché concetti intelligenti come l'eredità multipla di solito non sono consigliati . Anche se dondolano.

Bisogna tener conto del contesto. Se lavorate in una piccola azienda di periferia che assume solo i migliori, probabilmente potete permettervi cose esotiche e brillanti. Se lavorate per una banca francese che si affida solo a consulenti di, errrm, qualità casuale (a volte sono fortunati, a volte no), e dove ogni consulente ha un dominio di milioni di LOC da mantenere, allora con ogni mezzo rendete semplice abbastanza semplice che un mediocre lo capisca a prima vista. Nessuna indicazione, nessuna eredità multipla, nessun trucco intelligente, ecc…

È improbabile che tu sia licenziato perché sei troppo bravo. Immagino sia solo una scusa.

È molto più probabile che si tratti di un problema di comportamento, o che il capo non ti voglia bene per ragioni che non può dirti senza creare motivi per una causa. È anche possibile che tu sia il più costoso e che loro credano negli ETP (cioè che ogni lavoratore è uguale all'altro).

Se sei davvero così bravo, puoi renderti indispensabile in un buon modo:

• Mentore i programmatori junior. Raccontate i vantaggi e gli svantaggi dei diversi approcci e lasciate che facciano i loro errori invece di dire loro quale approccio adottare.
• Scrivete del buon codice che sia facile da mantenere da parte di altre persone.
• Promuovete le migliori pratiche in modo da aumentare la produttività, in contrapposizione alle cargo cult best practices, che suonano bene sulla carta ma uccidono la produttività.

Licenziare le persone indispensabili è in realtà una sana strategia di gestione. Quando la vostra azienda si affida a una sola persona che continua a svolgere il proprio lavoro e nessun altro all'interno dell'azienda ha le sue conoscenze e/o capacità, questo crea un'enorme responsabilità: cosa succede se quella persona viene investita da un autobus e muore (da cui il termine “fattore autobus”) o semplicemente sceglie di lasciare l'azienda per una nuova sfida? Ora la vostra azienda è bloccata in una situazione terribile perché nessuno può sostituire immediatamente l'indispensabile dipendente e voi non avevate alcun controllo sui tempi!

Per evitare questa situazione, l'azienda ha due opzioni. O si può tentare di diffondere le conoscenze e/o di aumentare le capacità dei collaboratori dell'indispensabile, oppure si può tentare di togliere il cerotto in un colpo solo licenziando l'indispensabile in un momento in cui si sceglie e si recupera dalla perdita di tale lavoratore quando è pronto per quel processo.

Poiché non è sempre pratico colmare un grande vuoto di conoscenze e soprattutto di capacità, licenziarli può essere la scelta più logica.

In qualità di dipendente, si dovrebbe sempre tentare di impedire di diventare indispensabile. Condividete le vostre conoscenze con i vostri colleghi e fate in modo che ci siano persone in grado di svolgere il vostro lavoro quando non siete presenti. Assicuratevi che le vostre pratiche siano adatte ai lavoratori con il livello medio di competenza della vostra azienda. Se ritenete che il livello medio sia troppo basso, lavorate con il management per cercare di aumentare tale livello. Assicuratevi che tutto ciò che create sia ben documentato e che tale documentazione sia di uno standard sufficientemente elevato da poter essere utilizzata da qualsiasi vostro collega per continuare il vostro lavoro.

Se l'unica cosa in comune tra le tre situazioni sei tu, allora devi considerare che qualcosa che stai facendo è un problema.

Hai parlato con i tuoi ex collaboratori e hai chiesto loro di criticarti? Non il tuo codice, ma il tuo comportamento in ufficio. Il modo in cui comunichi con i tuoi colleghi, il modo in cui comunichi con il tuo capo, il modo in cui ti occupi della documentazione, il modo in cui ti comporti durante le riunioni, ecc.

Ti sei messo nella posizione del tuo supervisore? Hai davvero pensato a cosa devono fare, quali sono le loro responsabilità, cosa li fa sentire bene quando spengono la luce dell'ufficio e vanno a casa? Ci sono molti, molti esempi in cui qualcuno scrive un codice sorprendente dal punto di vista di altri ingegneri del software, ma l'azienda fallisce.

Ho guardato il tuo profilo, dice “il tuo codice dovrebbe essere più pulito di te”. Anche dai tuoi commenti che “hai passato molto tempo a spiegare i concetti”, e “criticare fa parte del mio lavoro di ingegnere”… Penso che tu sia desideroso di dare consigli e che i tuoi consigli non siano semplicemente apprezzati dai tuoi compagni di squadra.

Questo può essere dovuto a quello che dici, o al modo in cui lo dici, probabilmente ad entrambi.

Scrivere codice produttivo e manutenibile non ti causerà il licenziamento. Sarete licenziati se non andrete d'accordo con il team. Questo è un vostro problema, non (come lo immaginate) il vostro codice è troppo buono. Il vostro codice potrebbe essere davvero buono - ma è molto più probabile che questo sia un problema di scontro di personalità.

Il mio consiglio per voi, è di non essere la coda che cerca di scodinzolare il cane. Tieni la testa bassa, stop dicendo alla gente come codificare, segui la direzione, lavora bene con gli altri, scrivi codice manutenibile. E poi non verrai licenziato.

Noto con interesse anche questo commento eloquente del tuo manager:

“Ma è davvero buono come finge?”

Quello che ti dice è che il tuo manager non si fida di te, il tuo manager pensa che tu non sia autentico e che tu sia arrogante e/o che abbia una considerazione delle tue capacità superiore a quella che hai in realtà. Le relazioni dipendono dalla fiducia per sopravvivere. Prendete nota che il vostro problema non è un problema tecnico. Il suo problema ha ben poco a che fare con la qualità del suo codice. Quello che avete è un problema con il modo in cui vi relazionate con i vostri colleghi e con il vostro manager.

La gente non viene spesso licenziata perché è indispensabile perché la gente viene licenziata ); Questa è un'affermazione ridicola. L'articolo a cui si fa riferimento qualifica chiaramente che “licenziare” non significa necessariamente lasciarli andare, ma piuttosto renderli non indispensabili (spostandoli, costringendoli a non essere coinvolti in un particolare progetto, ecc.)

Anche se eccessivamente qualificati a volte non ti faranno assumere – inoltre raramente ti fanno licenziare. I buoni dipendenti sono molto difficili da trovare; nessuna azienda ragionevole se ne sbarazzerà perché sono troppo bravi (a meno che non lavoriate solo per un idiota - allora vi stanno facendo un favore).

Le persone vengono licenziate perché pensano di essere indispensabili e migliori dei loro colleghi e quindi si rifiutano di fare i cambiamenti che devono essere fatti all'uomo allo specchio per funzionare bene in una squadra. licenziati per cattivo atteggiamento )

Se stai costruendo un ponte con un gruppo di nativi e tiri fuori un portatile mentre gli altri stanno legando la corda - puoi essere più intelligente o più istruito ma sei diventato un danno per la squadra e il problema sei TU.

Se sei davvero grande come ti fai chiamare, saresti abbastanza intelligente da adattare le tue azioni per rendere il TEAM più produttivo possibile vs. spingere dogmaticamente la tua agenda (cosa che probabilmente stai facendo). Se lo facessi, probabilmente avresti un lavoro per un tempo molto lungo.

Come qualcuno che è regolarmente coinvolto nel processo di assunzione, prenderò qualcuno che è buono e piacevole rispetto a qualcuno che è grande e un potenziale cancro ogni giorno.

Ogni programma è una comunicazione con due pubblici: un compilatore o un interprete che lo farà eseguire, e alcuni umani che lo hanno letto e compreso. Si può comunicare molto bene con il compilatore, ma si può anche scrivere del codice scadente perché non può essere facilmente compreso dagli altri esseri umani coinvolti.

In genere, un team di programmazione ha un insieme di linguaggi, framework, tecniche ecc. che sono noti a tutti nel team. I nuovi assunti che mancano di alcuni di questi pezzi li assorbono rapidamente perché chiunque nel team può spiegarli.

L'uso di qualcosa al di fuori di questo set comporta un costo per il datore di lavoro. Per esempio, supponiamo che tu sia l'unico programmatore del gruppo che ha familiarità con il framework X, e che tutti gli altri abbiano familiarità con un vecchio framework Y che viene utilizzato per alcuni codici esistenti e che è buono quasi quanto X.

Usare il framework X sarebbe un errore, a meno che non sia talmente migliore di Y che la direzione concordi che i guadagni tecnici derivanti dal suo utilizzo sono sufficienti a giustificare lo sforzo di formazione per far conoscere X a tutti.

Una tecnica che potresti usare è quella di far revisionare il tuo codice da alcune delle persone meno esperte che devono essere in grado di leggerlo. Vedi cosa hanno da chiedere e considera come potresti riscrivere quei pezzi per essere più chiaro per loro. Più si considera la mancata comprensione del codice come un difetto del codice e non dei lettori, migliore sarà il feedback che si otterrà.

La mia interpretazione è che lei è stato destinato a questo trattamento fin dal primo giorno di lavoro. Lei ha detto di essere stato assunto perché ha delle competenze che nessun altro nell'organizzazione ha (TypeScript, Node). E ora che hai lavorato sodo per produrre una soluzione elegante, sapientemente elaborata e complessa tutto da solo, nessuno capisce quello che hai fatto, e quindi sei visto come una responsabilità da parte della direzione.

Se tutto questo è vero, non c'è davvero nessun altro modo in cui questo sarebbe potuto accadere.

A mio parere, il problema è strutturale, non personale, e quindi la colpa è della situazione e del processo, non della persona:

• L'organizzazione ha assunto una sola persona con un set di competenze completamente diverso da tutti gli altri, e ad un livello avanzato di tali competenze, per svolgere una funzione critica. Questo garantisce che, se si lavora bene, si sarà l'unico a comprendere il codice che è critico per la missione dell'organizzazione. (È del tutto irragionevole aspettarsi che una risorsa di livello senior produca codice che abbia immediatamente un senso per le persone che non conoscono il linguaggio utilizzato)
• L'organizzazione non vi ha sottoposto regolarmente al processo di revisione del codice. Se lo avessero fatto, il vostro codice sarebbe stato rifiutato fino a quando non lo avreste reso conforme ai loro standard di leggibilità. Dal momento che siete l'unico a contribuire al codice, con il vostro stile, e utilizzando un diverso stack tecnologico, è praticamente garantito che nel tempo il codice diventerà sempre meno comprensibile per gli altri. L'unico modo per evitare che ciò accada è quello di chiedere agli altri la revisione del codice al di fuori del processo, costantemente, traendo eventualmente l'accusa di sprecare il tempo degli altri. La mancanza di un processo di revisione del codice vi espone al fallimento.

Ho esperienze simili nel mio background. Una volta sono stato assunto per colmare un vuoto di competenze. Nessun altro nella società aveva una competenza di cui aveva improvvisamente bisogno. Ho fatto bene il mio lavoro e dopo qualche mese sono iniziati i conflitti. Ero l'unico che poteva lavorare con alcuni componenti della domanda. Diventai un collo di bottiglia man mano che si accumulava un lavoro che solo io potevo fare. Un giorno sono stato messo da parte perché l'azienda ha deciso di sostituire tutto ciò che avevo prodotto con un codice completamente nuovo, a modo suo. Il mio orgoglio è stato ferito in quel momento, ma in retrospettiva, è stata la decisione giusta per l'azienda. Dopo un po’ di tempo è arrivato il momento di andare avanti, e l'ho fatto.

Se ti suona familiare, forse è ora che tu vada avanti. Forse il management ti riassegnera’ a qualcos'altro se continuera’ ad apprezzare le tue capacita’. O se riesci a sopportarlo, forse puoi aiutare a riscrivere tutto quello che hai fatto nella pila degli standard tecnologici aziendali. Se questo non è possibile, andatevene. In entrambi i casi, il vostro codice è probabilmente in viaggio verso il bidone della spazzatura. Probabilmente è la cosa giusta da fare, se nessun altro lo capisce. E comunque è la naturale conseguenza delle loro scelte.

Assicuratevi che nel vostro prossimo lavoro, gli altri nel vostro team applichino fondamentalmente le vostre stesse competenze, e soprattutto che abbiano un processo di revisione del codice. Quando ti chiedono di cambiare il tuo codice in certi modi, fallo. Non considerate il codice consegnato finché non ha superato la revisione del codice e i vostri colleghi diranno al management (se richiesto), sì, il codice è buono. Allora non c'è nessun problema. Va benissimo fare domande su cose del genere in un'intervista tecnica; l'ho fatto molte volte. Speriamo che quest'altro sviluppatore che ha studiato il vostro codice vi dia una buona referenza.

Come nota a piè di pagina, se siete almeno in parte responsabili della vostra situazione di lavorare da soli, senza l'acquisto da parte di altri membri del team, allora anche voi meritate almeno una parte della responsabilità per il risultato. (Hai spinto per l'uso di TypeScript / Node quando altri volevano usare qualcos'altro? Avete usato la libreria o la tecnica più recente e più cool, anche se qualcosa di più basilare sarebbe andato bene? Mi sono sentito colpevole anche di questo una o due volte). Se è così, assicuratevi di prendere una lezione da questo risultato. Ma se non è così, portate questa esperienza nella vostra prossima posizione a testa alta.

La maggior parte delle risposte hanno trattato il tuo post dal punto di vista della leggibilità o meno del tuo codice o della sua qualità. Ma questa situazione può accadere e accade in tutti i campi della vita. Ho accettato un lavoro sulla Las Vegas Strip come commerciante e floorman. Le mie tecniche e la mia velocità erano così avanti rispetto al resto del loro personale che le persone incaricate di controllarmi non riuscivano a starmi dietro. In altre parole, non potevano seguire le mie decisioni. Poiché si trattava di grandi quantità di denaro in pochi minuti, spesso si sentivano confusi e mi denunciavano al loro superiore sostenendo che avevo commesso un errore. Rivendicavo sempre le mie azioni a quella persona, ma l'atteggiamento di diffidenza nei miei confronti si faceva più profondo.

Il mio ego e sospetto che il vostro non vedevano i segnali di avvertimento e anzi mi dilettavo nella mia superiorità, riversandola, per così dire, sulla mia superiorità. Sono stato licenziato e ho perso un'ottima posizione retributiva.

La lezione è semplice, bisogna scendere al livello degli altri. Se loro tirano fuori solo 15 mani all'ora e tu ne tiri fuori 100, non sei una fonte di lode. Si sta ispirando gelosia e persino odio. Se il vostro orgoglio non può fare questo, dovete trovare un altro modo per guadagnarvi da vivere, perché tutti i posti sono essenzialmente gli stessi. Le persone sono persone, non puoi cambiarle. Alla fine mi sono stabilito in altre linee di lavoro, dove anch'io ero mediocre e quindi non mi sono distinto. Spero che tu possa risolvere la situazione a tuo vantaggio.

Ho deciso di aggiornare il mio commento ad una risposta:

Documenta molto bene il tuo codice.

La corretta documentazione del codice trasforma le esperienze negative in cui un giovane diavolo sbatte la testa contro un muro incomprensibile per ore in potenziali esperienze di apprendimento.

È possibile che semplicemente non siate così bravi come pensate di essere, ma per amore di civiltà, presumo che sappiate scrivere la giusta quantità di codice complesso per ridurre di un ordine di grandezza la complessità e il tempo richiesto dall'intero codice. Il fatto che ciò sia possibile richiede la sorpresa di molti idioti. Lo trovano una proposta incredula, e l'unico modo per convincerli è mostrarglielo.

Ma questo richiede finezza, coraggio e autocontrollo. Bisogna concentrarsi su tre cose prima di tutte le altre: dimostrare di non essere una minaccia, far sembrare gli idioti intelligenti, e non lasciare mai che un solo idiota si renda conto di essere un idiota. Se non riuscirete a fare queste tre cose, fallirete e sarà colpa vostra. Il pragmatismo è un must, e non c'è spazio per l'orgoglio.

Anche se non posso raccomandare questo approccio a tutti, quello che ha sempre funzionato per me è di ignorare a volte quello che gli idioti ostili mi dicono di fare. Invece, trovo il modo di fare quello che voglio fare, produrre il miglior software per cui molti di loro abbiano mai visto il codice in un tempo molto breve, e lo presento in modo tale che i loro capi li ricompensino con un elogio luminoso. Anche se non hanno avuto alcun ruolo nella sua creazione. Anche quando si sono attivamente opposti.

È giusto? Non dovrei avere pieno merito per il mio lavoro? Dovrei davvero dover ballare intorno ai sentimenti di tutti? Irrilevante. Questa è la realtà. Se non mi adeguo ad essa, allora sono io l'idiota.

Ci sono molte molte persone intelligenti che pensano che gli sviluppatori altamente qualificati siano irreprensibili ed è per questo che tu do li vuoi. Ma avete visto le altre risposte alla vostra domanda - la maggior parte dei manager non vuole affrontare i problemi di un team con livelli di abilità molto diversi, e non ha la possibilità di andare puramente ad alta abilità. Neanche loro hanno necessariamente torto, i problemi sono reali, e i benefici di un codice di alta qualità che va oltre le capacità della maggior parte delle persone che sono in grado di assumere sono molto minori.

Se siete anche solo all'incirca così bravi come dite di essere, allora non siete all'altezza del vostro lavoro. Sembra che dovreste sforzarvi di lavorare in un posto dove potete imparare dai vostri colleghi e i vostri colleghi possono capire il vostro codice.

Se avete perso qualche lavoro a causa di questo, allora farete una brutta figura con le Risorse Umane, i reclutatori e i manager. Speriamo che possiate fare rete in un lavoro incontrando sviluppatori di livello simile che possano garantire che il problema è che il vostro livello di competenza è troppo alto.

Infine, devo aggiungere che dovreste fare del vostro meglio per valutare onestamente se il vostro livello di competenza è davvero così alto. Sembra che ci siano prove che lo siano, ma la maggior parte delle persone crede che siano migliori di quello che sono. Anche molti sviluppatori passano attraverso una fase in cui diventano molto bravi in un approccio, ma non sempre riescono a mettere tutto insieme in una soluzione ottimale a livello globale, e mancano ancora di flessibilità. Per esempio, a volte potrebbe essere meglio scegliere una soluzione inferiore che si sa che le persone che si hanno possono mantenere, se si sa che non possono mantenerne una più sofisticata, e non è probabile che assumano qualcun altro che possa farlo.

Per affrontare la domanda in modo specifico,

Come posso evitare questo in futuro?

• Trova un capitolo locale di Toastmasters, partecipa attivamente e guadagnati i risultati. Qualcosa che sembra così ovvio come feedback, si spera che venga apprezzato e affinato in una delle vostre più preziose competenze.

• Esercitatevi ad essere lo studente invece che l'esperto. Hai visto questo discorso di Jon Skeet sulle basi ? Riuscite a immaginare quanta più comprensione si possa ottenere se tutti noi facessimo una documentazione come questa, andrebbe a beneficio di tutti, a tutti i livelli di una squadra!

• Una squadra non è una sola persona. Il vostro team crescerà e migliorerà collettivamente. Dovete aiutare. Non è una squadra se ogni membro è una cellula che va in direzioni diverse (ad esempio, tu più in alto, e il membro più recente stagnante). Le riunioni di 2 ore sono un buon inizio. Aggiungerei anche la rotazione delle coppie di N giorni. Questo è 1:1 volta che tu regali ai tuoi compagni di squadra ** E** loro regali a te. Nel tuo caso, inclinati verso il ruolo di navigatore e lascia guidare il tuo compagno. Esercitatevi a non scrivere il codice, per quanto possa sembrare strano.

• Volontario in un Meetup locale e Hack-a-thons. Può costringervi a distillare il vostro codice perché lo scopo è quello di collaborare, e non di costruire una rete elettrica a tolleranza di guasti, giusto?

• In ognuno di questi esercizi, provate questo concetto: leadership servendo. Come potete fare un compito o realizzare qualcosa per aiutare i bisogni di un altro membro del team?

• Come sottolineato, contribuite ai progetti open source per ottenere più punti di vista sul vostro codice. Possono confermare che siete brillanti, ma anche rafforzare i suggerimenti che state ascoltando dal vostro attuale capo. Nella migliore delle ipotesi, qualche recensione vi darà una nuova idea.

• Trovate un ingegnere che sia migliore di voi. Non è migliorare se stessi per essere il più intelligente della stanza. C'è una citazione (il mio googling è diviso tra Olgivy/Ford/Sorkin) che recita: “Non puoi imparare di più se ti circondi di cattivo talento”.

Presumo che la sua descrizione della situazione sia come dice lei. Non posso dire di aver avuto esattamente questa esperienza, ma ci sono aspetti che mi sono familiari.

Lei dice che questa è una “grande” azienda. Non so come sia in Francia, ma spesso le aziende più grandi non apprezzano le competenze degli sviluppatori interni, soprattutto se non sono aziende tecnologiche. Lo attribuisco soprattutto al fatto che i manager di tali aziende spesso non provengono da background tecnici o si sono allontanati dallo sviluppo perché non sono mai stati così bravi.

C'è anche un aspetto storico dei venditori che vendono strumenti che dovrebbero eliminare la necessità di sviluppatori di talento. Anche se il vostro team non utilizza una di queste cose orribili, c'è la possibilità che il management dell'azienda sia stato indottrinato in una nozione anti-intellettuale dei team di sviluppo. In realtà un manager mi ha detto in faccia che sono stato abbastanza intelligente da costruire una determinata soluzione, ma poi nessun altro sarebbe stato in grado di mantenerla, quindi abbiamo dovuto comprare qualcosa (shelfware.) Quindi credo che questo possa accadere.

Potresti aver bisogno di cercare un altro tipo di azienda. Una che valorizzi gli sviluppatori altamente qualificati. Potresti dover fare i conti con il fatto di non essere lo sviluppatore migliore. Se fossi un aspirante chef, probabilmente non saresti felice di lavorare da McDonald’s. Non hanno bisogno di chef. Hanno bisogno di persone che seguano una ricetta. Potresti essere materiale da chef e questa azienda (e altre come lei) è McDonald’s. La domanda che dovete porvi è perché non l'avete ancora fatto.

Come posso evitarlo in futuro?

Non lavorare con nessuno a meno che non si abbia la ragionevole certezza che il loro standard di codifica corrisponda al tuo. Il che significa rifiutare qualsiasi lavoro se nessuno dei seguenti candidati si candidano:

• Ti fanno domande di programmazione durante il loro processo di intervista
• Hanno esercizi di programmazione tra pari
• Chiedono un campione di codice e sono d'accordo
• Puoi vedere alcuni dei codici che hanno prodotto

Come posso evitare questo nel presente?

Questo è stato coperto da altre risposte.

Se sei proprio così bravo, raggiungi il loro livello e lentamente insegna loro ad essere programmatori migliori. La prima volta che ho dovuto gestire uno stagista ho quasi cancellato l'intero codice da lui prodotto. Ero letteralmente furioso quando ho visto quello che è stato commesso (per fortuna non avevo testimoni :P ).

Devi incoraggiare la programmazione tra pari, la revisione del codice. Sedersi con un altro programmatore e cercare di codificare insieme per 2 o 3 ore. Abbandonate i concetti che possono essere troppo difficili da spiegare (nuove funzionalità avanzate di Java 8 per esempio), e spiegate quelli più facili (eredità).

A volte, quando si parla con gli altri, bisogna “ammutolirlo” per non offendere le persone. Soprattutto se si è ben al di sopra degli altri con cui si lavora, è probabile che si offendano quando si parla di consigli e fatti che probabilmente dovrebbero sapere, ma che non hanno fatto.

Direi di commentare il tuo lavoro molto bene, in modo che le persone che lo controllano possano capirlo. Potresti anche aver bisogno di “giustificare” il motivo per cui scegli quel metodo di codifica rispetto a un altro all'interno dei tuoi commenti. Potresti essere il miglior codificatore, ma se sei all'interno di un team, devi lavorare come un team.

Se lavorare come un team significa lavorare con una mano dietro la schiena, (con questo intendo seguire le loro preferenze di codifica), allora fallo. Almeno così possono leggerlo, capirlo, e la squadra stessa sta meglio (anche se questo significa che stai urlando dentro di te).

Quasi ovunque tu vada dove fai parte di una squadra avrai delle linee guida su come vogliono che le cose siano codificate - e tu devi seguire queste linee guida.

Non possiamo dipendere da lui in un

a lungo termine Questo è il problema principale. Non vogliono dipendere da te, ma sei stato assunto perché in realtà dipendono da te.

Puoi tranquillizzare la direzione con:

• Non stai pensando di andare altrove comunque, in modo che possano contare su di te a lungo termine.

Penso di essere messo alla prova da problemi che mantengono le mie competenze utilizzate, quindi penso di aver finalmente trovato un posto di lavoro di cui posso godere per lungo tempo

• Sei disposto a fornire formazione ad altri membri del team per dare ulteriore valore al team.

Ho notato che il codice altrui non è veramente aggiornato con le tecniche di sviluppo software all'avanguardia, non è un problema, posso smettere di usare quelle tecniche del tutto, tuttavia sarebbe utile se tutti iniziassero ad usare quelle tecniche gradualmente per migliorare le prestazioni del team. Posso aiutarti in questo.

• Ti è stato chiesto di implementare le funzionalità XY, avendo le funzionalità spedite entro il tempo richiesto dalla tua abilità, le cose avrebbero potuto essere fatte in modi diversi ma in molto più tempo e con il rischio di bug aggiuntivi.

Posso avere un po’ di tempo in più per finire le prossime funzionalità? Ho davvero lavorato sodo per fare le cose correttamente, ci sono riuscito, ma temo che non tutti possano capirlo, invece voglio prendermi un po’ di tempo per rendere le cose comprensibili agli altri.

Sii onesto, se qualche affermazione non si applica (non lo faccio ora su quello che hai lavorato), non mentire, mai.

Se hanno intenzione di licenziarti, allora non sono davvero dipendenti da te per davvero. In ogni caso, almeno 2 persone nel team capiscono il tuo lavoro: Tu e il tuo collega. E ci sono buone probabilità che in futuro lo capiscano anche altre persone. Fondamentalmente non siete un collo di bottiglia nel vostro team, ma temono che possiate diventarlo in seguito. Dovrebbero comunque investire un po’ di tempo nella formazione.

Leggi * Il carro, il merlo e la Saab **. Dovrebbe essere in risonanza con te._

Ho avuto problemi simili in passato; ho imparato alcune cose su come affrontare la situazione, ma entrambi abbiamo usato mop e secchio per cercare di pulire l'uscita di una manichetta antincendio.

Non sono qui per suggerirti di meritare una diagnosi di salute mentale DSM-V, ma ti suggerisco che potresti essere ben consigliato di trovare un buon consigliere e lavorare su comportamenti non minacciosi e abilità sociali. Potresti anche leggere * Teoria delle menti aliene **.