Dlaczego wspólne kodowanie to najlepszy hack kariery?

Pierwsze kroki w programowaniu to jak nauka języka obcego. Początkowo składnia nie ma sensu, słownictwo jest nieznane, a wszystko wygląda i brzmi niezrozumiale. Jeśli jesteś podobny do mnie, kiedy zaczynałem, płynność wydaje się niemożliwa.

Obiecuję, że nie. Kiedy zacząłem kodować, krzywa uczenia się uderzyła we mnie — mocno. Spędziłem dziesięć miesięcy, ucząc się podstaw, próbując odeprzeć zwątpienie, które teraz rozpoznaję jako syndrom oszusta. Dopiero gdy zacząłem chodzić na spotkania przyjazne początkującym, zdałem sobie sprawę, jak wspólne programowanie otwiera niesamowite możliwości. Potrzebujesz tylko odpowiedniej społeczności ludzi, z którą możesz ćwiczyć.

Dla mnie tą społecznością byli Founders and Coders, darmowy bootcamp JavaScript, który pomógł mi zmienić moją karierę z copywritingu na kodowanie. Nawet teraz, niecały rok po ukończeniu kursu, trudno mi uwierzyć, że płacą mi za tworzenie oprogramowania.

Wspólne kodowanie polega na rozwiązywaniu problemów i wspólnym znajdowaniu rozwiązań. Obejmuje techniki, takie jak programowanie w parach, które kilka firm technologicznych traktuje wystarczająco poważnie, aby sprawdzić podczas ich rozmów kwalifikacyjnych. Uprawia również przydatne umiejętności, których trudno się nauczyć, jeśli wszystko, co robisz, to programowanie samotnie w domu.

Niezależnie od tego, czy dopiero zaczynasz pracę w branży technologicznej, czy masz za sobą kilkuletnie doświadczenie, wspólne kodowanie nigdy nie przestaje być przydatne. W tym artykule przyjrzymy się, w jaki sposób te wiecznie zielone umiejętności przygotowują Cię do długiej i udanej kariery w tworzeniu oprogramowania.

Idealne parowanie

Moje pierwsze doświadczenie z programowaniem w parach miało miejsce na spotkaniu dla początkujących o nazwie Coding For Everyone. Oto jak to działa: ludzie łączą się w pary, często z osobami, których nigdy nie spotkali, aby wspólnie rozwiązywać wyzwania JavaScript przy jednym laptopie. Jedna osoba przyjmuje rolę „nawigatora” i proponuje kod, który według niej powinien zostać napisany. Druga osoba, „kierowca”, wpisuje swoje sugestie na laptopie i zadaje pytania, gdy coś jest niejasne. Kontynuujesz to, często zamieniając się rolami, aż do końca dwugodzinnej sesji.

W teorii było to proste. W praktyce nie tak bardzo.

Uważam, że to dość rozpraszające, gdy ktoś, kogo nie znałem, ogląda mój ekran podczas pisania, i niechętnie oddawałem kontrolę, gdy nadszedł czas na zamianę ról. Nawigacja była jeszcze trudniejsza. Kiedy pomysł nie może przejść z twojej głowy do komputera bez uprzedniego przejścia przez ręce twojego partnera, każde słowo, które wypowiadasz, ma znaczenie. Wymagało to od nas obojga komunikacji, do której po prostu nie byliśmy przyzwyczajeni, i byłem pewien, że oboje nauczymy się więcej, jeśli rozdzielimy się, by pracować osobno.

Na szczęście trzymaliśmy się tego; Poszedłem ponownie na spotkanie w następnym tygodniu. Od tego czasu spędziłem setki godzin w parze z dziesiątkami programistów i nauczyłem się więcej, niż początkowo sądziłem, że jest to możliwe.

Programowanie w parach to niezwykle szybki sposób na naukę. Magia tej metody — po przezwyciężeniu początkowej niezręczności — polega na tym, że przynosi ona natychmiastowe rezultaty. Niektóre pętle sprzężenia zwrotnego, takie jak bańki na giełdzie, mogą potrwać godziny, dni, a nawet miesiące, aby wprowadzić korektę. Programowanie par zajmuje minuty, jeśli nie sekundy. Gdy zgubisz średnik, dwie pary oczu mogą wykryć błąd szybciej niż jedna. Chcesz przeszukać StackOverflow w poszukiwaniu wskazówek dotyczących fałszywego komunikatu o błędzie? Ty i twój partner możecie czytać różne wątki, skracając o połowę czas potrzebny na znalezienie odpowiedzi.

W przypadku jeszcze trudniejszych problemów, programowanie mob może być kolejnym krokiem naprzód. Ta metoda wymaga międzyfunkcyjnej części zespołu, aby zebrać się wokół tego samego ekranu komputera i rozwiązań burzy mózgów w czasie rzeczywistym, podczas gdy jedna osoba pisze.

„Wszystkie genialne umysły pracujące nad tym samym, w tym samym czasie, w tej samej przestrzeni, na tym samym komputerze.”

— Woody Zuill, zwinny trener i trener programowania mafii

Chociaż może się to wydawać nieefektywnym sposobem pracy, zwolennicy programowania mobów, tacy jak Woody Zuill, twierdzą, że może to faktycznie zaoszczędzić czas, eliminując potrzebę indywidualnych przeglądów kodu, ponieważ wszyscy przeglądają kod w czasie rzeczywistym, gdy jest pisany. Pomijając produktywność, myślę, że mobbing to fantastyczny sposób na poznanie nie tylko kodu, ale także tego, jak inni ludzie podchodzą do problemów. Jeśli programowanie w parach podwaja liczbę perspektyw, na które jesteś narażony, programowanie mobów daje jeszcze więcej informacji.

Nie oznacza to, że parowanie – a właściwie mobbing – to zwykła żegluga. Coś, z czym początkowo się zmagałem, odkładało moje ego na bok, by zadawać pytania, które moim zdaniem mogą brzmieć głupio. W takich sytuacjach dobrze jest pamiętać, że twój partner może mieć te same myśli, zwłaszcza jeśli oboje dopiero zaczynacie.

Jeśli znajdziesz się w parze z kimś starszym, być może w pracy, nie bój się grzebać w jego mózgach i zaimponować mu swoją dociekliwością. Nawet ktoś, kto jest tylko trochę dalej niż ty, mógłby pomyśleć o rzeczach, które nie przyszłyby do głowy komuś starszemu. Niektórzy z moich ulubionych programistów par mają tylko kilka miesięcy więcej doświadczenia ode mnie, ale zawsze wydają się wiedzieć dokładnie, jakie błędy mam zamiar popełnić i jak poprowadzić mnie we właściwym kierunku. Kiedy ci programiści twierdzą, że nie ma czegoś takiego jak głupie pytanie, naprawdę to myślą. Najlepsi programiści w parach mówią swobodnie, nie muszą wyglądać fantastycznie ani nie obawiać się, że będą wyglądać na głupców.

Programowanie w parach wymaga praktyki, ale warto je doskonalić. Badania pokazują, że programiści, którzy łączą się w pary, aby rozwiązywać problemy, są bardziej pewni siebie, produktywni i zaangażowani w swoją pracę. Niezależnie od tego, czy szukasz następnej pracy, czy zatrudniasz nowych pracowników, łączenie w pary jest dla Ciebie ważne.

Zasoby i dalsze czytanie

• „Połącz role programistyczne”, Jordan Poulton, GitHub
• „Przyjaźń, która uczyniła Google ogromnym”, James Somers, The New Yorker
• „Programowanie tłumu: podejście obejmujące cały zespół”, Woody Zuill, YouTube

Empatia inżynierska

Kiedy zacząłem uczyć się JavaScript, mój kod wyglądał bardzo podobnie do podłogi w mojej sypialni: pozwalałem, żeby robił się coraz bardziej bałaganiarski, aż nie miałem innego wyboru, jak tylko go posprzątać. Dopóki moja przeglądarka internetowa mogła to zrozumieć, nie obchodziło mnie, jak to wygląda.

Dopiero gdy zacząłem recenzować kod innych osób, zdałem sobie sprawę, że muszę okazać dużo więcej empatii osobom recenzującym mój.

Empatia może być najbardziej niedocenianym narzędziem w arsenale każdego dewelopera. To jest powód, dla którego IDEO stawia badania użytkowników w centrum procesu projektowania i dlatego Etsy prosi swoich projektantów i menedżerów produktów o wykonanie rotacji inżynierskiej. Empatia pojawia się, gdy mamy okazję zobaczyć, jak nasza praca wpływa na innych ludzi. Nic dziwnego, że wspólne kodowanie to świetny sposób na jego zbudowanie.

Peer code review — czynność wzajemnego sprawdzania kodu pod kątem błędów — wzywa nas do wykazania się empatią. Jako recenzent ważne jest, aby zdać sobie sprawę, że ktoś włożył wiele wysiłku, aby napisać kod, który zamierzasz skrytykować. W związku z tym staraj się unikać wyrażeń, które mogą sugerować osądzanie lub trywializować ich pracę. Kiedy odwołujesz się do ich kodu, chcesz pokazać im określone funkcje i wiersze, o które masz pytania, i zasugerować, jak mogą to zmienić. Udostępnianie zasobów edukacyjnych może być również bardziej pomocne niż karmienie łyżką rozwiązania. Niektóre z najbardziej przydatnych opinii, jakie otrzymałem z recenzji kodu, miały formę artykułów edukacyjnych, filmów, a nawet rekomendacji podcastów.

Pisanie dobrej dokumentacji dla twojego kodu to również długa droga. Działanie tak proste, jak utworzenie pliku readme z jasnymi instrukcjami instalacji, świadczy o empatii dla każdego, kto musi pracować z Twoim kodem. Założyciel GitHub, Tom Preston-Werner, opowiada się za podejściem do programowania typu „readme first”.

„Doskonałe wdrożenie niewłaściwej specyfikacji jest bezwartościowe. Na tej samej zasadzie pięknie wykonana biblioteka bez dokumentacji jest również cholernie bezwartościowa. Jeśli twoje oprogramowanie rozwiąże niewłaściwy problem lub nikt nie może wymyślić, jak go używać, dzieje się coś bardzo złego”.

— Tom Preston-Werner, założyciel GitHub

Rozmawiałem również z założycielami technologii, którzy traktują dokumentację jako istotną część udanego onboardingu. Jeden z CTO powiedział, że jeśli młodszy programista ma trudności z osiągnięciem poziomu produktywności w ciągu sześciu miesięcy od dołączenia do swojego zespołu, oznacza to, że baza kodu nie jest wystarczająco dobrze udokumentowana. Dodanie objaśniającego komentarza do złożonej funkcji, którą napisałeś, zajmuje tylko kilka sekund, ale może oszczędzić kolejnej osobie, która dołączy do Twojego zespołu, wiele godzin pracy.

Zasoby i dalsze czytanie

• „O empatii i żądaniach pull”, Slack Engineering, Medium
• „Rozwój oparty na Readme”, Tom Preston-Werner, GitHub
• „Czego firma Google nauczyła się ze swojej misji budowania idealnego zespołu”, Charles Duhigg, magazyn The New York Times

Osiągnięcie zwinne

Od milionów godzin pracy poświęconych na tworzenie filmów CGI po intensywne etapy rozwoju prowadzące do wydania wysokobudżetowych gier wideo, ogromne osiągnięcia techniczne wymagają oszałamiającej ilości wysiłku. Gdy po raz pierwszy zobaczyłem bazę kodów mojego obecnego pracodawcy, powalił mnie ogrom tego wszystkiego. Jak u licha ktoś to zbudował ?

Odpowiedź brzmi, że każdy może zbudować o wiele więcej niż ktokolwiek inny , biorąc pod uwagę odpowiednie ramy współpracy. W firmach, które zachęcają do wspólnego kodowania, oprogramowanie nie powstaje dzięki wysiłkom samotnego geniusza. Zamiast tego istnieją sposoby współpracy, które pomagają wspaniałym zespołom wykonywać niesamowitą pracę. Programiści z Founders i Coders stosują popularną metodologię tworzenia oprogramowania znaną jako „Agile”, a z mojego doświadczenia wynika, że ​​„funkcjonalni” są umieszczani w wielofunkcyjnych zespołach programistycznych.

Na temat Agile napisano całe książki, ale oto podsumowanie podstawowych pojęć:

• Zespół ds. rozwoju produktu dzieli duże prace na małe jednostki zwane „historiami użytkownika”, nadaje im priorytety i dostarcza je w dwutygodniowych cyklach zwanych „sprintami”.
• Tak długo, jak projekt trwa, cykle się powtarzają, a nowe wymagania dotyczące produktu są wprowadzane do zaległości zadań dla przyszłych sprintów.
• Zespół organizuje codzienne spotkania standup, aby omówić swoje postępy i zająć się wszelkimi blokerami.
• Proces jest zarówno przyrostowy, jak i iteracyjny: oprogramowanie jest budowane i dostarczane w częściach oraz udoskonalane w kolejnych sprintach.

Jako nałogowy majsterkowicz, którego solowe projekty hobby często ulegają „pełzaniu cech”, wiem, jak łatwo jest marnować czas na budowanie rzeczy, których nikt nigdy nie używa. Podoba mi się sposób, w jaki Agile zmusza Cię do nadawania priorytetów historyjkom użytkowników, aby cały zespół mógł skoncentrować się na dostarczaniu funkcji, na których naprawdę zależy Twoim użytkownikom. Świadomość, że wszyscy jesteście zjednoczeni wokół wspólnego celu, jakim jest stworzenie produktu lub usługi, która będzie funkcjonować po zakończeniu pracy, jest motywująca.

Dzielenie zadań na małe historyjki użytkownika jest również świetnym sposobem na sesje programowania w parach timeboxów. Bez względu na to, jak głęboko się znajdujesz w strefie, zakończenie pracy nad kluczową funkcją jest zawsze miłym przypomnieniem, aby odejść od biurka i zrobić sobie przerwę. Agile nadaje strukturę kodowaniu zespołowemu tam, gdzie w innym przypadku mogłoby jej brakować.

Tymczasem codzienne standupy dają ci swobodę mówienia o wszystkim, co cię powstrzymuje, a retrospektywy sprintów zapewniają przestrzeń do dzielenia się kluczowymi zwycięstwami i wskazywania, co zespół mógłby poprawić. Ceremonie te wzmacniają poczucie współpracy i odpowiedzialności oraz pomagają nam uczyć się razem więcej, niż moglibyśmy sami.

Wdrożenie wszystkich tych zasad Agile w praktyce może być wyzwaniem, zwłaszcza gdy nikt w zespole nie jest przyzwyczajony do tego sposobu pracy. W Founders and Coders większość uczniów potrzebuje trochę czasu, aby przyzwyczaić się do robienia codziennych standupów. Jednak po 18 tygodniach praktyki projektowej okazuje się, że Twoje procesy i umiejętności komunikacyjne znacznie się poprawiają. Zanim podejmiesz się pierwszej pracy z klientem, utworzyłeś znacznie jaśniejszy mentalny model tego, jak podejść do tworzenia w zespole aplikacji internetowej z pełnym stosem.

Najlepszym sposobem na naukę Agile jest budowanie ciekawych projektów z innymi ludźmi. Udział w hackathonach to doskonały sposób na nawiązanie kontaktu z potencjalnymi współpracownikami. Wiele projektów typu open source upublicznia swoje tablice projektów Kanban, dzięki czemu możesz zobaczyć, nad którymi problemami GitHub pracują różni współtwórcy. Kilka powitalnych wkładów od początkujących i często możesz przydzielić się do otwartych problemów i zacząć zgłaszać żądania ściągnięcia.

Ponieważ większość firm technologicznych subskrybuje jakąś formę Agile, często zdarza się, że pracodawcy pytają o to podczas wywiadów. Każde posiadane doświadczenie może odróżnić Cię od innych kandydatów, którzy być może nigdy nie programowali wspólnie, nie mówiąc już o Agile.

Zasoby i dalsze czytanie

• „Co to jest Agile?”, Steve Denning, Forbes
• „Embracing Agile”, Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• „Awesome First Pull Request Opportunities”, Shmavon Gazanchyan, Deloitte Digital

Zalecenia dotyczące zdalnego narzędzia do wspólnego kodowania

W ciągu ostatnich kilku lat narzędzia pracy zdalnej rozwinęły się do tego stopnia, że ​​czołowe firmy, takie jak Gatsby i Zapier, są teraz „najpierw zdalne”. Chociaż okaże się, czy zmieni się to w trend, można śmiało powiedzieć, że zdalne zespoły programistyczne są tutaj, aby pozostać.

W tym duchu oto kilka narzędzi, które mogą pomóc Tobie i Twojemu zespołowi we współpracy z daleka:

Jeśli odejdziesz od przeczytania tego artykułu, chcę, aby gracze zespołowi przebili poszczególnych współtwórców. W dziedzinie, w której co drugi tydzień wydaje się, że są nowe, gorące ramy do opanowania, nasze umiejętności techniczne starzeją się w sposób, w jaki nie starzeją się nasze umiejętności miękkie. Skutek jest taki, że programiści, którzy potrafią dobrze współpracować z innymi ludźmi, zawsze odkryją, że ich umiejętności są poszukiwane. Wspólne kodowanie to nie tylko skuteczny sposób uczenia się; to poszukiwany zestaw umiejętności, który każdy może rozwinąć przy wystarczającej praktyce i cierpliwości.