Come diventare un buon giocatore di squadra? [chiuso]

Ho programmato (ossessivamente) da quando avevo 12 anni. Sono abbastanza ben informato su tutto lo spettro dei linguaggi là fuori, dall'assemblaggio, al C ++, a Javascript, a Haskell, Lisp e Qi. Ma tutti i miei progetti sono stati fatti da solo.

Mi sono laureato in ingegneria chimica, non in ingegneria informatica o informatica, ma per la prima volta in autunno lavorerò su un grande progetto di programmazione con altre persone e non ho idea di come prepararmi. Ho usato Windows per tutta la mia vita, ma questo progetto sarà molto unix-y, quindi di recente ho acquistato un Mac nella speranza di familiarizzare con l'ambiente.

Ho avuto la fortuna di partecipare a un hackathon con alcuni amici l'anno scorso - entrambi i maggiori CS - e abbastanza eccitante, abbiamo vinto. Ma quando ho lavorato con loro mi sono reso conto che il loro flusso di lavoro era molto diverso dal mio. Hanno usato Git per il controllo della versione. Non l'avevo mai usato in quel momento, ma da allora ho imparato tutto ciò che posso al riguardo. Hanno anche usato molti framework e librerie. Ho dovuto imparare cosa fosse Rails da un giorno all'altro per l'hackathon (d'altra parte, non sapevano cosa fossero gli scopi o le chiusure lessicali). Tutto il nostro codice ha funzionato bene, ma non hanno capito il mio e io non ho capito il loro.

Sento riferimenti a cose che i veri programmatori fanno quotidianamente: unit test, revisioni del codice, ma ho solo il vago senso di cosa siano. Normalmente non ho molti bug nei miei piccoli progetti, quindi non ho mai avuto bisogno di un sistema di tracciamento dei bug o di test per loro.

E l'ultima cosa è che mi ci vuole molto tempo per capire il codice di altre persone. Le convenzioni di denominazione variabili (che variano con ogni nuova lingua) sono difficili (__mzkwpSomRidicAbbrev) e trovo difficile l'accoppiamento lento. Questo non vuol dire che non accoppi vagamente cose - penso di essere abbastanza bravo per il mio lavoro, ma quando scarico qualcosa come il kernel Linux o il codice sorgente di Chromium per guardarlo, passo ore a provare per capire come si collegano tutte queste directory e file dal nome strano. È un peccato di programmazione reinventare la ruota, ma spesso trovo che sia più veloce scrivere da solo la funzionalità piuttosto che passare ore a dissezionare alcune librerie.

Ovviamente, le persone che lo fanno per vivere non hanno questi problemi, e dovrò arrivare a quel punto da solo.

Domanda: quali sono alcuni passaggi che posso prendere per iniziare a "integrarmi" con tutti gli altri?

Grazie!

Penso che stai diventando un po 'ansioso ed entusiasta di lavorare per un gruppo.

Nessuno di noi ha imparato a lavorare in un gruppo o in gruppo dai libri o è stato dato qualche piccolo passo o "Guida ai manichini per lavorare in gruppo".

Impariamo solo a lavorare con i gruppi lavorando in gruppi.

Tutto ciò che hai sentito parlare di programmatori professionisti, andrà a posto gradualmente mentre lavori in gruppo. Imparerai tutti uno ad uno come il controllo delle versioni, i test delle unità ecc.

Per me, la linea di fondo è

Entra a far parte di una squadra.

Prenderò alcune delle tue frasi e farò un paio di punti generali:

(d'altra parte, non sapevano cosa fossero gli scopi o le chiusure lessicali). Tutto il nostro codice ha funzionato bene, ma non hanno capito il mio e io non ho capito il loro.

...

Sento riferimenti a cose che i veri programmatori fanno quotidianamente: unit test, revisioni del codice, ma ho solo il vago senso di cosa siano. Normalmente non ho molti bug nei miei piccoli progetti, quindi non ho mai avuto bisogno di un sistema di tracciamento dei bug o di test per loro.

...

Passo ore a cercare di capire come si collegano tutte queste directory e file dal nome strano ... Spesso trovo che sia più veloce scrivere da solo la funzionalità che passare ore a dissezionare alcune librerie.

Penso che la cosa più grande che dovrai imparare sia questa:

Per un determinato standard di capacità degli sviluppatori, un team di nsviluppatori fa meno del nvolte il lavoro che uno degli sviluppatori potrebbe fare da solo - ma fanno ancora più di quanto chiunque possa fare .

Il motivo è semplice: quando lavori con altre persone, devi dedicare un po 'del tuo tempo a scambiare informazioni con queste altre persone; mentre quando lavori da solo, lo scambio di informazioni avviene nella tua testa. Che naturalmente è più veloce.

L'altra cosa importante è:

Alcuni dei tuoi collaboratori saranno meno capaci di te, sicuramente in alcune abilità; alcuni saranno anche meno capaci di te in tutte le abilità

Con queste due idee in mente, tutto ciò che ho citato sopra ha senso. Molte persone non "ottengono" chiusure. I test e le revisioni del codice servono a garantire la qualità e ridurre il rischio quando il codice viene prodotto da un gruppo di persone con abilità miste . Il tracciamento dei bug è perché quando si producono sistemi sufficientemente grandi, i bug sono inevitabili. E le infinite biblioteche con le loro convenzioni sono perché senza convenzioni c'è semplicemente troppo codice per impararlo o scriverlo di nuovo ogni volta che ne hai bisogno.

Davvero, penso che l'unico modo per imparare a lavorare in gruppo sia effettivamente farlo; ma spero che quanto sopra ti aiuterà a prepararti mentalmente. In bocca al lupo!

Il modo più efficiente è quello di far parte di una squadra.

Entrare a far parte di un team può sembrare difficile, poiché ho capito che non fai ancora parte di un team, come molti studenti e molte persone il cui lavoro è lavorare con nessun altro sviluppatore in giro.

Ti consiglierei di prendere parte a un progetto open source molto attivo e che favorisce le comunicazioni frequenti sui moderni canali open-to-all (tracker di problemi, mailing list, wiki, ecc.). La comunicazione aperta è importante perché probabilmente inizierai osservando come interagiscono le altre persone, quindi evita i progetti che fanno affidamento sull'e-mail tra sviluppatori core o IRC non archiviati.

Preferisci un progetto che sembra accogliente, con diversi collaboratori abbastanza frequenti , piuttosto che un progetto con 1 persona che fa tutto. Inoltre, preferisci progetti in cui a chiunque è permesso di toccare tutto (piuttosto che ogni sviluppatore che ha la sua area delimitata), perché è più divertente e offre più opportunità di comunicazione.

Spina senza vergogna: sei il benvenuto qui !

Non ribadirò ciò che tutti gli altri hanno già detto sull'effetto "just do it", ma aggiungerò un ulteriore punto che non ho visto menzionato: un buon manager ti aiuterà davvero ad integrarti nel team.

Mentre potresti avere tutte le cose giuste su di te per la parte di programmazione del lavoro, potresti perdere alcune delle cose più interpersonali e relative allo sviluppo del software. Un buon manager ti guiderà nelle pratiche delle squadre (sia nelle competenze trasversali che in quelle difficili) per aiutarti a gelificare, e spera anche di dirti se hai fatto o fatto qualcosa che è in opposizione a tali pratiche; perché non puoi riparare qualcosa che non sai che è rotto.

Un altro consiglio che vorrei darti è che non ci sono due squadre uguali e che anche una squadra esistente cambierà quando una o più persone si uniranno a essa.

Una squadra nasce dall'interazione di individui che si conoscono e cercano di capire come lavorare insieme fino a quando non trovano un modo comune (vedi ad esempio le fasi di sviluppo del gruppo di Tuckman ).

Quindi il mio consiglio sarebbe di non cercare di trovare le risposte alle tue domande ora, ma di vedere cosa succede quando inizi davvero a lavorare nel nuovo team. Alcuni dei tuoi problemi potrebbero essere considerati non problematici dai tuoi colleghi, altri saranno considerati pertinenti e avrai la possibilità di discuterli insieme o persino promuovere la tua opinione sull'argomento. E infine, probabilmente ti occuperai anche di aspetti a cui non avevi pensato.

Concordo con ElYusubov sul fatto che hai bisogno di molta pazienza e dai a te stesso e ai nuovi colleghi un po 'di squadra per imparare a lavorare insieme fino a diventare una squadra. Se pratichi qualche sport di squadra, dovresti già averlo provato.

Un commento finale sul passare molto tempo a comprendere il codice di altre persone. Lavorare in gruppo significa che lavorerai sul codice di qualcun altro e altri sviluppatori lavoreranno sul tuo codice. A volte il codice è troppo complesso per essere riscritto da zero. Una soluzione tipica è chiedere allo sviluppatore originale di rivedere le modifiche, in modo da avere un po 'più di fiducia nel fatto che non si sta rompendo nulla nel loro codice.

Questo è stato per me un grande passo avanti nel passaggio da un programmatore solista a un programmatore di squadra: lavori su codice che capisci solo parzialmente e devi abituarti. Ciò comporta molta più comunicazione con i tuoi colleghi, molto rispetto (sì, hanno strane convenzioni di denominazione per le loro variabili, e quindi?) E fiducia reciproca (anche se hanno uno stile di codifica diverso, so che forniscono codice funzionante) .

Essere un buon membro del team significa comunicare senza paura, fidarsi dei tuoi college e superare gli ostacoli in un progetto come team edeliver project as a team.

Ci vuole tempo , richiede pazienza e richiede di imparare per sentirsi a proprio agio e sicuri come programmatore. È anche vero che NON tutti i programmatori sono buoni giocatori di squadra e i giocatori di squadra condividono il loro successo e imparano le lezioni dai fallimenti.

Sarebbe utile evidenziare alcuni personaggi di un buon membro del team .

a) Un buon membro del team è una persona che è orientata verso gli obiettivi invece che verso se stessi.

b) Qualità: pensare più al quadro generale piuttosto che all'autocompiacimento. Questo è il punto chiave. Tutte le altre qualità (come affidabilità, comunicazione costruttiva) ereditano da questa

c) Come migliorare: prova a qualificare il modo in cui hai interagito con la tua squadra durante il giorno, definisci i punti positivi e negativi, prestagli attenzione durante i prossimi incontri. Inoltre, prova a guardare le decisioni del team da molte angolazioni. Mettiti nei ruoli degli altri, pensa a come puoi influenzare il lavoro degli altri.

Innanzitutto, congratulazioni per essere il tipo di persona che sembra davvero apprezzare la programmazione. Tuttavia, la programmazione non è l'inizio e la fine della fornitura di sistemi utili. Avrai una sfida di fronte a te e dipenderà da te se torni a programmi di hobby o vai a una carriera in cui puoi fare ciò che ami e essere pagato per questo.

Sei svantaggiato dal fatto che non hai una formazione nella creazione di software. In quell'istruzione ci sono diverse cose insegnate (non solo come programmare) che per i laureati CS e gli sviluppatori di software esperti saranno una seconda natura. Non che si presenti spesso sul posto di lavoro (anche se una volta lo ha fatto per me), ma NP-hard è un esempio di un termine che potrebbero comprendere e che potresti non farlo. Probabilmente ti manca un background nella teoria formale dietro il calcolo, ma va bene, purché tu sia disposto a conoscerlo. Forse un master in CS nel tuo futuro? Sembra che alcuni dei tuoi codici possano essere idiomatici, nel senso che hai uno stile di programmazione che ti sembra chiaro, ma non ad altri. Presta attenzione alle revisioni del codice e sii disposto ad accettare le critiche e apprendere. Ci vorrà del lavoro e potresti sentirti frustrato,

Quello che stai cercando per te non ha prezzo. Sembri sinceramente goderti la programmazione. Penso che ti piaceranno anche gli altri aspetti dello sviluppo di sistemi, come progettazione, architettura, test, ottimizzazione, ecc. La programmazione è una parte del puzzle e dovrai imparare altre abilità per essere uno sviluppatore di software. Hackathon a parte, gran parte del business prevede la comunicazione, l'apprendimento reciproco, l'ascolto e la pianificazione. Ho lavorato con molte persone laureate in CS e mi è piaciuto lo sviluppo del software più che vendere automobili o dipingere case, ma non ne ho avuto un vero amore.