Komunikacja z członkami zespołu

Po przejściu rekrutacji rozpoczniesz swoją pierwszą pracę, prawdopodobnie na stanowisku junior developera. Masz prawo czegoś nie wiedzieć. Nie ma niczego wstydliwego w tym, że zwrócisz się o pomoc. Dwie kwestie są kluczowe - w jaki sposób się pytasz i w jakich przypadkach.

Do kogo zwracać się o pomoc?

Jeśli firma, do której trafiłeś przydzieli ci 'opiekuna', czyli osobę, która będzie wprowadzać cię w projekt, albo po prostu jest oddelegowana do odpowiadania na twoje pytania techniczne to zwracasz się właśnie do niego. Jeśli nie masz takiego opiekuna, możesz zapytać się osoby, która cię wprowadza do firmy, do kogo możesz zwracać się w razie problemów/pytań/wątpliwości.

W drugiej kolejności (lub gdy nie masz przydzielonego opiekuna) pytaj się osób, które pracują przy twoim projekcie. Staraj się zorientować mniej-więcej jakim wycinkiem zajmuje się dany członek zespołu (backend, frontend, grafik, tester itp.) oraz jakie ma doświadczenie. Chodzi o to, żeby np. nie pytać się frontendowca w sprawie zagadnień typowo serwerowych, bo prawdopodobnie nie będzie miał o tym pojęcia (ale może wskazać ci odpowiednią osobę do przedyskutowania tego problemu!). Wspomniane szacunkowe określenie doświadczenia jest ważne, ponieważ opinia/porada bardziej doświadczonych programistów jest bardziej wiarygodna niż kogoś, kto ma 3 miesiące stażu pracy. Jednak w wielu przypadkach, zwłaszcza jeśli chodzi o stosunkowo proste rzeczy, odpowiedź zwykłego developera, czy nawet juniora będzie wystarczająco dobra.

Dodatkowo można (rozwijając przy okazji swoją sieć kontaktów towarzysko/zawodowych w firmie) zapytać się o poradę postronną osobę w firmie, na przykład napomykając o sprawie podczas przygotowywania kawy, czy podczas przerwy obiadowej. W tym przypadku potrzeba sporego wyczucia, bo nie każdy może lubić być zarzucanym problemami w takim czasie.

Jak pytać?

Pytania problemy można podzielić na kilka kategorii. Nazwijmy je umownie pytaniami konkretnymi, planowymi i architekturalnymi. Pytania konkretne to zwykle dosyć wąskie problemy. Przykładami mogą być brak elementu w dropdownie, pojawienie się wyjątku podczas uruchamiania metody. Zanim poprosisz o pomoc postaraj się jak najwięcej samemu wywnioskować. Nie należy z tym przesadzać - chyba nikt nie chciałby zatrudniać developera, który siedział 3/4 dnia główkując nad bugiem, który jest dobrze znany 'opiekunowi', i może go rozwiązać w 30s. Czas to pieniądz - wiadomo, z drugiej jednak strony zbyt częste zawracanie głowy drugiemu programiście jest bardzo irytujące. Zatem, ile czasu poświęcić na samodzielną próbę walki? Sporo zależy od kalibru problemu. Myślę, że zwykle powinno być to 20-40 min. W tym czasie próbujesz rozwiązać problem. W razie niepowodzeń, robisz krótki research (np. czytając o rozwiązaniach podobnych problemów na StackOverflow). Warto chwilę spędzić zastanawiając się, o co może spytać się twój opiekun, gdy zasięgniesz jego rady (jaką wersję modułu używasz; co pojawia się w logach etc.), tak, żeby jak najkrócej i jak najsprawniej przebiegła wasza rozmowa. Opiekun też ma masę rzeczy do zrobienia i nie zawsze ma czas na długie dysputy właśnie z tobą. Formułujesz zwięźle problem, mówisz jakie metody próbowałeś nieskutecznie użyć; możesz dorzucić swoje przypuszczenia, co do źródła błędu. Przykładowe pytanie: 'Cześć Adam, masz moment? Słuchaj, staram się naprawić buga. Chodzi o rozjeżdżającą się dolną sekcję interfejsu admina. Jest ona bardzo podobna do widoku zwykłego użytkownika, ale dodatkowo jest w nim wyświetlane kilka wykresów. Może to wtyczka wykresów to powoduje? W konsoli przeglądarki czysto, kaskada stylów wygląda właściwie tak samo jak dla zwykłego usera. W internecie sporo osób sporo osób skarży się na problemy z tym pluginem, i nawet są podane przykłady ich rozwiązania, ale żaden nie pomaga w naszym przypadku. Masz może pomysł jak to ugryźć?'

Oczywiście innym przypadkiem jest np. taki, gdzie opiekun prosi cię o znalezienie rozwiązania na problem, którego przyczyny on sam również nie zna. Wtedy warto poświęcić więcej czasu walcząc samemu. Ale nawet w tych zagadnieniach, gdzie opiekun nie poda ci od ręki konkretnego rozwiązania, może nakierować cię, podać wskazówki gdzie szukać rozwiązania, jakiej metody debuggingu użyć.

Pytania planowe natomiast są to pytania jak zaprojektować tabele bazy danych dla implementacji ficzera którego masz za zadanie zrobić; jaką bibliotekę wykorzystać do zrobienia danej rzeczy. Jest to taka klasa zagadnień, które warto przedyskutować przed implementacją, albo w jej wczesnym etapie. Warto powiedzieć o swoich zamiarach (zwłaszcza gdy nie jesteśmy pewni naszego pomysłu), ponieważ błędne podejście może kosztować zmarnowanych wiele godzin twojej pracy, albo nawet dni. Pytanie również w tym przypadku powinno być poprzedzone researchem z twojej strony. Czasem warto nawet zacząć implementację, 'obwąchać teren'. Szybka próba instalacja biblioteki może pomóc w stwierdzeniu, czy będzie ona działać z wersją frameworka obecną w projekcie itp. Przykładowe użycie: 'Hej, Piotrek, masz chwilę? Mam za zadanie zaimplementowanie dodania filtra graficznego do każdego avatara użytkownika. Z tego co przeczytałem, ludzie polecają użyć biblioteki X lub Y. X nie jest rozwijana od ponad roku, ale oprócz możliwości dodania takich filtrów ma dostępnych więcej innych modyfikacji grafiki. Y jest obecnie prężnie rozwijana, i ma przyjemniejsze API. Łatwiej się ją też instaluje, bo nie wymaga modułu Z w swoich zależnościach. Czy dobrze myślę, że lepiej pójść właśnie w kierunku Y?'

Pytania architekturalne są po prostu pytaniami w jaki sposób działa dana część aplikacji, lub jej całość. Przy rozbudowanym projekcie czasem bardzo ciężko jest prześledzić w kodzie różne ścieżki przebiegu działania aplikacji. Również bywa tak, że aplikacja korzysta z innej, wewnętrznej aplikacji, do której kodu nie masz dostępu. W obu przypadkach programista z zespołu może streścić ci jak działa kod. Również może pomóc w wyjaśnieniu dlaczego zastosowana jest taka biblioteka a nie inna; czemu dany fragment kodu został napisany w taki sposób itp. Przykładowo, może okazać się, że dziwna implementacja danej funkcjonalności została zrobiona w taki sposób, bo to wiązało się z decyzją biznesową, lub pod dyktando dużego klienta. Dzięki temu zamiast nawet kilkugodzinnego czytania kodu, i starania zrozumienia się co on robi, dostaniesz skondensowaną wiedzę w przeciągu kilku minut. Takiego typu pytania możesz zadawać przy przy okazji innych, konkretniejszych pytań, lub gdy natkniesz się na wyjątkowo frapujący fragment kodu itp. Oczywiście, nie należy pytać się o działanie każdej funkcji/metody z jaką się stykasz. Czytanie kodu należy do twoich zadań; wspomniane pytania pomagają jedynie w przyspieszeniu i ułatwieniu tego procesu. Również trzeba wyważyć częstotliwość i dogłębność takich pytań - pozostali programiści mają własne zadania, i nie zawsze mają możliwość prowadzenia tego typu dyskusji.

Najprawdopodobniej dostaniesz jakąś odpowiedź, albo wskazówkę. Jeśli to nadal nie wystarczy, spytaj jeszcze raz, opisując to, co próbowałeś zrobić. Nie bój się pytać wiele razy, nawet jeśli chodzi o tą samą sprawę. Staraj się jednak, żeby każda z tych interakcji wnosiła coś nowego od ciebie, tzn. podchodzisz ponownie pytając z nowymi wnioskami, obserwacjami. Jeśli nie zrozumiałeś porady opiekuna, dopytuj się aż zrozumiesz.

Kiedy zadać pytanie?

Dobrym czasem na zadawanie pytań jest czas, gdy pytany nie jest zajęty. Pora obiadowa nie jest dobrym momentem, bo programista może chcieć odpocząć od kodu, porozmawiać o innych rzeczach, czy po prostu w spokoju skonsumować posiłek. Mniej formalne, luźniejsze rozmowy z innymi podczas przerwy obiadowej są w porządku.

Kiedy nie zadawać pytań? Na początku pracy, i pod jej koniec. Warto zostawić margines ok. 20-30 min. w obu przypadkach. Powód jest prosty - zazwyczaj programista potrzebuje kilku/kilkunastu minut, żeby przejść mentalnie z świata codziennego do trybu pracy. Potrzebuje rozmościć się w swoim gniazdku. Z drugiej strony, końcówkę dnia developer chciałby pewnie poświęcić na domknięcie własnych zadań. Poza tym, mentalnie może już być na zewnątrz, co nie jest dobre przy rozwiązywaniu czyichś problemów.

Staraj się nie wyrywać programisty z 'zony' (ang. zone). Jest to stan dużego skupienia, gdzie developer jest totalnie oddany rzeczy nad która pracuje. Nie rozmawia on wtedy z innymi, często ma słuchawki na uszach, żeby odciąć się od czynników zewnętrznych. Istnieje tylko on i kod. Ten stan dosyć ciężko osiągnąć, ale będąc w nim jest się bardzo produktywnym. Właśnie dlatego najlepiej nie przerywać komuś pracę, tylko po to, żeby o coś się zapytać. Lepiej wykorzystać chwilę, gdy pytany wraca z kuchni, skończył luźną rozmowę, albo skończył właśnie rozmawiać z inną osobą na temat techniczny. O ile jest to możliwe, pytaj się o kilka rzeczy na raz.

Wyjątkami są sytuację, gdzie np. potrzeba natychmiastowej interwencji (typu gdy trzeba natychmiast naprawić błąd na produkcji). Wtedy trzeba jak najszybciej się uporać z tematem, i konwenanse można sobie darować.

Pytając opiekuna nie zaczynaj od razu od sedna problemu - programista potrzebuje parę chwil, żeby 'przełączyć kontekst', czyli wyjść myślami ze swojego bieżącego zadania, opuścić 'zonę', i skupić się na twoim problemie. Zatem, o ile nie zwracałeś się do niego w obrębie kilku godzin z tą samą sprawą postaraj się nakreślić tło, kilkoma zdaniami opisać to co masz do zrobienia. Obserwuj, czy pytany przełączył już uwagę na ciebie. Warto tu obserwować zwłaszcza oczy - skupienie uwagi zwykle jest związane ze skupieniem wzroku na twojej twarzy (oczach). Zatem podsumowując, nie pytaj w ten sposób: 'Hej Adam, mam problem z zapytaniem SQL do wyciągania transakcji klienta wraz z danymi z tabel A i B. Próbowałem zastosować indeksy...'. Zamiast tego o wiele lepiej pytać tak: 'Hej Adam...' - (czekamy chwilę, aż rozmówca skupi chociaż częściowo na nas swoją uwagę) - '... Mam za zadnie zoptymalizowanie wyciągania danych z bazy na potrzeby statystyk. Tymi danymi są transakcje klienta, wraz z dodatkowymi informacjami z tabel A i B, które potem przedstawiamy na wykresie w sekcji admina. Musimy te dane wyciągać szybciej, bo obecnie trwa to kilkanaście sekund. Próbowałem zastosować indeksy...'

Staraj się przedstawiać swój problem rozmówcy jak najbardziej klarownie. To, że ty w swojej głowie wiesz co masz na myśli, to nie znaczy, że opiekun natychmiast zrozumie twoją nieskładną wypowiedź. Jeśli masz z tym trudności, to zanim podejdziesz możesz ułożyć sobie plan wypowiedzi. Jeśli nie jesteś pewien znaczenia jakichś technicznych sformułowań, to lepiej ich nie używaj. Jeśli zagadnienie jest podobne do innego, z którym miałeś do czynienia możesz o tym wspomnieć. Dosyć często ułatwisz pytanemu zadanie, jeśli zastosujesz uogólnienie lub uszczegółowienie problemu. Na przykład masz za zadanie wymuszenie wykonywania się jakiegoś skryptu na serwerze aplikacji. Dobrym pytaniem będzie 'Hej Adam, mam za zadanie zautomatyzować uruchomianie skryptu co 2h. Albo inaczej - chodzi o uruchamianie skryptu podobnego do tych, które zajmują się usuwaniem starych rekordów z bazy. W jaki sposób mogę to zrobić?'. Drugie zdanie jest uszczegółowieniem.