Jaki był największy problem, z którym musiałeś się zmierzyć? Seniorzy odpowiadają (cz.1)

Quora to miejsce pełne inspirujących treści, ale przede wszystkim pytań, które developerzy zadają innym developerom. My postanowiliśmy znaleźć wyjątkowe, a przede wszystkim pytania otwarte, które dadzą różnorodne odpowiedzi. Zebraliśmy je w jednym miejscu i przesłaliśmy seniorom, by poznać ich zdanie na tematy związane z pracą developera. Jak odpowiedzieli na pytanie dotyczące największego problemu, z którym musieli się zmierzyć?

Jaki był największy problem, z którym musiałeś się zmierzyć w ciągu całej historii pracy na stanowisku developera? Czego nauczyło Cię jego rozwiązanie?

Odpowiada: Wojtek Zając, Lead Frontend Developer w X-Team

Jednym z większych problemów, z którymi musiałem się zmierzyć jest nieodpowiednia komunikacja. Na myśl przychodzi mi projekt dla klienta z Los Angeles, w którym część osób pracowała w jego biurze, druga część w Krakowie, a pozostali zdalnie. Jako lider techniczny kilka razy w roku przemieszczałem się pomiędzy zespołami i zauważyłem szereg dość istotnych moim zdaniem problemów.

Pierwszą kwestią są różnice kulturowe. Amerykanie używają pozytywnego języka, którego trzeba nauczyć się odczytywać. W języku polskim często brakuje nam tej dodatkowej strefy “buforu”. Na myśl przychodzi mi sytuacja, w której – podczas grupowego calla z kierownictwem – jeden z developerów w Polsce dość mocno wypowiedział się na temat kodu, który to dotychczas był utrzymywany przez pracowników klienta. Innym razem negatywnie zostały ocenione umiejętności ów pracowników podczas ich nieobecności. Znając tę osobę zdaję sobie sprawę z tego, że jedynym zamiarem było przekonanie klienta do słuszności refaktoryzacji, a przy okazji pokazanie się jako osoba z bardzo dużą wiedzą. Niestety, zostało to oczywiście odebrane jako niepotrzebny atak i pozostawiło niesmak. Uważam, że w języku polskim jesteśmy niepotrzebnie negatywni i takie sytuacje zdarzają się dość często. Zazwyczaj w takiej sytuacji staram się tłumaczyć, że w rozmowach z klientem wymagana jest większa ostrożność w doborze słów. Innym rozwiązaniem jest też oddzielenie klienta od zespołu developerów. Wszystko zależy od sytuacji i charakteru członków zespołu.

Oferty pracy z

Drugi problem wynikał z braku zrozumienia zadań. Dla developerów “product team” nie wykonywał żadnej mierzalnej pracy. Tymczasem część produktowa musiała uporać się z dużą ilością prac koncepcyjnych. Z drugiej strony, developerzy mają skłonność do zbyt rzadkiego aktualizowania o statusie swoich zadań. W takim wypadku osoby o innych rolach nie mają świadomości, na jakim etapie jest projekt. Stąd konieczna jest transparentność i regularny kontakt.

Moim zdaniem nauka odpowiedniej komunikacji to wyjątkowo często pomijany aspekt w rozwoju programistów. Lepsze umiejętności miękkie oraz rozwój inteligencji emocjonalnej są konieczne w celu dalszego podążania ścieżką kariery.

Odpowiada: Michał Załęcki, Senior Software Engineer w Tooploox

Żaden z typowo technicznych problemów, a było kilka ciekawych, nie zapadł mi w pamięci tak jak pierwsze doświadczenia bycia prelegentem i podzielenia się wiedzą ze sceny. Przynajmniej w moim przypadku, nigdy nie jest tak, że kończę slajdy i jestem pewien, że wszystko pójdzie po mojej myśli. Pojawiają się wątpliwości czy na pewno dostatecznie prosto potrafię wytłumaczyć dane zagadnienie, a może uczestnicy będą znudzeniu, bo już wiedzą to o czym chcę powiedzieć. Najważniejsza lekcja jaką wyniosłem z doświadczenia bycia prelegentem to to, że osoby, które cię słuchają są po twojej stronie i chcą by ci się udało. Pytania, które zadają nie mają na celu wpuszczenia cię w maliny, a są świetną okazją na dopowiedzenie tego czego nie udało ci się przekazać podczas prezentacji i stanowią świetny informację zwrotną, która pomoże ulepszyć twoje wystąpienie.

Odpowiada: Kuba Bomba, Head of Product w Piwik PRO

Kiedy Piwik PRO zaczął się rozrastać, pojawiła się potrzeba zaangażowania kilku cross-funkcjonalnych zespołów. Wraz z przyrostem liczby osób pracujących nad projektem pojawiły się problemy komunikacyjne. Skupiłem się na tworzeniu interfejsów do komunikacji. Nie wszystkie pomysły się sprawdziły, ale to, co zadziałało w naszym przypadku to:

• Story mapy — dzięki nim widzimy szerszy obraz tego, nad czym pracujemy. Wiemy, co
  będzie zrobione w najbliższych tygodniach i (co równie ważne), co nie będzie.
• Cross-teamowe code review w ramach specjalizacji.
• Wyznaczenie jednego miejsca, gdzie każdy team może zgłaszać błędy i śledzić ich
  status.
• Wspólny kanał na Slacku do omawiania bieżących problemów.
• Opcjonalna obecność na spotkaniach (zależy nam na zaangażowaniu, nie na
  frekwencji) i wprowadzenie moderatorów czuwających nad dynamiką obrad.

Odpowiada: Mateusz Pacholec, Senior Software Developer w Objectivity

Wydaje mi się, że największym problemem było stworzenie rozwiązania idealnego do globalnej obsługi wyjątków. Chodzi o pełną obsługę po stronie serwera z przekazaniem w sensowny sposób informacji zwrotnej w odpowiedzi API (przekazać kod błędu do UI, a może pełną wiadomość — problem tłumaczenia, itp). Jest to bardziej problem designu samego systemu. Wydawać by się mogło, że jest to podstawowa rzecz. Jednak, aby dobrze zrealizować taką obsługę trzeba spojrzeć nieco szerzej na system. Pozwoliło mi to na porządne przemyślenie architektury i sposobu przekazywania informacji między warstwami.

Odpowiada: Sławomir Kaleta, Senior Developer PHP w CityCore

Najtrudniejsze zadanie z jakim się zetknąłem to przygotowanie skryptu w dwie godziny, który będzie w PHP asynchronicznie tworzyć workery obliczające odległości euklidesowe (nie wykluczając możliwości zmiany wykorzystania do czegoś innego). Wtedy nawet nie miałem bladego pojęcia, co to jest.

Główny skrypt miał ładować pliki i dzielić je na w miarę równe części, a następnie przesyłać je do workerów, które obliczały odległości. Dodatkowo każdy worker miał mieć zabezpieczenie w przypadku zawieszenia. Gdy się z jakiegoś powodu zawiesił, miał wznowić w miejscu, w którym skończył. Skrypt musiał obliczać na podstawie innych workerów, ile to powinno zająć, a jeśli skrypt wykonywał się za długo, miał go ubijać i tworzyć na nowo. W przypadku ponownego błędu miała iść informacja o niepowodzeniu pojedynczego workera, ale nie przerywać działania całości.

Po wyliczeniach ponownie trzeba było scalić plik w jeden z wynikami. W przypadku niepowodzenia workera, trzeba było ręcznie znaleźć błąd w podzielonej paczce danych i uruchomić skrypt, który by nie robił już całości tylko dokończył to co pozostało. Jak rozwiązałem ten problem? Szybko wpisałem w Google, przejrzałem StackOverflow i zacząłem pisać. Czego wtedy nauczyłem się? Nauczyłem się jak się liczy odległość euklidesową.

Zobacz też

growth hacks Programowanie to sztuka? Prawdy i mity na temat pracy programisty

Odpowiada: Mac Wasilewski, Senior Frontend Developer w Experian

Największy problem z jakim musiałem się zmierzyć wcale nie był związany z programowaniem, ale z interakcją z innymi zespołami. Firma, w której pracuje zatrudnia programistów w różnych oddziałach na całym świecie i zdarza się, że tworzymy PR (Pull Requests) do repozytoriów innych zespołów. My jako zespół mamy pewne wytyczne i standardy, w jaki tworzymy kod czy piszemy unit testy, sposoby w jakie nazywamy nasze commity, itp. I problem pojawia się, gdy ktoś z nas chce dodać kod do repozytorium innego zespołu, który może mieć odrobinę inne standardy. To prowadzi do dyskusji w komentarzach na temat kodu, czasem wydaje nam się, że komentarze te są głupie, że ktoś chce żebyśmy zmienili nasz kod w sposób, który uważamy za zły. Trzeba jednak zrozumieć, że ktoś kto chce żebyśmy zmienili nasz kod, nie znaczy, że go nie lubi, czy że kod jest wadliwy, tylko chce, żeby jego repozytorium utrzymało te same standardy i założenia.

Najlepiej więc zamiast wdawać się w dyskusje w komentarzach o wyższości jednych standardów nad drugimi, co spowalnia pracę, zorganizować szybką konferencję Skype i wyjaśnić wszystko. To samo tyczy się, gdy inny zespół dodaje PR do twojego repozytorium — nie wdawaj się w bezsensowne komentarze, zorganizuj telekonferencję i wyjaśnij wszystko. Najlepiej dbaj o to, by twoje README zawierało, wszystko co wymagasz od innych członków twojego zespołu.

Odpowiada: Kamil Warpechowski, Lead JavaScript Developer w MACRO-SYSTEM

Moim zdaniem największym wyzwaniem w pracy projektowej jest dobór zespołu technicznego pod kątem umiejętności. Panuje błędne przekonanie, że zespół złożony z samych seniorów będzie dowoził tysiące razy szybciej, niż grupa z zróżnicowanym doświadczeniem. Miałem okazję współpracować z ludźmi o ogromnym doświadczeniu w tej samej dziedzinie oprogramowania. Sęk w tym, że każdy definiował standardy na swój specyficzny sposób. Prowadziło to do wielu zbędnych konfliktów na poziomie spacje kontra tabulatory. Atmosfera w projekcie była ciężka do przeżycia, co oddziaływało dużymi opóźnieniami realizacji pracy oraz znaczącą rotacją pracowników. Człowiek z natury chce pokazać swoją wyższość. Jednakże w pracy zespołowej duże natężenie “unikalnych” jednostek nie przynosi dobrych efektów.

Członkowie tego projektu zostali podzieleni na dwie grupy. Stworzyły się obozy rywalizujące ze sobą, a “przenaszalność” zarówno kodu, jak i umiejętności została zniwelowana do zera.
Odpowiedni dobór doświadczenia w zespole jest niezmiernie ważny. W dobrze prowadzonym projekcie jest zajęcie zarówno dla wysokopoziomowego projektowania rozwiązania, jak i poprawiania drobnostek w wyglądzie aplikacji. Dzięki zróżnicowanemu doświadczeniu praca idzie dynamiczniej, a sam proces developmentu jest krótszy. Motywacja do pracy potrafi być ogromna dzięki temu, że osoby uczące się nowych umiejętności mają większe samozaparcie i chęci do eksperymentowania. Rola seniora sprowadza się wtedy nie do narzucania standardów i pilnowania ich jak zły policjant, lecz naprowadzaniu na prawdopodobne rozwiązania.

Ważną częścią pracy są dyskusje i wspólne planowanie rozwiązań. Wiele razy tzw. juniorzy potrafili zaproponować nietuzinkowe rozwiązania, na które team leader by nie wpadł, ponieważ od lat powtarza ten sam niekoniecznie sprawdzony schemat. Największą nagrodą dla mnie jest, jak zespół bez mojego udziału debatuje nad najlepszym rozwiązaniem problemu jeszcze na białej tablicy zamiast w edytorze kodu. Implementacja przemyślanych rozwiązań daje ogromną frajdę i chęć do budowania czegoś wartościowego — nawet w niezbyt fascynującej domenie biznesowej.

Dzięki wspólnym sesjom brainstormingowym oraz chęcią do dyskusji mamy spójny, przemyślany i komponentowy kod. Każdy z członków zespołu jest na bieżąco z ogólną koncepcją realizacji projektu, bo przecież każdego dnia uczestniczy w jej definiowaniu niezależnie od ilości lat przesiedzonych przed monitorem.

Warto pamiętać, że programistę nie powinno się oceniać przez pryzmat ilości znanych frameworków javascriptowych, lecz pod kątem umiejętności rozwiązywania realnych problemów w oderwaniu od konkretnej technologii.

Niebawem opublikujemy odpowiedzi na kolejne pytania, które znaleźliśmy na Quorze. Teraz czekamy na Wasze odpowiedzi w komentarzach — jesteśmy ciekawi, z jakimi Wy problemami dotychczas spotkaliście się.