Come diventare un buon giocatore di squadra? [chiuso]

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 una squadra da un libro o ci è stato dato qualche piccolo passo o "Guida per ragazzi al lavoro in squadre".

Impariamo a lavorare CON i gruppi lavorando IN gruppi.

Tutto ciò che hai sentito sui programmatori professionisti, andrà a posto gradualmente mentre lavori in team. Ne scoprirai uno ad uno come il controllo della versione, il test delle unità, ecc.

Per me, la linea di fondo è

Diventa parte di un team.

Ho intenzione di scegliere alcune delle tue frasi e fare un paio di punti generali:

(on the other hand, they didn't know what lexical scoping or closures were). All of our code worked well, but they didn't understand mine, and I didn't understand theirs.

...

I hear references to things that real programmers do on a daily basis -- unit testing, code reviews, but I only have the vaguest sense of what these are. I normally don't have many bugs in my little projects, so I have never needed a bug tracking system or tests for them.

...

I spend hours trying to figure out how all of these oddly named directories and files connect ... I often find it's just quicker to write up the functionality myself than to spend hours dissecting some library.

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

Per un determinato standard di capacità di sviluppo, un team di n sviluppatori fa less di n volte il lavoro che uno degli sviluppatori potrebbe fare da solo - ma lo fanno ancora fare più di quanto chiunque potrebbe .

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

L'altra cosa importante è:

Alcuni dei tuoi colleghi saranno meno capaci di te, certamente in alcune abilità; alcuni saranno anche meno capaci di te in tutte abilità

Con queste due idee in mente, tutto ciò che ho citato sopra ha senso. Molte persone non chiedono 'chiudi'. Le verifiche 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à mista . Il bug tracking è perché quando produci sistemi sufficientemente grandi, i bug sono inevitabili. E le infinite librerie con le loro convenzioni sono perché senza convenzioni c'è solo troppo codice per apprenderlo o scriverlo di nuovo ogni volta che ne hai bisogno.

In realtà, penso che l'unico modo per imparare a lavorare in un team è farlo davvero; ma spero che quanto sopra ti aiuterà mentalmente a prepararti. Buona fortuna!

Il modo più efficace è diventare parte di una squadra.

Partecipare a un team può sembrare difficile, poiché capisco che non sei ancora parte di un team, come molti studenti e molte persone il cui compito è lavorare senza altri sviluppatori in giro.

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

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

Plug spudorato: sei molto benvenuto qui !

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

Sebbene tu possa avere tutte le informazioni giuste su di te per la parte di programmazione del lavoro, potresti perdere alcune delle cose più legate allo sviluppo di software e interpersonali. Un buon manager ti guiderà nelle pratiche dei team (sia in soft skill che in hard skills) per aiutarti a gelificare, e spero anche di dirti se hai fatto o fatto qualcosa che è in opposizione a quelle pratiche; perché non è possibile correggere qualcosa che non si sa è 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 conoscono ciascuno altro e cercare di capire come lavorare insieme fino a quando non trovano un modo comune (vedi ad esempio le fasi di sviluppo di gruppo di Tuckman ).

Quindi il mio consiglio è di non cercare di trovare risposte alle tue domande ora, ma per vedere cosa succede quando inizi effettivamente a lavorare nella nuova squadra. Alcuni dei tuoi problemi potrebbero essere considerati non problematici dai tuoi colleghi, alcuni altri saranno considerati rilevanti e tu avrai la possibilità di farlo discuterli insieme o addirittura promuovere la propria visione sull'argomento. E infine, probabilmente ti occuperai anche di aspetti a cui non avevi pensato.

Sono d'accordo con ElYusubov che hai bisogno di tanta pazienza e dai te stesso e i nuovi colleghi qualche squadra per imparare a lavorare insieme fino a quando non si diventa un gruppo. Se pratichi qualche sport di squadra dovresti averlo sperimentato già.

Un ultimo commento su come trascorrere molto tempo a capire il codice di altre persone. Lavorare in una squadra significa che lavorerai sul codice di qualcun altro e altro gli sviluppatori lavoreranno sul tuo codice. A volte il codice è troppo complesso da riscrivere da zero. Una soluzione tipica è chiedere l'originale sviluppatore per rivedere le modifiche, in modo da avere un po 'più di fiducia che non stai infrangendo nulla nel loro codice.

Questo è stato per me un grande passo nella transizione da un programmatore solista a un programmatore di squadra: lavori sul codice che solo parzialmente comprendi e devi abituarti ad esso. Questo implica molto più comunicazione con i tuoi colleghi, un sacco di rispetto (sì, hanno strane convenzioni di denominazione per le loro variabili, quindi cosa?) 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 colleghi e superare gli ostacoli in un progetto come squadra e deliver project as a team.

Ci vuole tempo , richiede paziente e richiede di imparare per sentirsi a proprio agio e sicuro come programmatore. È anche vero che NON ogni programmatore è un buon giocatore 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) Il buon membro del team è una persona orientata all'obiettivo anziché autonoma.

b) Qualità: pensa di più al quadro generale piuttosto che alla soddisfazione personale. Questo è il punto chiave. Tutte le altre qualità (come l'affidabilità, la comunicazione costruttiva) ereditano da questo

c) Come migliorare: Cerca di qualificare come hai interagito con il tuo team durante il giorno, definire i punti positivi e negativi, prestare attenzione a loro durante i prossimi incontri. Inoltre, prova a Guarda le decisioni del team da molti punti di vista. Mettiti nei ruoli dell'altro, pensa a come puoi influenzare il lavoro degli altri.

In primo luogo, congratulazioni per essere il tipo di persona che sembra davvero apprezzare la programmazione. Tuttavia, la programmazione non è l'inizio e la fine della distribuzione di sistemi utili. Avrai una sfida davanti a te e starà a te decidere se tornare ai programmi di hobby o intraprendere una carriera in cui puoi fare ciò che ami e pagarti.

Sei svantaggiato in quanto non hai una formazione in software di costruzione. In quell'educazione ci sono diverse cose insegnate (non solo come programmare) che per i laureati CS e gli sviluppatori di software esperti sarà una seconda natura. Non che si presenti spesso sul posto di lavoro (anche se lo è stato per me, una volta) ma NP-hard è un esempio di un termine che potrebbero capire e che potresti non avere. Probabilmente non hai alcun background nella teoria formale dietro il calcolo, ma va bene, a patto che tu sia disposto a scoprirlo. Forse un master in CS nel tuo futuro? Sembra che parte del tuo codice possa essere idiomatico, nel senso che hai uno stile di programmazione che ti sembra chiaro, ma non per gli altri. Presta attenzione alle revisioni del codice e sii disposto ad accettare le critiche e imparare. Questo sta andando a prendere il lavoro, e potresti sentirti frustrato, ma tienilo d'occhio.

Ciò che hai per te non ha prezzo. Sembri sinceramente divertirti con la programmazione. Penso che apprezzerai anche altri aspetti dei sistemi di sviluppo, come la progettazione, l'architettura, i test, l'ottimizzazione, ecc. La programmazione è una parte del puzzle e dovrai imparare altre abilità per diventare uno sviluppatore di software. Gli hacker a parte, gran parte del business coinvolge la comunicazione, l'apprendimento reciproco, l'ascolto e la pianificazione. Ho lavorato con molte persone che sono laureati CS e mi è piaciuto lo sviluppo di software più che vendere auto o dipingere case, ma non ne avevo un vero amore.