inhire.ioBlogPraca w ITTeam Leader w IT. Na czym polega jego praca i z jakimi wyzwaniami mierzy się w CKSource?

Team Leader w IT. Na czym polega jego praca i z jakimi wyzwaniami mierzy się w CKSource?

Praca w IT
25/04/2022

Czy praca programisty i lidera zespołu jest nudna i monotonna? Porozmawialiśmy na ten temat z Jackiem Bogdańskim, który od kilku lat pracuje w CKSource – obecnie na stanowisku Team Leader & Solution Architect, ale zajmuje się również programowaniem. Opowiedział nam jak wygląda od kuchni jego praca, który projekt wymagał największej pracy i zaangażowania oraz co minimalizuje rotację w jego zespole.

Jesteś liderem zespołu w CKSource. Jak wyglądała twoja ścieżka kariery do tej pory?

Przygodę z IT zacząłem stosunkowo późno w porównaniu do “statystycznego developera”, ponieważ moje pierwsze studia nie były związane ze ścieżką kariery programisty. Dopiero w wieku 24 lat zdecydowałem się na zmianę kierunku rozwoju i poszedłem na inżynierię oprogramowania na Politechnice Warszawskiej. Jednak od tego czasu zawodowo zajmuję się wyłącznie IT.

Pierwszym stackiem technologicznym, w który całkowicie się zaangażowałem był .NET. JavaScript, z którym pracuję teraz na co dzień, pojawiał się raczej w formie dodatku, byłem typowym full stackiem zajmującym się głównie backendem z odrobiną frontu – “gdy leader kazał”. Podejrzewam, że określenia fanboy Microsoftu lub hejter JavaScriptu świetnie by wtedy do mnie pasowały 🙂 Po latach zdobywania doświadczenia zacząłem zupełnie inaczej traktować technologie, z którymi pracuję – przede wszystkim jako narzędzie, bez dokładania do tego zbędnej filozofii.

Z platformą .NET miałem do czynienia przez ok 4-5 lat – zarówno w formie projektów hobbystycznych, jak i pracując jako programista. Uznałem jednak, że nie mogę dalej ignorować tego, co się dzieje po drugiej stronie projektów, nad którymi pracuję i czas najwyższy zrozumieć, jak działa frontend. Po dokładnym screeningu różnych firm skupiających świetnych programistów JavaScript, zdecydowałem się wysłać tylko jedno CV, do CKSource.

Chyba najistotniejszym powodem, dla którego zdecydowałem się wysłać CV właśnie do tej firmy, była możliwość podejrzenia otwartego kodu źródłowego obu edytorów CKEditor – 4 oraz 5. Dzięki temu mogłem samodzielnie sprawdzić poziom softu pisanego przez developerów oraz przekonać się, jaka jest kultura pracy podczas procesu review – wiedziałem już na co się piszę, aplikując do tej firmy. Jestem z CKSource już ponad 4 lata – to chyba mój najdłuższy staż w jakiejkolwiek firmie, w której pracowałem.

Masz już kilkuletnie doświadczenie jako programista. Co z perspektywy czasu było dla ciebie największym wyzwaniem w tym zawodzie?

Radzenie sobie z porażkami jest chyba jedną z tych umiejętności, których bardzo trudno się nauczyć, niezależnie od zawodu, stażu pracy czy też funkcji, jaką pełnimy w firmie. Programowanie jest kreatywną pracą, gdzie często identyfikujemy się z kodem, który piszemy oraz produktami, które tworzymy. Niestety, liczba zmiennych wpływających na powodzenie projektu jest ogromna. W literaturze można spotkać się z bardzo wysokim odsetkiem nieudanych projektów IT, czasami failure rate sięga nawet 70-75%.

Sądzę, że w przypadku projektów webowych failure rate jest znacznie niższy, jednak kwestia tego, czy developer zmierzy się z odrzuconym kodem, nad którym pracował wiele dni, tygodni czy miesięcy to kwestia czasu, a nie szczęścia czy nawet doświadczenia.

Myślę, że największym wyzwaniem, z którym musiałem się zmierzyć było właśnie wyciąganie odpowiednich wniosków z projektów, które się nie udały, a nie z tych, które zakończyły się sukcesem. Projekt, który udało się zrealizować daje oczywiście ogrom doświadczenia oraz satysfakcji. Jednak to te nieudane projekty, usunięte linijki kodu oraz rozpalone dyskusje na GitHubie wymagały ode mnie największego wysiłku. Zależało mi na tym, aby poświęcony czas został przekuty w wartość dodaną dla firmy, nawet jeśli sam projekt bądź kod nie dotrwa do fazy deploymentu.

Przeczytaj także – Zgrany zespół przyciąga kandydatów, którzy zostają na długo – CKSource

Opowiedz, co należy do twoich obowiązków i jak wygląda twój typowy dzień pracy.

Do moich obowiązków należy zarówno dbanie o “zdrowie” zespołu – upewnienie się, że osoby, z którymi współpracuję rozwijają się oraz dobrze rozumieją cele projektowe – jak i prowadzenie samych projektów w kwestiach produktowych i technicznych. Mam tu na myśli precyzowanie wizji projektu w kontekście realizowania celów biznesowych, tego, jak dany produkt ma działać, oraz samą implementację projektu, czyli planowanie architektury i struktury kodu. Biorę również czynny udział w samym procesie powstawania kodu.

Jak wygląda mój typowy dzień pracy? Każdego poranka odpalam Slacka, ogarniam najpilniejsze wrzutki, które pozostały mi z dnia poprzedniego, a następnie rezerwuję sobie parę godzin na pracę typowo developerską, tj. programowanie bądź inspekcję kodu. Dalsza część dnia, to zazwyczaj dyskusje na temat problemów architektonicznych w naszych projektach oraz komunikacja z innymi zespołami. Co jakiś czas dochodzi także backlog refinement produktów oraz wsparcie klientów, jeśli ich zgłoszenia wymagają pomocy osoby technicznej. Mamy również regularne spotkania 1on1, na których mam okazję porozmawiać z programistami, aby poznać ich zdanie na temat naszej pracy i najzwyczajniej dowiedzieć się, co u nich słychać.

To tak w skrócie, jednak naprawdę trudno jest określić, jak wygląda mój typowy dzień, bo sytuacja zmienia się bardzo dynamicznie, w zależności od tego, gdzie akurat jestem najpilniej potrzebny. Zazwyczaj jednak wszystko sprowadza się do odblokowywania zespołu poprzez rozwiązywanie najbardziej strategicznych problemów, aby mógł on kontynuować swoją pracę bez niepotrzebnych dystrakcji.

W jakiej metodyce pracujecie? Na czym ona polega?

Wykorzystujemy to, co akurat dla nas skutecznie działa i nie komplikuje niepotrzebnie naszej pracy. Nauczyliśmy się, że zbyt duże formalizowanie tego, w jaki sposób pracujemy przyczynia się raczej do odciągania developerów od kodu, niż im pomaga.

Pracujemy w sposób zwinny, jednak unikamy dogmatów typu Scrum, ponieważ ilość energii, która jest potrzebna, aby poprawnie zaimplementować tego typu metodyki przewyższała zysk. Regularnie jednak korzystamy z Kanban Boarda, i to on jest naszym “centrum dowodzenia”. Metoda Kanban umożliwia nam prowadzenie asynchronicznej komunikacji z zachowaniem wysokiej transparentności naszej pracy.

Warto jednak dodać, że każdy zespół w CKSource wypracował własne podejście do pracy; to, co dobrze działa w naszym zespole, może nie sprawdzić się w innym. Nie oznacza to, że firma jest prowadzona w sposób chaotyczny, wręcz przeciwnie! Sposób pracy jest dostosowany indywidualnie do pracujących w zespole developerów – to przede wszystkim oni mają czuć się dobrze.

„Tworzenie edytora tekstowego w przeglądarce wymaga ogromnej wiedzy z zakresu specyfikacji HTML, działania API przeglądarkowego oraz znajomości wszelkich, nawet najdrobniejszych, różnic w implementacji specyfikacji W3C przez różnych dostawców przeglądarek internetowych.”

W CKSource powstało już wiele zaawansowanych produktów. Który z nich, twoim zdaniem, był najbardziej przełomowy, a który wymagał od was najwięcej pracy?

Myślę, że nie będzie zaskoczeniem, gdy odpowiem na oba pytania, że jest to cała linia naszego flagowego produktu, jakim jest CKEditor.

Pierwsza wersja edytora, CKEditor 3, została upubliczniona w 2003 roku (wtedy jeszcze pod bardziej kontrowersyjną nazwą, FCKEditor – od inicjałów założyciela firmy CKSource). Od tego czasu edytor przeszedł nieprawdopodobne zmiany – poprzez CKEditor 4 (2012), który nadal jest przez nas utrzymywany, kończąc na całkowitym przepisaniu produktu w formie CKEditor 5 (2018).

Wcześniej nie zdawałem sobie sprawy z tego, jak trudny może być tego typu projekt – zarówno pod względem technicznym, jak i biznesowym. Oczywiście nie mówimy tutaj o ustawieniu atrybutu contenteditable na elemencie blokowym oraz dodaniu kilku przycisków formatujących tekst – to zupełnie nie ten poziom developmentu. Zanim zacząłem pracę w naszej firmie miałem całkowicie nieprawidłowe wyobrażenie o tym, jak wygląda implementacja tak zaawansowanego produktu jak edytor tekstowy.

Tworzenie edytora tekstowego w przeglądarce wymaga ogromnej wiedzy z zakresu specyfikacji HTML, działania API przeglądarkowego oraz znajomości wszelkich, nawet najdrobniejszych, różnic w implementacji specyfikacji W3C przez różnych dostawców przeglądarek internetowych. Dochodzą do tego również tematy związane z dostępnością oraz ogólnie pojętym UX.

Na pewno nie pomaga również fakt, że cały codebase obu produktów (CKEditor 4 oraz CKEditor 5) jest otwarty. Wymaga to od developerów znacznie większej dbałości o tworzony kod, ponieważ on również staje się wizytówką produktu – choć to akurat cieszy mnie najbardziej.

W tej chwili CKEditor 5 to niezwykle zaawansowany projekt, który angażuje zarówno programistów tworzących kod edytora, jak i zespoły dostarczające rozwiązania w chmurze, a także narzędzia usprawniające obsługę zewnętrznych formatów (jak Word i PDF) oraz dedykowany zespół QA. Dochodzi do tego ogromna praca realizowana przez zespoły niezaangażowane bezpośrednio w tworzenie kodu, jednak również przyczyniające się do sukcesu produktu, jak Sales, Marketing czy Support.

Czy masz jakieś sprawdzone sposoby na zatrzymanie wartościowego pracownika w zespole?

W naszym zespole kładziemy duży nacisk na wspólne zaufanie oraz przyzwolenie na popełnianie błędów. Jak już wspominałem, błędy w IT są rzeczą naturalną, z którą musi się zmierzyć każdy programista, natomiast wyciąganie wniosków powinno polegać przede wszystkim na usprawnieniu naszej pracy. Ponadto każdy członek zespołu ma bezpośredni wpływ na to, czym się zajmujemy podczas regularnych spotkań backlog refinement, gdzie wspólnie priorytetyzujemy naszą pracę oraz decydujemy, co wpadnie do kolejnego sprintu.

Dzięki temu każdy z developerów ma poczucie realnego wpływu nie tylko na sposób wykonania projektu, ale również na to, co zostanie zaimplementowane i jak dany produkt ostatecznie będzie wyglądał. Myślę, że znacząco zwiększa to poczucie satysfakcji ze swojej pracy wszystkich zaangażowanych osób oraz bezpośrednio przyczynia się do minimalizacji rotacji w naszym zespole.

Dlaczego warto dołączyć do teamu CKSource?

Przede wszystkim ze względu na wysoką kulturę naszej pracy oraz niesamowitą atmosferę w firmie. Mamy wielu uzdolnionych ludzi, otwartych na współpracę i poszerzanie swoich kompetencji. Dołączając do CKSource, będziesz mieć okazję pracować nad ciekawymi, rozwojowymi projektami, często z otwartym kodem źródłowym i ludźmi chętnie dzielącymi się wiedzą.

W zasadzie każda osoba z firmowego software circle, z którą będziesz współpracować jest programistą – niezależnie od tego, czy jest to team leader, product owner czy CTO firmy. Dobrze rozumiemy znaczenie przeprowadzania testów, refaktoryzowania kodu oraz stosowania dobrych praktyk programistycznych w projektach.

Myślę, że każdy, komu zależy na rozwoju zawodowym oraz osobistym i kto chce mieć bezpośredni wpływ na tworzone przez CKSource rozwiązania świetnie odnajdzie się w naszej firmie. Niezdecydowanych zapraszam do przejrzenia repozytoriów na GitHubie – myślę, że nic tak nie przemawia do programistów, jak trochę dobrze napisanego kodu 🙂