Solo programmatore .NET trasferirsi in una squadra [chiuso]

Sinceramente, ma il mio consiglio sarebbe:

Spendi tanto della prima settimana con le persone piuttosto che con la tecnologia. Non sprecare il primo giorno personalizzando il tuo desktop o qualsiasi altra cosa che ti isolerà dal team. Scopri il maggior numero possibile di colleghi il più rapidamente possibile.

Cerca di capire chi sono i cavalli da lavoro e chi sono anche i barboni. Evita il più possibile i barboni, ogni squadra li ha e non vuoi essere classificato come uno.

Partecipa a qualsiasi evento sociale nelle prime settimane, anche se solo una birra dopo il lavoro o il pranzo.

Ascolta e scrivi le cose, chiedi ai colleghi di ripetere le descrizioni delle procedure li avverrà.

Spendi i primi 3-6 mesi per familiarizzare, a meno che non sia specificamente richiesto su un problema specifico, non raccomandare modifiche a procedure / architettura / ecc. Lavoreranno in modo diverso per te, e alcuni elementi potrebbero essere poveri, ma ci saranno delle ragioni e raramente sono dovuti a negligenza o ignoranza.

Dubito che il lato della programmazione sia effettivamente un problema.

• Per saperne! Incontrare nuovi programmatori è un ottimo modo per imparare nuovi trucchi. Guardandoli tipo imparerai alcuni trucchi editor e guardando il loro codice ti daranno nuove idee.

• Non disturbare i tuoi colleghi ogni cinque minuti, ma se sei davvero bloccato non esitare a chiedere aiuto. Troppi programmatori sono bloccati su un programma per due giorni in cui chiedere al tuo vicino di risolvere l'operazione in un'ora.

• Le guerre di codice sono guerre religiose. La sintassi potrebbe essere leggermente diversa da quella parte (si aggiungono parentesi alle istruzioni della linea singola?) Ma raramente vale la pena di litigare.

• Socializzare. Se fanno un drink ogni settimana, assicurati di unirti a loro. Questo può essere semplice come mangiare insieme .

Giocare a Devil's Advocate e dirò assicurarmi che i tuoi compagni di squadra siano competenti. Niente è peggio che lavorare in una squadra dove nessuno, tranne te, fa qualcosa in modo "corretto", perché sei sempre in minoranza in persone che vogliono fare cose sbagliate.

Hai menzionato il fatto di lavorare sotto sviluppatori con uno sfondo impressionante, quindi sembra promettente e in tal caso ti incoraggio ad imparare ciò che puoi, ma non dimenticare mai ciò che già conosci per il gusto della "mentalità della mandria". Se tutti gli altri fanno qualcosa di sbagliato e lo fai bene, non comprometterti.

Oltre a Jonno, direi:

Sii preparato per i cambiamenti. Ogni squadra lavora in modo diverso. I buoni team SW hanno regole di codifica. Siate pronti ad accettarli, anche se inizialmente sembrano strani.

Sii preparato per molte più comunicazioni. Quando lavori da solo, ti vengono in mente molte informazioni dettagliate. Non appena lavori in una squadra, questi dettagli (almeno alcuni di essi) devono essere condivisi e comunicati e il tempo necessario per questo.

Ascolta più di quanto parli.

Fai più domande di quelle che cerchi di rispondere (a meno che le domande non siano rivolte a te). I "vecchi temporizzatori" del team sapranno quanti progressi stai facendo nell'apprendimento del codice dalle domande che chiedi. Probabilmente hanno una lista mentale di domande che si aspettano.

Scrivi il tuo codice per adattarlo allo stile prevalente. Questo si applica a dove si inseriscono spazi, parentesi graffe, lettere maiuscole, lunghezza dei nomi delle variabili, dimensioni medie dei metodi, densità dei commenti e tutto ciò che non dovrebbe avere importanza. Se hai davvero un buon motivo per fare le cose in modo diverso, chiedi a uno dei veterani perché la squadra abbia lo stile dato. Potresti imparare alcune cose interessanti sulla storia e le personalità del team. Il che mi porta al prossimo punto.

Scopri la tradizione del team. Molto probabilmente nessuna delle informazioni è scritta da nessuna parte, ma è conoscenza comune della squadra. La tradizione del team include la storia di come il progetto è arrivato al suo stato attuale, gli errori commessi in passato, i successi fatti nel passato, le lezioni apprese lungo la strada. Si riferisce a brevi frasi come "sembra di nuovo il bug di frobnitz". Quando vedi / senti i membri del team concordare con un commento criptico che qualcuno fa, probabilmente c'è un problema di squadra. Chiedi a qualcuno.

Non criticare il codice finché non conosci le personalità e la storia coinvolte. Non sai chi potresti offendere.

Fai domande e ascolta le risposte. Pensa alle risposte alle domande precedenti prima di chiedere la prossima in modo da poter provare ad anticipare una risposta.

Cerca di fare il miglior lavoro possibile. Abituati a chiederti che cosa qualcun altro del team penserà del tuo codice se dovessero apportarvi una modifica il mese prossimo.

Se vedi un problema che deve essere risolto, fai del tuo meglio per avere una soluzione ragionevole pronta da offrire prima di esprimere preoccupazione riguardo al problema. Assumi la proprietà di implementare una soluzione quando fai notare un problema.