În primul meu rol de inginerie software la un brand de comerț electronic, de multe ori am lucrat în secret la sarcini în afara responsabilităților mele principale. Și de multe ori m-am simțit izolat de coechipierii mei.

Prin urmare, când am fost invitat să particip la un curs bazat pe proiecte pentru a-mi îmbunătăți abilitățile de comunicare, am sărit cu ocazia.

Pentru program, am fost repartizat într-o echipă cu alți doi ingineri și o echipă de conducere pentru a construi o aplicație de stivă completă utilizând React, Python și Flask. Acum că cursul s-a terminat, m-am gândit să împărtășesc lecțiile pe care le-am învățat despre cum să fiu un jucător de echipă mai bun.

Lecția 1: Nu subestimați potențialul nivel de dificultate al unui proiect

Întrucât cursul a fost destinat inginerilor de bază, m-am gândit că voi avea o experiență, deoarece aveam deja o experiență profesională în Node.js. Acordat, stiva noastră tehnologică ar folosi un backend Python Flask, dar m-am gândit că Python și Flask nu ar fi prea greu de ridicat.

În prima zi a proiectului nostru, ni s-a arătat ce vom construi. Uau, brusc m-am simțit foarte nepregătit. Proiectul nostru a fost mult mai provocator decât mă așteptasem.

ad-banner

Ceilalți doi coechipieri ai mei păreau să ridice materialul cu ușurință. La sfârșitul primei noastre săptămâni am fost cel mai puțin membru al echipei noastre.

Știam React destul de bine, așa că front-end-ul nostru nu mi-a fost prea dificil. Dar backend-ul nostru folosea PostgresSQL și Python, pe care nici unul dintre ei nu le cunoșteam bine. A devenit rapid clar că sarcinile așteptate de la noi vor fi deosebit de provocatoare pentru cineva cu puțină experiență în Python.

Lecția 2: Solicitați feedback despre lucrările în curs

Inițial, de multe ori mă trezeam pierdând timpul făcând o muncă inutilă. De exemplu, odată am creat un formular de profil de utilizator editabil, fără să-mi dau seama că coechipierul meu se afla în mijlocul construirii unei componente de dialog reutilizabile a UI-ului material pe care aș fi putut-o folosi.

Altă dată am petrecut timp citind un tutorial despre cum să obțin identitatea unui utilizator autentificat, fără să-mi dau seama că coechipierul meu a dat deja seama.

Dându-mi seama cât timp petrec făcând o muncă inutilă, am început să postez în panoul nostru de mesaje Slack la ce lucram și să cer feedback. Colegii mei au răspuns rapid. Făcându-mi colegilor să ofere informații despre proiectele mele neterminate, am putut evita duplicarea muncii.

Lecția 3: Când este apăsat pentru timp, acordați prioritate pentru a evita învățarea

Având în vedere că m-am străduit să țin pasul cu volumul de muncă, trebuia să îmi prioritizez mai bine timpul. Ori de câte ori cineva a creat o funcție nouă, ar crea o solicitare Git Pull (PR) pentru a cere revizuirea codului. La început, am analizat fiecare PR și le-am acordat tuturor atenția mea deplină. Cu toate acestea, acest lucru s-a dovedit curând impracticabil.

Îmi amintesc că am petrecut mult timp examinând PR pentru a adăuga cookie-uri și jetoane pentru autentificare. Pentru a face o revizuire adecvată, am citit mai întâi o mulțime de informații de fundal despre probleme de securitate, cum ar fi cookie-urile, stocarea locală și atacurile de scriptare între site-uri. Când am terminat toată acea lectură, am citit prin PR, doar pentru a găsi tot codul avea sens și nu aveam nimic de comentat.

În retrospectivă, având în vedere cât de mult eram în urmă cu propriile sarcini, ar fi trebuit să ignor o mare parte din documentația cookie-urilor și, în schimb, să fac doar o revizuire rapidă a PR pentru a economisi timp.

Obținerea unei cunoștințe aprofundate despre funcționarea interioară a autentificării cookie-urilor noastre a fost de puțin folos pentru productivitatea mea generală. În schimb, alte PR-uri, cum ar fi cea care a configurat React Context pentru a trece starea prin aplicația noastră, au afectat direct aproape fiecare caracteristică la care am lucrat.

Prioritizarea obținerii unei înțelegeri profunde a acelui PR ar fi fost o utilizare mult mai valoroasă a timpului meu.

Lecția 4: Construiți noi caracteristici trecând de la bucăți la bucăți

Pentru a mă organiza mai mult, a trebuit să învăț cum să scap prin documentația tehnică. Am sunat un prieten inginer de-al meu, Sean Ellison-Chen, și i-am cerut procesul pentru abordarea unei noi caracteristici care necesită o tehnologie care este nouă pentru el.

El a explicat că mai întâi încearcă să înțeleagă cel mult 70% din ceea ce se întâmplă și apoi începe imediat să construiască caracteristica în bucăți. Fiecare bucată se angajează în git.

De exemplu, să presupunem că trebuie să configureze socket-uri web, ar putea configura o structură de schelet de bază pentru socket-uri web, să o angajeze în git, apoi să lucreze la următoarea bucată de configurare a evenimentelor socket corecte și așa mai departe.

Lucrând în bucăți, el asigură o progresie lină, de la abordarea minimelor până la a avea în cele din urmă o funcție pe deplin funcțională.

Lecția 5: Solicitați feedback de la conducătorul echipei dvs.

La jumătatea programului, am primit feedback de la conducătorul echipei noastre, Shums Kassam. Mi s-a spus să cer ajutor mai mult, să scotocesc documentația și să-mi folosesc colegii de echipă.

Am luat sfatul la inimă și am crescut de câte ori am postat în panoul nostru de mesaje. Am început să am apeluri video cu colegii de echipă pentru a revedea caracteristicile pe care le construiam. Am parcurs mai repede prin documentația tehnică și am evitat zonele mai puțin critice. Prin implementarea acestor modificări, rata contribuțiilor mele a accelerat.

Lecția 6: Evitați să faceți o treabă perfectă pentru sarcini ale căror cerințe s-ar putea schimba

Prin pur noroc, am aflat importanța amânării sarcinilor ale căror cerințe s-ar putea schimba.

Una dintre primele mele sarcini a fost crearea unui formular front-end care permite utilizatorilor să își schimbe informațiile de profil. Când am trimis codul meu spre examinare, mi s-a spus că aspectul formularului trebuie să fie fixat, deoarece unele dintre lungimile de intrare nu se potriveau.

În mod normal, aș fi petrecut cele 45 de minute pentru a-l repara chiar atunci. Dar am rămas cu mult în urmă în contribuțiile mele, așa că am comentat doar un „tot” despre potrivirea lungimilor de intrare și am combinat codul meu.

O săptămână mai târziu, un coechipier a subliniat că ar fi o experiență mai bună pentru utilizator să combine intrările separate „stradă”, „oraș”, „stat” și „țară” într-o singură intrare „adresă”. Când a simplificat intrările, comentariul meu „todo” nu mai era aplicabil.

Amânând să lucrez la formular, mă salvasem de la a face o muncă inutilă.

Lecția 7: Fiți confortabil cu trimiterea codului nerecomandat

Aproape de sfârșitul proiectului nostru, echipa noastră se grăbea să termine toate caracteristicile noastre înainte de o dată fixă, când vom prezenta proiectul nostru publicului. Am planificat ca toate funcțiile să fie trimise cu mult timp în avans pentru a ne oferi suficient timp pentru a practica și repeta.

Dar am ajuns să transmit trăsătura mea finală cu abia o oră la demo-ul nostru și a trebuit să ne grăbim să-l adăugăm. Deși prezentarea noastră a mers bine, am fost îngrijorat că am trimis trăsătura atât de târziu, deoarece a redus grav capacitatea echipei noastre de a repeta. demo-ul nostru în avans.

În retrospectivă, îmi dau seama că, în loc să trimit un cod optimizat și curat, aș fi putut economisi cel puțin două ore de timp prin simpla adăugare de comentarii despre refactorizare ulterior.

În ultimele luni, am învățat multe lecții despre cum să fii un jucător de echipă mai bun. Cel mai important, am învățat că munca în echipă este o abilitate care poate fi îmbunătățită la fel ca oricare alta.

Programul la care am participat a fost condus de Hatchways, o companie care îi ajută pe inginerii software să obțină primele locuri de muncă. La momentul scrierii acestui document, ei deservesc inginerii și companiile din America de Nord. Dacă sunteți un angajator care dorește să angajeze stagiari sau ingineri de bază, consultați Hatchways – Angajatori.

Sunt din orașul New York și în prezent caut o nouă funcție de inginerie software. Aici este CV-ul meu. E-mailul meu este siegel.moshes@gmail.com