Programmatore Solo .NET che si trasferisce in un team [chiuso]

Sono stato un programmatore .NET solo per una piccola startup negli ultimi 8 anni. Ho messo insieme un software abbastanza decente, e ho sempre cercato di migliorare me stesso e conformarmi alle migliori pratiche, incluso il controllo del codice sorgente (SVN / TFS). Ho lavorato a stretto contatto con un team di ingegneri di altre discipline, ma quando si trattava del software ero l'unico programmatore. Amo l'arte della programmazione e amo imparare cose nuove per affinare i miei strumenti.

Tra 2 settimane inizierò un nuovo lavoro in un team di 20 sviluppatori .NET. La mia posizione sarà di livello medio e lavorerò sotto alcuni programmatori con sfondi incredibilmente impressionanti. Ancora una volta, l'aspetto del team di sviluppo sarà nuovo per me, quindi sto cercando alcuni suggerimenti generali per "nuovi ragazzi" che mi aiuteranno a essere il più efficace e facile da andare d'accordo fin dall'inizio.

Tutto è permesso, compresi consigli di alto livello e piccole cose quotidiane sulla comunicazione.

Principalmente buon senso ma il mio consiglio sarebbe:

Trascorri la maggior parte della prima settimana con le persone piuttosto che con la tecnologia. Non perdere il primo giorno a personalizzare il tuo desktop o qualsiasi altra cosa che ti isolerà dal team. Conosci 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 annota le cose, chiedi ai colleghi di ripetere le descrizioni delle procedure per evitarle.

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

Dubito che il lato della programmazione sarà effettivamente un problema.

• Imparare! Incontrare nuovi programmatori è un ottimo modo per imparare nuovi trucchi. Guardandoli digitare imparerai alcuni trucchi dell'editor e guardare il loro codice ti darà 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 lo avrebbe risolto in un'ora.

• Le guerre di codice sono guerre di religione. La sintassi potrebbe essere un po 'diversa laggiù (aggiungi parentesi alle singole frasi?) Ma raramente vale la pena di litigare.

• Socializzare. Se stanno bevendo qualcosa ogni settimana, assicurati di unirti a loro. Questo può essere semplice come mangiare insieme .

Giocando con Devil's Advocate e sto per dire che i tuoi compagni di squadra sono competenti. Niente è peggio che lavorare in una squadra in cui nessuno tranne te fa qualcosa nel modo "corretto", perché sei sempre più numeroso delle persone che vogliono fare le cose nel modo sbagliato.

Citi di lavorare sotto sviluppatori con un background impressionante, quindi sembra promettente e in tal caso ti incoraggio a imparare ciò che puoi, ma non dimenticare mai ciò che già sai per amore della "mentalità da gregge". Se tutti gli altri fanno qualcosa di sbagliato e lo fai bene, non scendere a compromessi.

Oltre a Jonno, direi:

Preparati ai cambiamenti. Ogni squadra lavora in modo diverso. I buoni team SW hanno regole di codifica. Preparati ad accettarli, anche se inizialmente sembrano strani.

Preparati a molte più comunicazioni. Quando lavori da solo, nella tua testa ci sono molte informazioni dettagliate. Non appena lavori in gruppo, questi dettagli (almeno alcuni di essi) devono essere condivisi e comunicati e per questo è necessario del tempo.

Ascolta più di quanto parli.

Poni più domande di quante cerchi di rispondere (a meno che le domande non siano dirette a te). I "vecchi timer" del team sapranno quanti progressi stai facendo nell'apprendimento del codice dalle domande che poni. Probabilmente hanno un elenco mentale di domande che si aspettano.

Scrivi il tuo codice per abbinare lo stile prevalente. Questo vale per dove inserisci spazi, parentesi graffe, lettere maiuscole, lunghezza dei nomi delle variabili, dimensione media dei metodi, densità dei commenti e tutto il resto che non dovrebbe importare. Se hai davvero un buon motivo per fare le cose in modo diverso, chiedi a uno dei vecchi perché il team ha lo stile dato. Puoi imparare alcune cose interessanti sulla storia e sulle personalità del team. Il che mi porta al punto successivo.

Impara la tradizione della squadra. Molto probabilmente nessuna delle tradizioni è scritta da nessuna parte, ma è una conoscenza comune della squadra. La tradizione del team include la storia di come il progetto è arrivato allo stato attuale, gli errori commessi in passato, i successi fatti in passato, le lezioni apprese lungo il percorso. Viene indicato in brevi dichiarazioni come "sembra di nuovo il bug di Frobnitz". Quando vedi / senti i membri del team concordare con un commento enigmatico che qualcuno fa, probabilmente c'è la conoscenza del team coinvolto. Chiedi a qualcuno.

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

Poni domande e ascolta le risposte. Pensa alle risposte alle domande precedenti prima di porre quella successiva in modo da poter provare ad anticipare una risposta.

Sforzati di fare il miglior lavoro possibile. Abituati a chiederti cosa penseranno gli altri membri del team del tuo codice se devono modificarlo 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 per il problema. Assumersi la responsabilità di implementare una soluzione quando si evidenzia un problema.