Gestire il mio collega antiquato

Sono un programmatore abbastanza giovane e lavoro in un reparto IT di un'azienda di medie dimensioni. Ho un collega ed è davvero un bravo programmatore di Visual Basic 6. E intendo davvero bene. Onestamente. È in grado di fornire applicazioni funzionanti, contenenti pochissimi bug, nel momento in cui devo prendere la mia prima tazza di caffè e avviare la macchina. È proprio così bravo.

Il fatto è che stiamo lavorando con una squadra e il suo stile di lavoro è completamente antiquato. Non crede nel software di versioning (se ti assicuri solo che il tuo codice sia corretto, non hai bisogno di tutte quelle sciocchezze). Non crede nella distribuzione (posso fornire un eseguibile funzionante. Il modo in cui viene distribuito è per i amministratori di sistema capire). Non crede nell'astrazione. ('se vuoi creare una subroutine, vai avanti, ma non chiamare alcuna subroutine da quella subroutine. Diventa così disordinato e il codice è difficile da seguire. In questo modo ognuno può seguire ogni passo lungo la strada. 'o' sì, certo che puoi usare quella libreria per farlo per te, ma in questo modo non capisci davvero cosa sta succedendo ') e certamente non credi in OOP. (lavoriamo in VB.net)

È così bravo in quello che fa, è in grado di fornire applicazioni molto più velocemente di me. Ma non funziona in una squadra. L'altro membro del nostro team è tranquillo e non gli piace parlare, anche se tende ad essere d'accordo. Il nostro manager pensa che valga punti validi, ma non è un programmatore.

Ho davvero difficoltà a mantenere i programmi che ha scritto, e non crea una buona atmosfera di squadra. Quale pensi sia la cosa migliore da fare per me?

Sembra uno di quelli "È un bravo ragazzo ma ..." dove sai che sta arrivando la verità. E la verità sembra che non sia proprio un bravo ingegnere. Un buon software non riguarda solo la velocità di lavoro e di sviluppo. Riguarda anche le altre cose che hai menzionato: manutenibilità, compatibilità, astrazione (per l'efficienza futura), ecc.

Quindi, detto questo, sembra che tu abbia uno sviluppatore di problemi tra le mani. La cosa peggiore per te è che ha dimostrato e probabilmente impostato a modo suo. Che cosa si può fare?

• Lavora intorno a lui.
• Sforzati di produrre i tuoi progetti seguendo un programma così stretto come lui.
• E se non puoi, produce un risultato migliore .
• Nel corso del tempo quei concetti comprovati che respinge inizieranno a ripagarti.

D'altra parte, se sei costretto a lavorare a modo suo, vattene.

Non provare a cambiare il tuo collega. Lo stai descrivendo come qualcuno in grado di fornire software funzionante. Probabilmente è troppo tardi per integrarlo nel team.

Quindi hai due scelte:

• Adattati . Forse con il tempo sarai in grado di convincerlo dell'utilità di un sistema di controllo del codice sorgente? Dovrai aumentare il tuo cerchio di influenza . Più è resistente al cambiamento, più tempo avrai bisogno.

• Rimuoviti dal team. Hai molti punti per giustificare questo. Forse dovresti lasciarlo mantenere le sue applicazioni da solo e dedicarti a nuove cose.

• Rimuoviti dal company. A volte, questa è l'unica soluzione.

Se fossi in te, installerei il mio sistema di controllo del codice proprio ora. Inizia a usarlo per tutto il codice e gestiscilo in modo che gli altri membri del tuo team dispongano di account e possano accedervi. Gli altri colleghi saranno probabilmente entusiasti di usarlo.

Il tuo collega che non crede in tali pratiche potrebbe non essere facile da convincere. Tuttavia, qualsiasi codice con cui sei costretto a lavorare che è stato scritto da lui dovrebbe passare al controllo della versione in modo da poter lavorare con esso. Quando ha bisogno di accedere alle tue modifiche, inviagli un semplice set di istruzioni passo per passo su come estrarre il tuo codice dal repository.

Non devi essere combattivo o andare al di sopra di lui per coinvolgerlo in processi più moderni. A volte basta andare per la propria strada ed essere un leader con l'azione è più efficace che cercare di convincere qualcuno con le parole. Piccoli passi. Se inizia a essere più sensibile al controllo della versione, inizia a refactoring delle subroutine e ad aggiungere test unitari per proteggersi dalle modifiche. Automatizza i test e mostragli come può accedere ai risultati non appena effettua il check-in.

Molte volte le persone sono solo resistenti perché non amano il cambiamento. Ma se i cambiamenti vengono presentati loro in modo graduale e in un modo che li rende facili da seguire, spesso vedranno i benefici molto rapidamente.

Soprattutto, rendilo tutto il più semplice possibile per lui (Keep It Simple Stupid). Consentigli di iniziare a seguire queste pratiche alle sue condizioni. Ma non lasciarti trascinare giù.

Sarò onesto, non stai dipingendo una sua bella foto. Metodi arcaici, software difficili da mantenere, testardi nei confronti di nuovi modi di lavorare, contro l'astrazione ecc. Ecc

Da quello che hai detto, se sta producendo software FASTER in gran parte privo di bug di quanto tu sia senza l'uso di librerie riutilizzabili e modelli di progettazione finalizzati allo sviluppo rapido di applicazioni, allora dice di più su di te, di lui ...

... riguardo a lui ... sì, trova un modo per NON lavorare con lui e NON essere associato al suo lavoro. Sembra che abbia un tipico atteggiamento egoistico nei confronti del suo lavoro. Non puoi lavorare con qualcuno del genere, puoi solo osservarli lavorare e riordinare dopo di loro (come sei attualmente).

Ho visto questo prima ,

E sono quasi disposto a scommettere: questo tipo di ragazzo appare solo "veloce" perché ha una serie di "schemi" provati e testati nella sua testa. Il 99% delle app Line of Business è CRUD , roba base.

Probabilmente usa un sacco di Copy & Paste dal suo codice esistente (niente di sbagliato in questo).

Ma..

Nel momento in cui incontra qualcosa di remotamente complesso, cade, perché? perché non si adatta più a nessuno dei "modelli" di base.

Una piccola sfida ...

Creerei un progetto sul lato, un progetto complesso che beneficia davvero di OOP e del riutilizzo del codice.

Quindi mostragli quel progetto e chiedigli di implementarlo per funzionalità.

Scommetterei quindi che il suo codice sarà quasi certamente 10 volte più grande e 10 volte più brutto se lo avesse implementato a modo suo.

Guarda questo dal punto di vista commerciale.

Ci vuole più tempo per produrre il codice buggier. Produci meno entrate quindi fai schifo.

Se, nel tempo, è possibile invertire questo, è possibile invertire questo.

Ma forse, solo forse, questo programmatore antiquato può davvero insegnarti un paio di cose sulla produzione di codice rapidamente che è così privo di bug? Forse le sue tecniche non sono così vecchie come pensi?

Trovo sospetto che qualcuno possa produrre un codice così grande senza alcune buone pratiche. Potresti essere in grado di apprendere quelle pratiche e applicarle alle "migliori pratiche" e alle cose di tendenza che capisci.

Se il tuo manager non è un programmatore, prova a metterlo in termini che capirà.

• Dovremmo usare sourecontrol perché in caso contrario potremmo avere grossi problemi nel recupero

• Mi ci vuole x quantità di tempo più lungo perché si rifiuta di seguire alcuni processi piuttosto di base.

D'altra parte, assicurati di non essere troppo preso dalla perfezione, cioè questa è una buona pratica che dobbiamo seguire. È probabile che il tuo collega abbia molto da aggiungere, potresti doverlo spingere lentamente nella giusta direzione.

Sembra che il tuo collega non si sia mai sviluppato in una squadra. Questo tipo di partner di guru solista non consente una buona dinamica di gruppo. Quindi parlane con il tuo superiore e prova a discutere di pro e contro con il tuo partner fevor. Se riesci a farlo nel modo migliore, ma se rifiuta, sali nel cahin del comando

Parla con il tuo manager, chiaro e semplice come hai fatto qui. C'è un potenziale qui per la crescita: se il tuo collega è bravo come dici tu, non dovrebbe prenderlo molto convincente per farlo iniziare a convertire usando il controllo del codice sorgente e .Net con i concetti OO corretti.

Parlerei con gli altri per avere un quadro più ampio di come le cose sembrano dove sei. Forse ci sono alcune separazioni lì in modo che il suo codice non debba mescolarsi troppo con gli altri in quanto esiste il potenziale per separarlo nella propria area per un modo in cui questo potrebbe essere gestito anche se questo è più per un livello superiore come un regista o CIO da realizzare piuttosto che uno sviluppatore.

Potresti voler parlare con lui per vedere che tipo di sistemi più grandi ha costruito in quanto ci sono alcuni grandi sistemi aziendali che tendono ad essere un sacco di blocchi in cui il codice degli spaghetti può entrare nella terra di "Oh, ecco perché OOP può essere buono! " anche se questo a volte porta il caso in cui si rivela abbastanza utile vedere come questa può essere una cosa utile da avere nella propria cassetta degli attrezzi.

L'apatia può essere un altro sospetto per vedere se è per questo che rifiuta alcune cose che riterrei quasi fondamentali in termini di come tendo a progettare il codice, ma forse ho avuto troppi aiuti di Kool.

Sfidalo (in senso buono) per dimostrarti il ​​contrario, mostragli il lato interessante degli strumenti e delle pratiche. Non proteggere.

Ad esempio, forse non crede nel controllo delle versioni come un aiuto, ma gli mostra come si ramificano / uniscono e come può lavorare su diverse funzionalità sperimentali senza bisogno di avere una massa di file.

Per quanto riguarda OOP, mostragli alcuni modelli di design interessanti / complessi, come il modello di comando, il modello di attività e come può fargli risparmiare tempo prezioso e tutto il tuo team.

Se non ti interessa minimamente ... potrebbe essere un caso perduto, ma poi di nuovo, hai gli strumenti per la tua squadra e puoi superarlo. Prova a utilizzare un software di repository che mostra / invia messaggi di commit che il tuo manager può vedere, che porterà trasparenza al tuo manager e lascerà il tuo collega fuori dalla scena (bitbucket.org ha repository privati ​​gratuiti con spazio illimitato, se usi mercurial).

Alla fine, non cercare di convincere con le parole ma con azioni inconfutabili, questo è il modo migliore per affrontare le persone testarde IMHO (la psicologia inversa a volte funziona anche, lol).

bene, le tecniche che menzioni sono ovviamente buone, ma devi anche chiederti se le stai spingendo come ideologia. Trovo che i programmatori più giovani tendano a essere un po 'evangelici su ciò che hanno raccolto al college. ricorda che queste tecniche sono buone a causa dei risultati: il controllo della versione consente lo sviluppo simultaneo, il tracciamento più chiaro di progettazione, sviluppo, test, fasi di correzione dei bug. se i tuoi progetti sono davvero a breve termine, molti di questi sono semplicemente inappropriati e finiranno per renderti meno agile. semplicemente non è il caso che la migliore pratica significhi usare ogni possibile migliore pratica. l'astrazione, ad esempio, può sicuramente essere più una responsabilità che un aiuto, almeno alcune volte. il controllo della versione ha più senso quando si hanno tempistiche di sviluppo estese, codice complesso, più programmatori: esiste una sorta di sinergia, che è difficile ottenere trazione con frammentarietà.

Penso che il punto di partenza sia tenere d'occhio il potenziale riutilizzo - man mano che i progetti passano, pensano ai punti in comune o quadri più generali. cercare di uscire di fronte ai progetti sarebbe una mossa potente e potrebbe farti lavorare con più tecnica ...

Dovresti chiedere al tuo supervisore di fare una presentazione per TUTTI i motivi per cui il software "versioning" è buono. Non individuare il tuo collega fuori.

Sono uno scettico del software di controllo del codice sorgente, perché vedo le persone abusarne continuamente - come un modo per evitare il lavoro.

I miei colleghi si fondono COSTANTEMENTE, calpestando costantemente le dita degli altri. Ma una buona lezione amichevole sui suoi benefici sarebbe una cosa piacevole e stimolerebbe le discussioni.