Perché la codifica collaborativa è l'ultimo trucco professionale

Fare i primi passi nella programmazione è come imparare una lingua straniera. All'inizio la sintassi non ha senso, il vocabolario non è familiare e tutto sembra e suona incomprensibile. Se sei come me quando ho iniziato, la fluidità sembra impossibile.

Prometto che non lo è. Quando ho iniziato a programmare, la curva di apprendimento mi ha colpito duramente. Ho passato dieci mesi a insegnarmi le basi mentre cercavo di allontanare i sentimenti di insicurezza che ora riconosco come sindrome dell'impostore. È stato solo quando ho iniziato a frequentare i meetup per principianti che mi sono reso conto di come la programmazione in modo collaborativo apra incredibili possibilità. Hai solo bisogno della giusta comunità di persone con cui esercitarti.

Per me, quella community era Founders and Coders, il bootcamp JavaScript gratuito che mi ha aiutato a cambiare la mia carriera dal copywriting al coding. Anche adesso, a meno di un anno dal completamento del corso, non riesco a credere di essere pagato per sviluppare software.

La codifica collaborativa consiste nell'affrontare i problemi e nel trovare soluzioni insieme. Comprende tecniche come la programmazione di coppia, che diverse aziende tecnologiche prendono abbastanza sul serio da esaminare durante i loro processi di intervista. Coltiva anche abilità utili che sono difficili da imparare se tutto ciò che stai facendo è programmare da solo a casa.

Che tu abbia appena iniziato nel settore tecnologico o che tu abbia diversi anni di esperienza alle spalle, la codifica collaborativa non smette mai di essere utile. In questo articolo, vedremo come queste competenze sempreverdi ti equipaggiano per una carriera lunga e di successo nello sviluppo di software.

Abbinamento perfetto

La mia prima esperienza di programmazione di coppia è stata durante un incontro per principianti chiamato Coding For Everyone. Ecco come funziona: le persone si accoppiano, spesso con persone che non hanno mai incontrato, per risolvere le sfide JavaScript insieme sullo stesso laptop. Una persona assume il ruolo di "navigatore" e propone il codice che ritiene debba essere scritto. L'altra persona, il "driver", scrive i propri suggerimenti sul laptop e fa domande ogni volta che qualcosa non è chiaro. Continui a farlo, scambiando frequentemente i ruoli, fino alla fine della sessione di due ore.

In teoria era semplice. In pratica non tanto.

Ho trovato piuttosto fastidioso avere qualcuno che non conoscevo guardando il mio schermo mentre scrivevo, ed ero riluttante a cedere il controllo quando era il momento di scambiare i ruoli. Ho trovato la navigazione ancora più complicata. Quando un'idea non può passare dalla tua testa al computer senza prima passare per le mani del tuo partner, ogni parola che dici conta. Richiedeva un grado di comunicazione da parte nostra a cui semplicemente non eravamo abituati, ed ero sicuro che entrambi avremmo imparato di più se ci fossimo separati per lavorare separatamente.

Fortunatamente, siamo rimasti con esso; Sono andato di nuovo al meetup la settimana successiva. Da allora ho trascorso centinaia di ore in coppia con dozzine di sviluppatori e ho imparato più di quanto pensassi inizialmente possibile.

La programmazione in coppia è un modo incredibilmente veloce per imparare. La magia del metodo, una volta superata l'imbarazzo iniziale, è che produce risultati immediati. Alcuni cicli di feedback, come le bolle nel mercato azionario, possono richiedere ore, giorni o addirittura mesi per produrre una correzione. La programmazione della coppia richiede minuti, se non secondi. Quando perdi un punto e virgola, due paia di occhi possono individuare l'errore più velocemente di uno. Hai bisogno di cercare in StackOverflow indizi su un messaggio di errore canaglia? Tu e il tuo partner potete leggere thread diversi, dimezzando il tempo necessario per trovare una risposta.

Per problemi ancora più complicati, la programmazione mob può essere un ulteriore passo avanti. Questo metodo richiede una sezione interfunzionale di un team per riunirsi attorno allo stesso schermo del computer e raccogliere soluzioni in tempo reale mentre una persona digita.

"Tutte le menti brillanti che lavorano sulla stessa cosa, allo stesso tempo, nello stesso spazio, sullo stesso computer."

— Woody Zuill, Allenatore Agile e Formatore di Programmazione Mob

Sebbene possa sembrare un modo inefficiente di lavorare, i sostenitori della programmazione mob come Woody Zuill affermano che può effettivamente risparmiare tempo eliminando la necessità di revisioni del codice individuale perché tutti rivedono il codice in tempo reale mentre viene scritto. Produttività a parte, penso che il mobbing sia un modo fantastico per imparare non solo il codice, ma anche come le altre persone affrontano i problemi. Se la programmazione in coppia raddoppia il numero di prospettive a cui sei esposto, la programmazione mob fornisce ancora più approfondimenti.

Questo non vuol dire che l'accoppiamento - o addirittura il mobbing - sia semplice. Qualcosa con cui ho lottato inizialmente è stato mettere da parte il mio ego per fare domande che pensavo potessero suonare stupide. In queste situazioni, è bene ricordare che il tuo partner potrebbe avere gli stessi pensieri, soprattutto se entrambi siete appena agli inizi.

Se ti ritrovi a fare coppia con qualcuno più anziano, magari al lavoro, non aver paura di prendere in considerazione il suo cervello e impressionarlo con la tua curiosità. Anche qualcuno che è solo un po' più avanti di te potrebbe pensare a cose che non verrebbero in mente a qualcuno più anziano. Alcuni dei miei programmatori di coppia preferiti hanno solo pochi mesi di esperienza in più di me, eppure sembrano sempre sapere esattamente quali errori sto per commettere e come guidarmi nella giusta direzione. Quando questi sviluppatori dicono che non esiste una domanda stupida, lo intendono davvero. I migliori programmatori di coppia parlano liberamente, senza la necessità di apparire fantastici o la paura di sembrare sciocchi.

La programmazione in coppia richiede pratica, ma vale la pena perfezionarla. Gli studi dimostrano che i programmatori che si accoppiano per risolvere i problemi tendono ad essere più sicuri, produttivi e coinvolti nel proprio lavoro. Sia che tu stia cercando il tuo prossimo lavoro o che tu stia assumendo nuove assunzioni, l'abbinamento è premuroso.

Risorse e ulteriori letture

• "Accoppia ruoli di programmazione", Jordan Poulton, GitHub
• "L'amicizia che ha reso Google enorme", James Somers, The New Yorker
• "Programmazione Mob: un approccio a tutto il team", Woody Zuill, YouTube

Empatia ingegneristica

Quando ho iniziato a insegnare a me stesso JavaScript, il mio codice somigliava molto al pavimento della mia camera da letto: lo lasciavo sempre più disordinato finché non avevo altra scelta che riordinarlo. Finché il mio browser web poteva capirlo, non mi importava come appariva.

È stato solo quando ho iniziato a rivedere il codice di altre persone che ho capito che dovevo mostrare molta più empatia per le persone che hanno recensito il mio.

L'empatia potrebbe essere lo strumento più sottovalutato nell'arsenale di qualsiasi sviluppatore. È il motivo per cui IDEO mette la ricerca degli utenti al centro del loro processo di progettazione e perché Etsy chiede ai designer e ai product manager di effettuare una rotazione ingegneristica. Empatia emerge quando abbiamo l'opportunità di vedere come il nostro lavoro ha un impatto sulle altre persone. Non c'è da stupirsi che la codifica collaborativa sia un ottimo modo per costruirla.

La revisione del codice tra pari, l'atto di controllare il codice dell'altro per verificare la presenza di errori, ci invita a esercitare empatia. In qualità di revisore, è importante riconoscere che qualcuno ha compiuto notevoli sforzi per scrivere il codice che stai per criticare. Pertanto, cerca di evitare di usare frasi che potrebbero implicare giudizi o banalizzare il loro lavoro. Quando fai riferimento al loro codice, vuoi mostrare loro le funzioni e le righe specifiche su cui hai domande e suggerire come potrebbero rifattorizzarlo. La condivisione delle risorse di apprendimento può anche essere più utile dell'alimentazione con il cucchiaio di una soluzione. Alcuni dei feedback più utili che ho ricevuto dalle revisioni del codice sono arrivati ​​sotto forma di articoli educativi, video e persino consigli sui podcast.

Anche scrivere una buona documentazione per il tuo codice fa molto. Un atto semplice come la creazione di un file readme con chiare istruzioni di installazione mostra empatia per chiunque abbia bisogno di lavorare con il tuo codice. Il fondatore di GitHub Tom Preston-Werner sostiene un approccio allo sviluppo basato sul readme.

“Una perfetta implementazione della specifica sbagliata è inutile. Per lo stesso principio, anche una libreria splendidamente realizzata senza documentazione è dannatamente quasi priva di valore. Se il tuo software risolve il problema sbagliato o nessuno riesce a capire come usarlo, sta succedendo qualcosa di molto brutto".

— Tom Preston-Werner, fondatore di GitHub

Ho anche parlato con i fondatori della tecnologia che considerano la documentazione una parte essenziale di un'integrazione di successo. Un CTO ha affermato che se uno sviluppatore junior fatica a raggiungere un livello di produttività entro sei mesi dall'ingresso nel suo team, indica che la base di codice non è sufficientemente documentata. Ci vogliono solo pochi secondi per aggiungere un commento esplicativo a una funzione complessa che hai scritto, ma potrebbe far risparmiare ore di lavoro alla prossima persona che si unisce al tuo team.

Risorse e ulteriori letture

• "Su empatia e richieste di attrazione", Slack Engineering, medio
• "Sviluppo basato su Readme", Tom Preston-Werner, GitHub
• "Quello che Google ha imparato dalla sua ricerca per costruire la squadra perfetta", Charles Duhigg, The New York Times Magazine

Successo agile

Dai milioni di ore di lavoro necessarie alla realizzazione di film in CGI alle intense fasi di sviluppo che portano alle versioni di videogiochi ad alto budget, gli enormi risultati tecnici richiedono uno sforzo sbalorditivo. La prima volta che ho visto la base di codice del mio attuale datore di lavoro, sono rimasto sbalordito dall'enormità di tutto. Come diavolo ha fatto qualcuno a costruirlo ?

La risposta è che ognuno può costruire molto più di chiunque altro , dato il giusto framework collaborativo. Nelle aziende che incoraggiano la codifica collaborativa, il software non emerge dagli sforzi di un genio solitario. Invece, ci sono modi di lavorare insieme che aiutano grandi team a fare un lavoro straordinario. Gli sviluppatori di Founders and Coders praticano una popolare metodologia di sviluppo software nota come "Agile" e, secondo la mia esperienza, mette il "funzionale" nei team di sviluppo interfunzionali.

Sono stati scritti interi libri su Agile, ma ecco un riassunto dei concetti fondamentali:

• Un team di sviluppo prodotto scompone grandi parti di lavoro in piccole unità chiamate "storie utente", assegna loro la priorità e le consegna in cicli di due settimane chiamati "sprint".
• Finché il progetto continua, i cicli si ripetono e i nuovi requisiti di prodotto vengono inseriti in un arretrato di attività per gli sprint futuri.
• Il team tiene riunioni quotidiane in piedi per discutere i propri progressi e affrontare eventuali blocchi.
• Il processo è sia incrementale che iterativo: il software viene costruito e distribuito a pezzi e perfezionato in sprint successivi.

Come armeggiatore cronico i cui progetti di hobby da solista spesso soccombono al "feature creep", so quanto sia facile perdere tempo a costruire cose che nessuno usa mai. Adoro il modo in cui Agile ti costringe a dare priorità alle storie degli utenti in modo che l'intero team possa concentrarsi sulla fornitura di funzionalità che interessano ai tuoi utenti. È motivante sapere di essere tutti uniti attorno all'obiettivo comune di costruire un prodotto o servizio che continuerà ad avere una vita dopo aver finito di lavorarci.

Anche la suddivisione delle attività in piccole storie utente è un ottimo modo per sincronizzare le sessioni di programmazione di timebox. Non importa quanto ti trovi nella zona in cui ti trovi, finire di lavorare su una caratteristica chiave è sempre un bel promemoria per allontanarti dalle tue scrivanie e fare una pausa. Agile dà struttura alla codifica collaborativa dove altrimenti potrebbe mancare.

Nel frattempo, gli standup quotidiani ti danno la libertà di parlare di tutto ciò che ti sta trattenendo e le retrospettive di sprint offrono lo spazio per condividere vittorie chiave e individuare dove la squadra potrebbe migliorare. Queste cerimonie promuovono un senso di collaborazione e responsabilità e ci aiutano a imparare di più insieme di quanto potremmo da soli.

Mettere in pratica tutti questi principi Agile può essere difficile, soprattutto quando nessuno in un team è abituato a questo modo di lavorare. In Founders and Coders, la maggior parte degli studenti impiega un po' di tempo per prendere l'abitudine di fare standup quotidiani. Tuttavia, dopo 18 settimane di pratica basata sui progetti, scopri che i tuoi processi e le tue capacità di comunicazione migliorano immensamente. Nel momento in cui assumi il tuo primo lavoro con il cliente, hai formato un modello mentale molto più chiaro su come affrontare la creazione di un'app Web full-stack in un team.

Il modo migliore per imparare Agile è costruire progetti interessanti con altre persone. Partecipare agli hackathon è un ottimo modo per entrare in contatto con potenziali collaboratori. Molti progetti open source rendono pubbliche le loro bacheche di progetto kanban, quindi puoi vedere su quali problemi GitHub stanno lavorando i diversi contributori. Diversi contributi di benvenuto da parte di principianti e spesso puoi assegnarti a problemi aperti e iniziare a sollevare richieste pull.

Poiché la maggior parte delle aziende tecnologiche si abbona a una qualche forma di Agile, non è raro che i datori di lavoro lo chiedano nelle interviste. Qualsiasi esperienza che hai può distinguerti dagli altri candidati che potrebbero non aver mai codificato in modo collaborativo, per non parlare di Agile in mente.

Risorse e ulteriori letture

• "Cos'è Agile?", Steve Denning, Forbes
• "Abbracciare l'agile", Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• "Fantastiche opportunità di prima richiesta pull", Shmavon Gazanchyan, Deloitte Digital

Suggerimenti per lo strumento di codifica collaborativa remota

Negli ultimi anni, gli strumenti di lavoro a distanza sono avanzati al punto che aziende di spicco come Gatsby e Zapier sono ora "prima in remoto". Mentre resta da vedere se questo si trasformerà in una tendenza, è sicuro dire che i team di sviluppo remoto sono qui per restare.

In questo spirito, ecco alcuni strumenti che possono aiutare te e il tuo team a programmare in modo collaborativo da lontano:

Se prendi qualcosa di negativo dalla lettura di questo articolo, voglio che i giocatori di squadra prevalgano sui contributori individuali. In un campo in cui sembra esserci un nuovo quadro caldo da padroneggiare ogni due settimane, le nostre competenze tecniche invecchiano in un modo che le nostre competenze trasversali non fanno. Il risultato è che gli sviluppatori che possono lavorare bene con altre persone scopriranno sempre che le loro capacità sono richieste. La codifica collaborativa non è solo un modo efficace per imparare; è un insieme di abilità ricercato che chiunque può sviluppare con sufficiente pratica e pazienza.