Dziękuję Sumo Logic 💙

Moja przygoda w Sumo Logic właśnie się zakończyła.

Jestem zadowolony, że mogłem pracować z tak wspaniałymi osobami 💙
3,5 roku pracy w amerykańskim środowisku dużo mnie nauczyły.

Zapraszam Was do artykułu opisującego zebrane doświadczenia.

Spis treści

1. Jak to się zaczęło?
2. Po pierwsze - Chcę programować
3. Chcę pracować w międzynarodowym środowisku
4. Język angielski
5. Feedback
6. Integracje
7. Onboarding
8. Dzielenie się wiedzą
9. Continuous Integration
10. Testy
11. Code ownership
12. Praca w sposób hybrydowy

Jak to się zaczęło?

Historia o moich początkach w Sumo Logic jest opisana przeze mnie w innym artykule. Nie ma sensu jej powtarzać. Zainteresowanych zapraszam do wpisu “Nowy początek”.

Po pierwsze - Chcę programować

Rozpoczynając pracę w Sumo Logic, byłem szczęśliwy, że wreszcie znowu programuję. Przez poprzednie 1,5 roku rozwijałem się jako full time trener programowania.

Nie zrozumcie mnie źle, uwielbiam uczyć ludzi, przekazywanie wiedzy sprawia mi frajdę. Natomiast czułem pewny niedosyt.

Czułem, że nie robię czegoś, co mnie bardzo rozwija - brakowało mi programowania.

Dziś już wiem, że bycie trenerem chcę łączyć z pracą przy projekcie. Tworząc same szkolenia, można wypaść z obiegu. Dlatego bardzo ważne jest, aby mieć regularną praktykę i styczność z kodem.

Bardzo lubię programować. Dziś już wiem, że to moje koronne zajęcie, które pokazuje mi, jak dużo jeszcze mogę się nauczyć.

Obok programowania, cenię sobie branżę edukacyjną, w której chciałbym od czasu do czasu się realizować.

Na trzecim miejscu jest fotografia, ale to już pewnie wiecie z mojego Instagrama.

Chcę pracować w międzynarodowym środowisku

Moje doświadczenie pracy w polskich firmach spowodowało, że wejście w świat amerykańskich standardów pracy nie było dla mnie płynne.

Styl pracy w międzynarodowych firmach jest inny, jest dość elastyczny.

Jako programista, 10 lat zarządzany z ramienia polskiego oręża, miałem inne doświadczenia w sprawach związanych z wykonywaniem pracy jak np.:

• czas pracy,
• planowanie zadań,
• rozliczanie projektów,
• podejście do deadline-ów,
• lessons learned.

Praca w międzynarodowym środowisku daje większe możliwości:

• poznania najlepszych praktyk zarządzania projektem,
• pracy w grupie w różnych strefach czasowych,
• dostępu do nowoczesnych technologii,
• poszerzenia o nowe horyzonty kulturowe,
• zwiedzenia świata poprzez podróże do innych lokalizacji firmy,
• oraz rozpoznawalność marki na całym świecie!

Język angielski

Nigdy wcześniej język angielski nie był tak często przeze mnie używany.

Podczas pracy w polskich firmach wystarczyło, że posiada się umiejętności do czytania dokumentacji narzędzi, których się używa. W procesach rekrutacyjnych do takich firm jest zwykle 1-2 pytania po angielsku, aby zweryfikować poziom kandydata.

W międzynarodowych firmach cała rekrutacja jest po angielsku. Dla osób bez codziennej praktyki tego języka może być to dość wymagające zadanie.

Praca w takim środowisku motywuje do nauki języka!

Gorąco polecam zajęcia z lektorem, w zależności od swojego poziomu zaawansowania, może być to lektor z Polski, a dla osób na wyższym poziomie, pewnie lepszym rozwiązaniem byłby “native” tj. nauczyciel z USA lub UK.

Podczas pracy w międzynarodowym środowisku, często brakowało mi konkretnego słowa lub zwrotu, którego mógłbym użyć, aby dokładniej opisać sytuację, odpowiedzieć na pytanie lub je zadać.

To mnie stopowało w płynnej pracy.

Jestem bardzo kontaktowym gościem, ale niestety z uwagi na braki w poprawnym używaniu gramatyki języka, miałem trudności w zainicjowaniu procesu i pracowaniu w stylu, jaki lubię, tj. szybka wymiana informacji między stakeholderami a mną.

Dodatkowo uwarunkowania kulturowe są równie ważne. W międzynarodowym środowisku bardzo ważne są konwenanse, np. używanie zwrotów grzecznościowych:

• “could you please …”
• “can you please …”
• “how about …”
• “do you think …”

Z tego miejsca mam dla Was listę zwrotów, których regularnie używa się w procesie wytwarzania oprogramowania. Jest to lista wyrażeń, które na szybko przychodzą mi do głowy.

• assumptions, assume (tego się nauczyłem na pierwszych interview)
• root cause
• low hanging fruits
• GA - General Availability
• rollout
• flaky tests

Feedback

Regularny feedback to podstawa do lepszej współpracy. Feedback składający się tylko z oceny rocznej, czy nawet półrocznej, to za długi okres na komunikację zwrotną.

Bez regularnego feedbacku, tylko z oceną roczną, trudno jest taki roczny feedback odbierać (bo jak bardzo jest on aktualny?).

Również dawanie feedbacku po tak długim czasie nie jest łatwe. Bez robienia notatek, nie sposób jest wszystko przytoczyć.

Dobry feedback powinien składać się z dwóch części:

• około 25% powinny stanowić informacje jednoznacznie pozytywne,
• natomiast 75% konstruktywnych informacje zwrotne, same konkrety mające praktyczne zastosowanie, żadnych błahostek.

Udzielanie feedbacków to twardy orzech do zgryzienia.

Tego trzeba się nauczyć samodzielnie, bo ani szkoła, ani studia nie uczą nas, jak przekazać komuś konstruktywną wiadomość, która pomoże mu rozwinąć skrzydła. Widać to nawet w dzisiejszych czasach w mediach społecznościowych, gdzie fala hejtu jest momentami żenująco ogromna.

Integracje

Okres pandemii pokazał mi (myślę, że nie tylko mi) ten ważny aspekt życia. Lockdown i zamknięcie w mieszkaniach nie sprzyja integracji. Ciężko jest nawiązać nowe znajomości przez Zooma. Siedząc w domu, nie możemy, chociażby przybić piątki na przywitanie! Osobiście, cenię sobie fizyczny kontakt z rozmówcą.

Gdy realizuję szkolenia, to czuje się lepiej na tych, na których widzę ludzi na żywo, gdzie mogę zobaczyć, czy rozumieją, co do nich mówię. Myślę, że to działa również w drugą strony. Uczestnicy mogą szybciej zadań pytanie itd.

Konferencje programistyczne

Wspólne wyjazdy na konferencje to świetny sposób na integrację zespołu.

Na poniższym zdjęciu możecie zobaczyć, jak większość z naszego teamu poleciała do Helsinek na konferencję React Finland 2022.

Dzięki temu wyjazdowi poznaliśmy siebie bardziej, co było świetną wartością dodaną do tego, czego się nauczyliśmy podczas merytorycznej części wydarzenia.

Off-site

Wydarzenia off-site, to wspólne wycieczki w dowolne miejsce na świecie (z dala od biura) w celu poznania się i integracji na innej płaszczyźnie niż tylko środowisko biurowe.

Tego typu wydarzenia to fajnie spędzony czas, wśród osób z firmy. Poznajemy więcej cech osób, z którymi współpracujemy.

Moim zdaniem takie rozwiązania są dobre, ale nie mogą być jedyną formą integracji. Podczas takiego wydarzenia z większością ludzi się niestety nie poznamy.

Onboarding

Duży codebase niesie pewne konsekwencje — duży czas potrzebny na wdrożenie się.

Uważam, że najlepszą formą poznawania nowego kodu jest “pair programming”. Podczas sesji pracy w parach, możemy dowiedzieć się więcej i szybciej o najważniejszych miejscach w kodzie, o procesie bootstrapingu aplikacji, czy też po prostu o najlepszej strategii do developmentu.

Nowa osoba poznająca projekt traktuje każdy plik z taką samą wagą. Dopiero po iluś tam miesiącach / latach pracy widzimy, że nie wszystko jest tak samo ważne. Istnieją miejsca, na które powinniśmy zwrócić szczególną uwagę:

• reużywalne, np. katalogi common, shared, utils,
• bootstrap aplikacji,
• komponenty z design systemu.

Dzielenie się wiedzą

Dzielenie się wiedzą, na spotkaniach całego teamu, jest super! 😍

Regularne spotkania, podczas których toczy się interesująca wymiana wiedzy, to czas, który pobudza do merytorycznych dyskusji.

Dzięki tego typu spotkaniom można uczyć się od siebie nawzajem, co jest fantastyczne. Każdy inżynier ma swoje doświadczenia, swoją historię, którą to dzieli się z innymi.

Continuous Integration

Stabilność narzędzia do Continuous Integration jest bardzo ważna.

Proces CI jest uruchamiany regularnie, aby sprawdzać, czy nasze zmiany czegoś nie zepsuły, wprowadzając jakże niechciane regresje.

Dlatego też niestabilny Jenkins, to zło z punktu widzenia czasu dowożenia. Niestabilność może się objawiać tym, że restart builda zmienia jego status, tj. gdy build zakończył się niepowodzeniem, to jego restart nie powinien dawać innego wyniku.

Do tego dochodzą również testy.

Testy

Tworzenie testów jest bardzo ważne - przepraszam za ten truizm.

Natomiast każdy z nas zetknął się z pisaniem testów, które to raz działały, a raz nie. Tego typu testy nazywane są “flaky”.

Tworząc testy w Cypressie, można sobie wypracować pewne rozwiązania, które spowodują, że tego typu testy będą mniej “fragile”.

Zasada 1.

Testy kodu są lepsze niż testy funkcjonalne.

Testy kodu, czyli testy jednostkowe oraz integracyjne. Nie przywiązujmy się do nomenklatury. Każdy zespół ma swoją.

Dlaczego?

1. Testy kodu są szybsze, możemy w testach jednostkowych wyrenderować komponent, a potem klikać po nim (prawie) tak samo, jak użytkownik,
2. Test kodu są mniej “flaky”, wszelkie zapytania HTTP są mockowane, więc odpada nam problem z długimi czasami odpowiedzi,
3. Nie trzeba ich uruchamiać na różnych środowiskach np. Chrome, Firefox etc.

Zasada 2.

Testy end-to-end na mockowanym środowisku, są lepsze od tych uruchomionych na środowisku produkcyjnym.

Dlaczego?

1. Nie musimy testować regularnie backendu, który i tak posiada swoje testy,
2. Dzięki mockowaniu danych, możemy wykreować dość nieoczekiwane przypadki,
3. Środowiska produkcyjne są regularnie używane, przez co dane w testach nie są deterministyczne.

Code ownership

Jeśli PR modyfikuje katalog, który był wpisany do pliku CODEOWNERS, oraz był do niej przypisany jakiś GitHub-owy zespół, to dany PR, musi zostać zaakceptowany przez osobę z tego zespołu, w przeciwnym przypadku nie można zmerdżować takiego PR-a do mastera.

Problem robi się czasochłonny, jeśli czekamy na review kogoś z innej strefy czasowej.

Więcej o code owners jest do poczytania na blogu GitHuba.

Praca w sposób hybrydowy

Praca w sposób asynchroniczny może być przeszkodą w efektywnej realizacji zadań.

Czekanie na odpowiedź od kolegów z różnych stron globu, może nie być instant. Zawdzięczamy to oczywiście różnym strefom czasowym.

Warto znać sposoby, aby nie tracić czasu i pracować efektywnie w takim zespole, który składa się z inżynierów pracujących w różnych “time zonach”.

Jak pracować efektywnie w międzynarodowym środowisku?
Tego dowiesz się z mojego “mięsistego” poradnika. Zapraszam!

Do zobaczenia! 🖐️

Jeszcze raz. Ten ostatni raz. Chciałem serdecznie podziękować wszystkim Sumo-ludzikom, z którymi miałem przyjemność pracować. Jestem przekonany, że nasze drogi jeszcze się przetną nie raz!