Cosa fare con gli sviluppatori famosi che non documentano il loro lavoro?[Chiuso]

https://stackoverflow.com/questions/532338

collaboration

22-08-2019
|

Domanda

C'è un collega che sa seriamente il fatto suo, è una delle persone più brillanti con cui abbia mai lavorato, ma lui:

lavora nella sua piccola area della sua home directory piuttosto che in quella comune CVS deposito
no documento il suo codice
no commento il suo codice, ad es.3.500 SLOC di C senza commenti e senza righe vuote per interrompere le cose
spesso complica eccessivamente le cose, ad es.utilizza tre script di shell che si chiamano a vicenda per svolgere il lavoro che un semplice script di shell potrebbe svolgere.

Forse questa è una di quelle persone che pensano "se sono l'unica persona a saperlo, non potranno liberarsi di me"?

Qualche suggerimento su cosa fare?

A proposito, la direzione conosce la situazione e sta cercando di cambiare le cose.

Soluzione

Secondo me qualcuno a fare cose stupide come avete descritto in precedenza non può essere uno sviluppatore di stelle! A me sembra che lui fa intenzionalmente le cose più complicate come sono, in modo che nessun altro che se stesso in grado di mantenere il codice. Ciò si rende ancora più importante di quello che è in realtà! Parlate con lui. Egli deve cambiare! Se non lo fa, sostituirlo con una vera star-sviluppatore!

Vi prometto, in anche un anno e mezzo che non sapere come funziona il proprio codice! licenziarlo e si può risparmiare un sacco di tempo e denaro.

Altri suggerimenti

La parte CVS è facile - un guasto del disco rigido "accidentale" gli insegnerà una lezione per una vita (assicuratevi di avere una copia di backup anche se così non sarà effettivamente perdere codice)

Che suona come una situazione difficile.

Personalmente, vorrei lasciarlo andare. Egli può essere uno sviluppatore di stelle, ma non è un giocatore di squadra. E avete bisogno di avere una squadra coesa che può lavorare insieme, se si vuole fare un buon prodotto.

In mancanza di documento è un modo (molto male) per garantire la sicurezza del lavoro.

Si possono fare diverse cose per contrastare questo:

aggiungere documentazione come requisito per le valutazioni delle performance personale.
non accetta un software che non è documentato.
una parola con lo sviluppatore e scoprire il motivo per cui non documenta.
Compra uno strumento di documentazione fredda.

Gioca poliziotto cattivo / poliziotto buono schizzo avete visto dai film. Lasciate che la gestione sia il poliziotto cattivo e tu essere il poliziotto buono. Lasciate che il managament chiedere documentazione over-kill e per-minuto backup ZIP del suo lavoro. Ma tu gli offri documentazione moderata (da doxygen per esempio) e il controllo fonte consueta check-ins ...

Parlate con lui?

Se è veramente un "developer stella" che sarà lui a prendere atto di quello che dici.

Non gli può cambiare durante la notte, ma potrebbe essere che lui è solo completamente ignaro che le altre persone non ottengono abbastanza come fa lui.

Modifica:

E 'probabilmente un po' tardi per cambiare la società, ma sono necessarie maggiori informazioni a lavorare per trovare una soluzione. E 'impossibile per chiunque qui per suggerire in realtà lasciare che il ragazzo andare da solo in base a questi punti. Se hai raccontato il ragazzo ogni giorno per l'ultimo anno che ha bisogno di cambiare o che sia fuori di qui, allora si può lasciarlo andare. Tuttavia, non vedo alcuna prova di questo.

Uno sviluppatore brillante può essere insegnato a usare controllo del codice sorgente, commento e documenti. Se si spende lo sforzo qui allora si avrà veramente uno sviluppatore stella.

Si potrebbe essere concentrandosi sulla zona sbagliata qui, vi viene fornito l'opportunità di vedere alcuni punti deboli nel vostro processo.

lavora nel suo piccolo spazio della sua home directory, piuttosto che nel repository CVS comuni

Una semplice chat sarà probabilmente sufficiente qui, i benefici del controllo di versione parlano da sole e tutte le persone "brillante" sarebbe probabilmente essere entusiasta di quei benefici. Tuttavia può anche essere una buona occasione per guardare in sistemi di controllo versione alternativi che consentono una maggiore facilità d'uso e flessibilità (dare un'occhiata a bzr e git). Meglio ancora, coinvolgerlo nel processo di selezione, se è veramente una "stella" che probabilmente hanno una buona ingresso ed essere più acquisito nel suo utilizzo.

non documentare il suo codice

Non suona come la documentazione è parte del processo. La gente sta andando a resistere dover fare lavoro extra e se non v'è un processo definito allora si sta parlando di un sacco di lavoro extra. La documentazione è davvero necessario? Se è così, c'è un processo definito per la creazione di esso? si dovrebbe avere qualcuno interamente dedicato ad esso? In caso di almeno avere uno strumento per facilitare (forse qualcosa di semplice come MediaWiki)?

non commenta il suo codice, per esempio 3.500 SLOC di C con commenti e le righe vuote a becco cose

Tre parole: peer review del codice. Al di fuori di evidenti benefici di errore-catching, anche questo può fornire una certa pressione dei pari, che è una forza forte e può essere una buona cosa. Volendo essere percepito bene dai vostri coetanei auto-genera proprietà e qualità.

spesso overcomplicates cose, per esempio utilizza tre script di shell che chiamano l'un l'altro a fare il lavoro che un semplice script di shell potrebbe fare.

Anche in questo caso, la revisione del codice dei pari. Lei ha accennato che la gestione conosce carenze di questo programmatore. Lo fa? E 'piuttosto difficile per le persone a cambiare e migliorare, se non riconoscono i problemi con il modo in cui stanno facendo le cose.

E, forse meglio di tutti, da venire con i piani per migliorare il vostro processo di sviluppo (che sarà probabilmente migliorare non solo la "stella", ma tutti gli altri del team) probabilmente si può guadagnare un po 'stelle d'oro per te dalla gestione.

Non sembra molto di un programmatore di stella per me. Tutti i buoni programmatori sanno che la formattazione del codice e l'utilizzo di materie controllo del codice sorgente. Sembra anche se fa buoni progressi da lui stesso, sta ostacolando il progresso degli altri membri del team, che potrebbero avere un effetto negativo netto sul lavoro sempre fatto. Parlate con lui, e se si rifiuta di cambiare le sue pratiche, lasciarlo andare.

Se è davvero così luminosa e non si può cambiare le sue vie, né si vuole perdere lui, ma si vuole ancora il codice per essere documentato e commentato allora il mio suggerimento sarebbe quello di lasciare che uno sviluppatore meno esperto fare il documentazione e commentando per lui. Personalmente se fossi uno sviluppatore stella mi sentirei prettiy sciocca se qualcun altro è stato fatto per commentare il mio codice e vorrei iniziare a farlo io stesso alla fine. Nel frattempo, mentre questo non accade lo sviluppatore meno esperto può imparare una cosa o due.

C'è di più a essere uno sviluppatore stella che essere solo un programmatore eccellente. Se lui non ha le competenze del team ed è volutamente ignorando norme squadra ha bisogno di essere portato fino a lui. Se rifiuta di aderire a loro dopo aver parlato con il management, forse lui non è la giusta misura per la vostra azienda.

Questa domanda mi rende nervoso, perché mentre la persona che stai descrivendo suona egregia, posso vedere un po 'di me in lui.

Credo di essere un buon giocatore di squadra, e ho la fortuna di essere in una squadra molto buona. Comunque, io faccio uso di metodi che i miei colleghi non capiscono, anche se ho cercato piuttosto difficile da spiegare. C'è solo un piuttosto ampio divario di esperienza, che non è la riflessione sul nessuno di noi.

La documentazione è un argomento molto vasto e difficile. Cerco di seguire il DRY (non ripetere se stessi) Maxim. La documentazione che è separato dal codice può ammontare a ripetere se stessi, quindi è suscettibile di uscire da data a meno che non si rallenta te giù per tenerlo aggiornato. Il mio approccio al solito è quello di toccare in su dopo.

Spesso il problema su cui sto lavorando è così difficile che io possa avanzare piano e documentare tutto quello che voglio, ma quando si tratta di codice che ho spesso scoprire che mi sbagliavo e ri-pensarlo. Così l'idea che è possibile documentare cose in anticipo, e basta seguire che, funziona solo per i problemi piuttosto semplice, mi sembra.

In ogni caso, penso che questa sia una domanda eccellente, e la risposta non è affatto semplice.

è il ragazzo davvero una rock star? Sul serio? Pensaci per un secondo. È lui intelligente, ma non fare le cose, o è intelligente e in grado di fare le cose?

Ci pensi davvero difficile.

Se è veramente una rock star, allora forse non si dovrebbe scherzare con lui. Sta producendo cose incredibilmente impressionante utilizzando il proprio processo. Solo perché c'è un modo diverso di fare le cose che funziona meglio per voi, non significa che sta per permettergli di produrre la sua opera migliore. Invece di cercare di convincerlo a piegare al vostro processo, che molto bene potrebbe uccidere tutta la sua magnificenza, si dovrebbe cercare di trovare un modo per accogliere il modo in cui lavora.

Se è veramente buono come dici tu, si dovrebbe non vi dispiace farlo. Se non vale la pena di farlo, allora non è davvero così bravo. In tal caso, non si dispone di una rock star, basta avere un programmatore mediocre che non piace giocare sia le regole. Quei ragazzi, si dovrebbe solo sbarazzarsi di. Una rock star temperamentale è di solito vale la pena, anche se, a causa della qualità di ciò che lui o lei può produrre. Quelle persone, si dovrebbe andare di tutto per mantenere.

Suona come un programmatore stella che ha annoiato del suo lavoro ed è finita complicare le cose per renderlo più di una sfida. Che sarà lui a trovare qualcosa di meglio molto presto.

Il tentativo di cambiare le cose? Cosa preferisci, un pezzo scarsamente documentato lavoro del software o di una giunca ben documentato? Alcune persone sono in grado di software di scrittura che richiede poco a commenti, che non è un indicatore affidabile della qualità.

Ho paura che stai andando a perdere un buon sviluppatore.

"Hi Star Developer,

solo un po 'informale heads-up per dirvi che dalla prossima settimana, saremo Richiederemo la documentazione di codice, e disponibile commentando nel codice - che sta per essere politica aziendale, e non ci sarà nessuna eccezione "

Da allora in poi, basta fare con quel fallimento lo stesso come si farebbe fare con una mancanza di alzare in tempo, un fallimento per fermare perdita di tempo durante il lavoro, ecc Linea di fondo è se il capo dice il documento, di documentare o non stai facendo il tuo lavoro correttamente.

Se si sta lavorando in questo modo, non è uno sviluppatore stella - grandi sviluppatori software capire che la manutenibilità è estremamente importante. Si dovrà probabilmente pagare a caro prezzo per questo a lungo andare, sarei molto diretto con lui di quanto sia grave questo è e lasciato andare se non può iniziare a registrare. Ho visto questo molte volte prima ed è una bomba a orologeria.

Per essere onesto, ho visto un sacco di sviluppatori come questo e, a meno che non sono solo fuori dalla scuola, che non cambierà. Dico taglio la lossless ora, la sua unica intenzione di ottenere di più per licenziarlo mentre continua a vomitare il codice di più impossibile da mantenere:)

E 'molto improbabile che la gestione sarà sbarazzarsi di lui, se lui è davvero brillante.

L'intero progetto può essere chiuso, ovviamente, ma non ci sarà alcuna utilità nel CVS e la documentazione poi, in ogni caso.

Nessuna gestione sparerà un buon programmatore solo per assumere uno cattivo.

Gli dica che aiuterà gli per sbarazzarsi di gestione ogni volta che vuole.

Che cosa è che vuole cambiare lavoro? Si può dire la gestione: "OK, la gente, tutto è proprio come mi hai chiesto:. Controllato, documentato e sotto di controllare ho fatto con la mia parte, imballo e lasciare".

Può il team di avere successo con fuori lui? Se è così spingere il problema e si rifiutano di accettare qualsiasi codice che non è adeguatamente documentata o non soddisfa altri standard. Speriamo che questo ottenere il punto attraverso, ma potrebbe essere solo farlo arrabbiare e indurlo a smettere. Se la squadra non può avere successo con fuori lui allora siete fuori di fortuna fino a quando si può formare un sostituto fino al suo livello di abilità che non può essere la pena il tempo e lo sforzo.

+1 a ocdecio: se è uno sviluppatore di punta, il suo codice dovrebbe essere basato su un design di così alta qualità da documentarsi da solo.

Detto questo, la frustrazione potrebbe essere che, sebbene sia eccellente in aree tecnicamente impegnative che gli interessano, non si occupa della fornitura di funzionalità: solo tu saprai se questo è un problema per la tua organizzazione.

Avere un "guru" disponibile può essere un vero salvavita - o almeno lo era, o StackOverflow ha reso quel ruolo ridondante?

Non lasciate che il codice di essere rilasciato fino a quando non è passato la revisione del codice e solo permettergli di passare se ci sono abbastanza commenti e / o la documentazione per il codice che ha scritto per l'attuale funzione / progetto.

Modifica lo porta su nella sua valutazione. Documentazione / Codice commentando può essere dato a lui per le sue "aree di miglioramento".

: -)

Si potrebbe anche aggiungere controlli automatici di qualità che impedirebbero lo check-nel suo codice fino a quando fu sufficientemente documentata.

Questo è se lo si può convincere il check-in, in primo luogo! (Che è essenziale, IMO)

C'è un sacco di gente qui sui "commenti, e allora?" carrozzone qui. Codice letterato senza osservazioni è perfettamente possibile, ma solo perché qualcuno è intelligente e non commenta, non significa necessariamente che essi sono la scrittura di codice e scrivere.

Quindi cerchiamo di chiarire. È già detto che non documenta il suo codice a tutti, sia in commenti o documenti separati, e lui non utilizza alcun controllo del codice sorgente. Che ne dite di:

È il suo codice comprensibile, nonostante la mancanza di commenti?
Il team di utilizzare qualsiasi tipo di gestione dei problemi (ad esempio FogBugz, Bugzilla, ecc), che partecipa?
È il suo codice in prova?
C'è qualcun altro sulla squadra che in realtà è almeno un po 'a conoscenza di come il suo codice funziona?
È lui disposto ad almeno riconoscere che poteva stare a fare alcuni cambiamenti nel modo in cui lavora con il resto della squadra?

Se la risposta a tutte queste domande è "no", hai un grosso problema. Basta essere intelligenti non significa necessariamente fare qualcuno un bene. Avete qualche garanzia che non lascerà tuo domani società o essere colpito da un autobus? Come si sarebbe avvitato se quello che è successo? Vale la pena il rischio?

Credo che questo è abbastanza tipico in qualsiasi ambiente. Come si arriva qualcuno a fare ciò che si vuole? Questo è esattamente ciò che "Come trattare gli altri e farseli amici" è tutto. Dale Carnegie non era di manipolazione, ma la gestione delle persone.

Sembra a me come se fosse appena inesperto e ha bisogno di una certa esperienza e di orientamento.

Pensi che è possibile sedersi e parlare con lui su questi temi? Dire a qualcuno che sta facendo qualcosa di sbagliato spesso sembra la cosa sbagliata da fare (soprattutto nelle società occidentali di oggi, dove non vogliamo ferire i sentimenti di altre persone), ma penso che si può andare molto lontano dalla calma e onestamente spiegare i problemi e li parlando attraverso. Aiuta se la persona che si e il vostro parere, che è tutto un altro problema ed è parlato nel libro di cui sopra rispetta. Assicurarsi capisce che si tratta di problemi seri. Inoltre, che in tutti i processi di sviluppo futuri che ci si aspetta che fare queste cose troppo quindi è una buona idea per praticare loro ora.

Non credo che attendere la prossima revisione delle prestazioni è una buona idea. Accumulando un sacco di feedback negativo e la consegna tutto in una volta è solo una cattiva idea e mi piaceva quando che è stato fatto a me.

la documentazione del codice è sopravvalutato. formazione CVS è facile.

Una buona classe dovrebbe rivelare il suo scopo attraverso i suoi metodi e le proprietà.

documentare il modello all'esterno dell'applicazione è anche più facile a fluire e comprendere.

vorrei portare alla sua attenzione, se non si può ottenere risolto sembra che sarà di perdere uno sviluppatore stella.

Modifica: Oops - usato CSV invece di CVS, per molti importazioni e io uso svn eh

fargli usare strumenti automatizzati esecuzione-verifica. (Vedere la mia risposta a " Come porre domande a un obsructionist? ")
Se lui overcomplicates e non fa uso di SCC, è non un ottimo sviluppatore -. Queste cose sono parti importanti dell'ingegneria del software
Nel caso molto improbabile che abbia un po 'di brillantezza insostituibile in settori come algoritmi, lo assegna a lavorare in quella zona, ad esempio, gli algoritmi che definiscono, e ottenere un vero e proprio programmatore di fare la codifica.
Usa il codice analisi statica per comprendere e ripulire il suo codice.

Il pair programming. Trova coppia di Hima che "completo" lui per esigenze che hai appena elencato. Potrete risolvere un problema sarà controllo del codice sorgente, la documentazione, in discussione ogni sua azione, ecc È inoltre allena altro ragazzo utilizzando prima la forza ragazzo

Da ciò che si descrive, questo tizio è decisamente non uno sviluppatore stelle. La programmazione è uno sport di squadra, e chi non gioca bene con gli altri non aggiunge molto valore a un progetto.

Personalmente, non potrei ricordare codice che ho scritto 6 mesi o più anni fa, e molto molto valore la storia dei cambiamenti in una sorta di controllo del codice sorgente.

Se avete avuto le revisioni del codice regolari con questo ragazzo penso che si dovrebbe vedere che lui non è così stellare di uno sviluppatore come si pensa che sia.

Sono d'accordo con la maggior parte delle persone su questo thread. Un modo per metterlo sul punto caldo è quello di avere il codice della squadra recensioni.

Per la prima riunione di revisione del codice scegliere il codice da un membro del team che è aperto e accetterà le raccomandazioni. Lo sviluppatore "stella" avrà la possibilità di vedere come funziona il codice di revisione e quindi è possibile pianificare il suo codice da rivedere dopo. Dategli un po 'di tempo per preparare la prossima riunione e da allora dovrebbe essere almeno commentando il suo codice.

L'intenzione di revisioni del codice non è quello di mettere la vergogna sulla gente, ma piuttosto di individuare in modo collaborativo i problemi e luoghi di miglioramento, ma sarà un buon modo per mettere lo sviluppatore stella sul sedile caldo.

A mio parere, è necessario eliminare questo ragazzo. Sembra che il suo codice è illeggibile e lui non è sicuramente una squadra, né una cassaforte, lettore.

E 'anche una cattiva pratica di permettere a qualcuno di vedere se stessi come indispensabile. Se lo si lascia tenere questo, le sue pratiche otterrà peggio, non meglio. Quando se ne va, per ognuno fa, verrà lasciato con un enorme mal di testa di codice aggrovigliato. È necessario tagliare le perdite ora se non si forma in su.

Infine, mantenendo questo sviluppatore senza di lui che regna in due set un cattivo esempio da sviluppatori junior. Se si forza loro di funzionare correttamente, si rischia di risentimento dal "perché lui e non me" folla. Se non lo fai, si ottiene un po 'di hack che lavorano come la vostra "stella".

In breve, a meno che modella su molto, molto rapidamente, è il momento di abbandonare lui, per la salute e la sanità mentale di tutto il vostro staff di sviluppo.

Abbiamo avuto un problema simile quando ho iniziato il mio lavoro attuale poco più di 3 anni fa, il nostro sviluppatore capo era un cowboy. Era molto intelligente, ma molto irregolare, alcune delle sue cose era molto ben documentato, ma in modo troppo complicato era sovrapponibile a mantenere, o il codice prima e capire quello che stava costruendo in seguito, avrebbe gettato fuori il codice per vedere cosa sarebbe bastone.

Ha lasciato circa 2 1/2 anni fa, ed è ancora ci perseguita quando troviamo un po 'del suo vecchio codice, e nella sua difesa che è come il negozio di sviluppo qui è stato eseguito allora, negli ultimi 3 anni sono stato in una crociata per cambiare quella mentalità.

Quando si diventa uno sviluppatore stelle smette di essere così tanto su quanto bene si conosce il sistema, codice, quadro, architettura, ecc e di più su

Scrittura elegante, mantenibile,, codice leggibile flessibile
Lavorare con il resto della squadra:. Usando controllo del codice sorgente, guidare con l'esempio, etc
documentare ciò che ogni metodo, classe, oggetto, ecc sta facendo
La ricerca di nuovi e migliori modi di fare le cose per se stessi e il vostro team

se il vostro non aver seguito tutti e quattro di questi a un certo livello il vostro non è uno sviluppatore stella, tanto più se si rifiutano di provare / imparare ad usarli, allora è il momento che che dovrebbe trovare altre opportunità di lavoro in un modo o in un altro, sento morire di fame artista è popolare con questo tempo di persona (il tutto fraintendere genio)

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow