De ce codificarea colaborativă este cel mai bun hack pentru carieră

A face primii pași în programare este ca și cum ai învăța o limbă străină. La început, sintaxa nu are sens, vocabularul este necunoscut și totul pare și sună de neinteligibil. Dacă ești ca mine când am început, fluența pare imposibilă.

Îți promit că nu este. Când am început să codesc, curba de învățare m-a lovit - greu. Mi-am petrecut zece luni învățând elementele de bază în timp ce încercam să alung sentimentele de îndoială pe care acum le recunosc drept sindromul impostorului. Abia când am început să merg la întâlniri prietenoase pentru începători, mi-am dat seama cum codificarea în colaborare deschide posibilități uimitoare. Ai nevoie doar de comunitatea potrivită de oameni cu care să exersezi.

Pentru mine, acea comunitate a fost Founders and Coders, bootcamp-ul gratuit JavaScript care m-a ajutat să-mi schimb cariera de la copywriting la codificare. Chiar și acum, la mai puțin de un an de la finalizarea cursului, cu greu îmi vine să cred că sunt plătit să dezvolt software.

Codarea în colaborare înseamnă abordarea problemelor și descoperirea soluțiilor împreună. Acesta cuprinde tehnici precum programarea în pereche, pe care mai multe companii de tehnologie le iau suficient de serios pentru a le verifica în timpul proceselor de interviu. De asemenea, cultivă abilități utile care sunt greu de învățat dacă tot ceea ce faci este să codezi singur acasă.

Indiferent dacă sunteți abia la început în industria tehnologiei sau aveți câțiva ani de experiență, codarea în colaborare nu încetează să fie utilă. În acest articol, vom analiza modul în care aceste abilități veșnic verzi vă echipează pentru o carieră lungă și de succes în dezvoltarea de software.

Împerecherea perfectă

Prima mea experiență de programare în pereche a fost la o întâlnire pentru începători numită Coding For Everyone. Iată cum funcționează: oamenii fac pereche, adesea cu oameni pe care nu i-au întâlnit niciodată, pentru a rezolva provocările JavaScript împreună, pe același laptop. O persoană își asumă rolul de „navigator” și propune codul despre care crede că ar trebui scris. Cealaltă persoană, „șoferul”, își scrie sugestiile pe laptop și pune întrebări ori de câte ori ceva nu este clar. Continuați să faceți acest lucru, schimbând rolurile frecvent, până la sfârșitul sesiunii de două ore.

În teorie, era simplu. În practică, nu atât.

Mi s-a părut destul de distragător să am pe cineva pe care nu-l cunoșteam care îmi urmărește ecranul în timp ce tastam și am fost reticent să predau controlul când era timpul să schimb rolurile. Mi s-a părut că navigarea este și mai dificilă. Când o idee nu poate trece din capul tău în computer fără a trece mai întâi prin mâinile partenerului tău, fiecare cuvânt pe care îl spui contează. Ne-a cerut amândoi un grad de comunicare cu care pur și simplu nu eram obișnuiți și eram sigur că amândoi vom învăța mai multe dacă ne despărțim pentru a lucra separat.

Din fericire, ne-am păstrat; Am fost din nou la întâlnire săptămâna următoare. De atunci, am petrecut sute de ore în asociere cu zeci de dezvoltatori și am învățat mai multe decât credeam inițial posibil.

Programarea în pereche este o modalitate incredibil de rapidă de a învăța. Magia metodei - odată ce treci peste stângacia inițială - este că dă rezultate imediate. Unele bucle de feedback, cum ar fi bulele de pe piața de valori, pot dura ore, zile sau chiar luni pentru a produce o corecție. Programarea perechilor durează minute, dacă nu secunde. Când greșiți un punct și virgulă, două perechi de ochi pot observa greșeala mai repede decât unul. Trebuie să căutați în StackOverflow indicii despre un mesaj de eroare necinstiți? Tu și partenerul tău poți citi fiecare fire diferite, reducând la jumătate timpul necesar pentru a găsi un răspuns.

Pentru probleme și mai complicate, programarea mafioților poate fi un pas suplimentar. Această metodă necesită ca o secțiune transversală a unei echipe să se adune în jurul aceluiași ecran de computer și să facă brainstorming de soluții în timp real, în timp ce o singură persoană scrie.

„Toate mințile strălucitoare lucrează la același lucru, în același timp, în același spațiu, pe același computer.”

— Woody Zuill, Agile Coach și Mob Programming Trainer

Deși ar putea părea o modalitate ineficientă de a lucra, susținătorii programării mafiote, cum ar fi Woody Zuill, spun că poate economisi timp prin eliminarea nevoii de revizuiri individuale a codului, deoarece toată lumea revizuiește codul în timp real pe măsură ce este scris. Lăsând deoparte productivitatea, cred că mobbing-ul este o modalitate fantastică de a învăța nu doar despre cod, ci și despre modul în care alți oameni abordează problemele. Dacă programarea în pereche dublează numărul de perspective la care ești expus, programarea mafiote oferă și mai multe perspective.

Asta nu înseamnă că împerecherea – sau într-adevăr mobbing – este simplă. Ceva cu care m-am luptat inițial a fost să-mi pun ego-ul deoparte pentru a pune întrebări despre care credeam că ar putea părea stupid. În aceste situații, este bine să rețineți că partenerul dvs. ar putea avea aceleași gânduri, mai ales dacă amândoi sunteți la început.

Dacă te trezești să faci perechi cu cineva mai în vârstă, poate la serviciu, nu-ți fie teamă să-i alegi creierul și să-l impresionezi cu curiozitatea ta. Chiar și cineva care este doar puțin mai în față decât ți-ai putea gândi la lucruri care nu i s-ar întâmpla cuiva mai în vârstă. Unii dintre programatorii mei preferați au doar câteva luni mai multă experiență decât mine, dar par să știe întotdeauna exact ce greșeli sunt pe cale să fac și cum să mă îndrume în direcția corectă. Când acești dezvoltatori spun că nu există o întrebare prostească, ei chiar vorbesc serios. Cei mai buni programatori perechi vorbesc liber, fără a fi nevoie să pară fantastici sau de teama de a arăta prost.

Programarea în pereche necesită practică, dar merită perfecționată. Studiile arată că programatorii care se asociază pentru a rezolva probleme tind să fie mai încrezători, mai productivi și mai implicați în munca lor. Indiferent dacă vă căutați următorul loc de muncă sau vă încorporați noi angajați, asocierea este îngrijitoare.

Resurse și lecturi suplimentare

• „Pereche de roluri de programare”, Jordan Poulton, GitHub
• „Prietenia care a făcut Google uriaș”, James Somers, The New Yorker
• „Programarea mafioților: o abordare a întregii echipe”, Woody Zuill, YouTube

Empatie inginerească

Când am început să mă învăț JavaScript, codul meu semăna foarte mult cu podeaua dormitorului meu: l-am lăsat să devină din ce în ce mai dezordonat până nu aveam de ales decât să-l aranjez. Atâta timp cât browserul meu web a putut înțelege, nu mi-a păsat cum arată.

Abia când am început să revizuiesc codul altor persoane, mi-am dat seama că trebuie să arăt mult mai multă empatie față de oamenii care îl revizuiesc pe al meu.

Empatia ar putea fi instrumentul cel mai subestimat din arsenalul oricărui dezvoltator. Acesta este motivul pentru care IDEO pune cercetarea utilizatorilor în centrul procesului lor de proiectare și de ce Etsy le cere designerilor și managerilor de produs să facă o rotație de inginerie. Empatia apare atunci când avem ocazia să vedem modul în care munca noastră afectează ceilalți oameni. Nu e de mirare că codarea colaborativă este o modalitate atât de grozavă de a o crea.

Evaluarea codului de la egal la egal – actul de a verifica reciproc codul pentru greșeli – ne solicită să exersăm empatia. În calitate de recenzent, este important să recunoașteți că cineva a depus un efort considerabil pentru a scrie codul pe care sunteți pe cale să îl criticați. Ca atare, încercați să evitați să folosiți expresii care ar putea implica judecată sau să le trivialeze munca. Când vă referiți la codul lor, doriți să le arătați funcțiile și liniile specifice despre care aveți întrebări și să sugerați cum l-ar putea refactoriza. Împărtășirea resurselor de învățare poate fi, de asemenea, mai utilă decât hrănirea cu lingura unei soluții. Unele dintre cele mai utile feedback pe care le-am primit de la recenziile de cod au venit sub formă de articole educaționale, videoclipuri și chiar recomandări de podcast.

Scrierea unei documentații bune pentru codul tău este, de asemenea, un drum lung. Un act la fel de simplu precum crearea unui readme cu instrucțiuni clare de instalare arată empatie pentru oricine trebuie să lucreze cu codul dvs. Fondatorul GitHub, Tom Preston-Werner, pledează pentru o abordare a dezvoltării, care se citește mai întâi.

„O implementare perfectă a specificațiilor greșite nu are valoare. După același principiu, o bibliotecă frumos lucrată, fără documentare, este, de asemenea, aproape lipsită de valoare. Dacă software-ul tău rezolvă problema greșită sau nimeni nu își poate da seama cum să-l folosească, se întâmplă ceva foarte rău.”

— Tom Preston-Werner, fondator GitHub

De asemenea, am vorbit cu fondatori de tehnologie care tratează documentația ca pe o parte esențială a integrării de succes. Un CTO a spus că, dacă un dezvoltator junior se luptă să atingă un nivel de productivitate în decurs de șase luni de la alăturarea echipei sale, înseamnă că baza de cod nu este suficient de bine documentată. Durează doar câteva secunde pentru a adăuga un comentariu explicativ la o funcție complexă pe care ai scris-o, dar ar putea economisi următoarea persoană care se alătură echipei tale ore de efort.

Resurse și lecturi suplimentare

• „Despre Empathy & Pull Requests”, Slack Engineering, Medium
• „Readme Driven Development”, Tom Preston-Werner, GitHub
• „Ce a învățat Google din încercarea sa de a construi echipa perfectă”, Charles Duhigg, The New York Times Magazine

Realizare Agile

De la milioanele de ore de lucru necesare pentru realizarea filmelor CGI până la crizele intense de dezvoltare care duc la lansări de jocuri video cu buget mare, realizările tehnice uriașe necesită un efort uluitor. Prima dată când am văzut baza de cod a actualului meu angajator, am fost uluit de enormitatea tuturor. Cum naiba a construit cineva asta?

Răspunsul este că toată lumea poate construi mult mai mult decât oricine , având în vedere cadrul de colaborare potrivit. În companiile care încurajează codificarea colaborativă, software-ul nu iese din eforturile unui geniu singuratic. În schimb, există modalități de a lucra împreună care ajută echipele grozave să facă o muncă uimitoare. Dezvoltatorii de la Founders and Coders practică o metodologie populară de dezvoltare de software cunoscută sub numele de „Agile” și, din experiența mea, pune „funcționalul” în echipele de dezvoltare interfuncționale.

S-au scris cărți întregi despre Agile, dar iată un rezumat al conceptelor de bază:

• O echipă de dezvoltare a produsului descompune bucăți mari de lucru în unități mici numite „povestiri ale utilizatorilor”, le acordă prioritate și le livrează în cicluri de două săptămâni numite „sprinturi”.
• Atâta timp cât proiectul continuă, ciclurile se repetă, iar noile cerințe de produs sunt introduse într-un stoc de sarcini pentru viitoarele sprinturi.
• Echipa ține zilnic întâlniri standup pentru a discuta progresul lor și pentru a aborda orice blocanți.
• Procesul este atât incremental, cât și iterativ: software-ul este construit și livrat în bucăți și rafinat în sprinturi succesive.

Fiind o persoană care mișcă în mod cronic, ale cărei proiecte de hobby solo cedează adesea în fața „feature creep”, știu cât de ușor este să pierzi timpul construind lucruri pe care nimeni nu le folosește vreodată. Îmi place modul în care Agile te obligă să prioritizezi poveștile utilizatorilor, astfel încât întreaga echipă să se poată concentra pe furnizarea de funcții la care utilizatorii tăi le pasă cu adevărat. Este motivant să știi că toți sunteți uniți în jurul obiectivului comun de a construi un produs sau serviciu care va continua să aibă o viață după ce veți termina de lucrat la el.

Împărțirea sarcinilor în povești mici de utilizator se întâmplă, de asemenea, să fie o modalitate excelentă de a sesiunilor de programare perechi timebox. Indiferent cât de adânc în zonă vă aflați, terminarea lucrării la o caracteristică cheie este întotdeauna un memento plăcut să vă îndepărtați de birouri și să faceți o pauză. Agile conferă structură codificării colaborative acolo unde altfel ar putea lipsi.

Între timp, standup-urile zilnice vă oferă libertatea de a vorbi despre orice vă reține, iar retrospectivele de sprint oferă spațiu pentru a împărtăși victoriile cheie și pentru a identifica unde echipa s-ar putea îmbunătăți. Aceste ceremonii promovează un sentiment de colaborare și responsabilitate și ne ajută să învățăm împreună mai multe decât am putea singuri.

Punerea în practică a tuturor acestor principii Agile poate fi o provocare, mai ales când nimeni din echipă nu este obișnuit cu acest mod de lucru. La Founders and Coders, majoritatea studenților durează ceva timp pentru a-și lua obiceiul de a face standup-uri zilnice. Cu toate acestea, după 18 săptămâni de practică bazată pe proiecte, descoperiți că procesele și abilitățile dumneavoastră de comunicare se îmbunătățesc enorm. În momentul în care vă asumați primul lucru client, v-ați format un model mental mult mai clar despre cum să abordați construirea unei aplicații web full-stack într-o echipă.

Cel mai bun mod de a învăța Agile este să construiești proiecte interesante cu alți oameni. Participarea la hackathoane este o modalitate excelentă de a intra în legătură cu potențiali colaboratori. Multe proiecte open-source își fac publice panourile de proiect kanban, astfel încât să puteți vedea la ce probleme GitHub lucrează diferiți colaboratori. Câteva contribuții binevenite din partea începătorilor și deseori vă puteți desemna probleme deschise și începe să ridicați solicitări de tragere.

Deoarece majoritatea companiilor de tehnologie sunt abonate la o anumită formă de Agile, nu este neobișnuit ca angajatorii să întrebe despre asta în interviuri. Orice experiență pe care o aveți vă poate diferenția de alți solicitanți care nu au codificat niciodată în colaborare, cu atât mai puțin cu Agile în minte.

Resurse și lecturi suplimentare

• „Ce este Agile?”, Steve Denning, Forbes
• „Embracing Agile”, Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• „Oportunități uimitoare de primire a cererii de tragere”, Shmavon Gazanchyan, Deloitte Digital

Recomandări pentru instrumentul de codificare colaborativ la distanță

În ultimii câțiva ani, instrumentele de lucru la distanță au avansat până la punctul în care companii proeminente precum Gatsby și Zapier sunt acum „în primul rând la distanță”. Deși rămâne de văzut dacă acest lucru se va transforma într-o tendință, este sigur să spunem că echipele de dezvoltare la distanță sunt aici pentru a rămâne.

În acest spirit, iată câteva instrumente care vă pot ajuta pe dvs. și echipa dvs. să codificați în colaborare de la distanță:

Dacă luați un lucru de la citirea acestui articol, vreau să fie ca jucătorii de echipă să învingă contribuitorii individuali. Într-un domeniu în care pare să existe un nou cadru fierbinte de stăpânit o dată la două săptămâni, abilitățile noastre tehnice îmbătrânesc într-un mod în care abilitățile noastre soft nu o fac. Rezultatul este că dezvoltatorii care pot lucra bine cu alți oameni vor găsi întotdeauna că abilitățile lor sunt solicitate. Codarea în colaborare nu este doar o modalitate eficientă de a învăța; este un set de abilități căutat pe care oricine îl poate dezvolta cu suficientă practică și răbdare.