Praca programisty a innowacje. Rozmawiamy o legacy code, awansach i rozwoju w IT.

Innowacyjne projekty high-tech potrzebują zarówno doświadczonych developerów jak również juniorów, którzy najczęściej uczą się tego, co akurat jest na topie. Czy stare technologie mogą się przydać, a praca w najnowszych technologiach jest jedyną drogą wdrażania innowacji? Jakie wyzwania dla programisty pojawiają się na każdym etapie rozwoju i jak się w nich odnaleźć, aby otrzymać upragniony awans? O tym wszystkim opowiada inżynier / developer z wieloletnim doświadczeniem - Michał (Bruno) Szulc.

Praca programisty a innowacje. Rozmawiamy o legacy code, awansach i rozwoju w IT.

1. W branży IT utarło się powiedzenie, że najszybszy sposób na podwyżkę to zmiana pracy. Czy wobec tego wieloletnia praca dla jednej firmy to realny cel, czy rzecz niemożliwa?

Wszystko zależy od osoby – dla mnie zawsze miało ogromne znaczenie by nie utknąć w miejscu: jednym projekcie lub jego aspekcie na lata. Miałem to szczęście, że zazwyczaj po 2-3 latach, kiedy dany obszar funkcjonalny znałem już na wylot, zawsze pojawiało się coś nowego, co wyrywało mnie ze stagnacji i umożliwiało rozwój. Wobec tego, mimo, że w każdej z firm, z którą się związałem, pracowałem po kilka lat, nie nazwałbym tego staniem w miejscu. W ten sposób: wychodząc ze strefy komfortu, szczególnie przy zmianie branży rozwijamy się nawet w ramach jednej firmy.

2. Mówiąc o firmach, w których pracowałeś - jaka była Twoja ścieżka kariery, czym zajmujesz się zawodowo i jaki jest Twój tech stack?

Swój zawód nazwałbym: programista systemów wbudowanych.

Zaczynałem w krakowskim oddziale Motoroli, pracując nad oprogramowaniem Operation & Maintenance stacji bazowych CDMA, później LTE. Kolejnym obszarem, w którym realizowałem się, już pracując dla ALTEN Polska była automatyka przemysłowa. Później była praca dla przemysłu samochodowego. Nowością była dla mnie przede wszystkim tematyka Functional Safety i związana z nią praca w bardzo sformalizowanym środowisku. Jednym z moich ostatnich stanowisk była rola architekta oprogramowania.

Właściwie od początku mojej kariery zawodowej obracam się w tematach, które leżą pomiędzy hardware a software: embededd software i firmware bazujące na C lub C++.

3. Jakie warunki powinien Twoim zdaniem spełnić pracodawca, by stworzyć dla developerów dobrą przestrzeń do rozwoju kompetencji?

Oprócz programów rekrutacji wewnętrznej, które, jeśli są dobrze prowadzone, pozwalają developerom na elastyczny rozwój, bardzo ważna jest otwartość pracodawcy na rozmowę i negocjacje, jasne mówienie o możliwościach, czasami nawet fundowanie developerom szkoleń związanych z ich wymarzonymi kierunkami rozwoju.

Istnieje silne przekonanie – sam myślę, że jest w nim ziarno prawdy - że nowi pracownicy dostają na start lepsze warunki finansowe niż ci, którzy w firmie są już o kilku lat. Stąd właśnie wzięło się powiedzenie, o którym już wspomnieliśmy, że najszybszą drogą awansu w IT jest zmiana pracy. Myślę, że nie musi tak być, jeśli pracodawca dba o pracowników z długim stażem.

4. Jak jest u Twojego pracodawcy?

Zaczynałem pracę w ALTEN, kiedy krakowski oddział firmy był niewielki i od początku czułem przyjazną atmosferę. Dzisiaj pracuje w nim ponad 300 osób, a klimat w biurze się nie zmienił i nie mam poczucia anonimowości, jak to bywa w wielkiej korporacji. Zespół jest integrowany w taki sposób, że nawet jeśli pracujemy dla różnych klientów to czujemy, że jesteśmy jednym teamem.

Chwali się też elastyczność, jeśli chodzi o warunki umowy i szybkość realizacji dodatkowych ustaleń, czy to finansowych czy związanych z potrzebnym nadprogramowym urlopem. Firma wspiera swoich pracowników na różnych polach - pamiętam, gdy w którymś momencie naszej współpracy pojawiła rozbieżność interpretacji nowych regulacji prawnych, która mogłaby potencjalnie zaszkodzić pracownikom na umowach B2B. ALTEN zapewnił pracowników, że mogą być spokojni o swoje zatrudnienie. Takie rzeczy sprawiają, że w firmie po prostu chce się zostać.

5. Co Twoim zdaniem jest kluczowe by w branży IT awansować z Junior Developera na Regulara, a docelowo by zostać Seniorem/ Leadem?

Myślę, że najważniejszym elementem jest rozpoznawalność, którą można zbudować na wiele różnych sposobów. Trzeba zdobywać wiedzę i doświadczenie, dzięki angażowaniu się w projekty i intensywnej nauce, także poprzez dopytywanie współpracowników. Warto się nią później dzielić i znajdować czas na wsparcie innych, na początku w zespole, a później też w szerszym gronie. Dzięki temu zyskuje się opinię osoby, która wie i może pomóc.

Kolejna rzecz: nie należy bać się tematów trudnych, bo właśnie tam można się wykazać. Pamiętam, jak zdarzało mi się wyjeżdżać z klientem lub dostawcą na trudne delegacje. Dzięki podejmowaniu się takich zadań można zyskać rozpoznawalność i zaufanie przełożonych, które w dłuższej perspektywie przełoży się na większą odpowiedzialność i awans.

A zawsze warto dbać o odpowiedni “support” w zespole, który nawet jeśli nie jest na pierwszej linii frontu, w danym momencie może nam bardzo pomóc w trudniejszych momentach. Dotyczy to przede wszystkim starszych inżynierów - moim zdaniem powinniśmy być postrzegani, jako ci, których chętnie służą pomocą i podzielą się z innymi wiedzą. Nawet jeśli wymaga to od nas dodatkowego sprawdzenia lub doczytania.

6. W swojej pracy w ALTEN realizujesz projekty z różnych branż. Jak ważna jest dla Ciebie elastyczność i umiejętność łączenia różnego rodzaju technologii i wiedzy oraz szerokiego spojrzenia na realizowany projekt czy produkt?

Wejście do nowej branży czy domeny wymaga przyjęcia każdorazowo nowego podejścia. Staram się to robić z dużą dozą pokory, bo chociaż język i składnia pozostają te same, zmienia się sposób ich wykorzystania i podejście. Dla przykładu - zaproponowałem jednemu z klientów z branży motoryzacyjnej rozwiązanie znane mi z innej branży, jednak szybko okazało się, że pomysł nie nadaje się do wykorzystania. Na moje pytanie, dlaczego nie, usłyszałem odpowiedź, która dla pozostałych osób zebranych na spotkaniu była oczywista: “to szybko wyczerpie baterię”.

Mówiąc o elastyczności, myślę, że musimy ją rozumieć w ten sposób, że nie zawsze będziemy zajmować się takim kodem produkcyjnym, fragmentem produktu albo środowiskiem, którym chcielibyśmy się zajmować. Fantastycznie jest spojrzeć na portfolio klienta i pomyśleć, że gdzieś tam kręci się kawałek mojego kodu, ale lwia część pracy programisty to coś, czego nie widać - testy, środowisko, inwestygacja znalezionych problemów itd.

7. Czy Twoim zdaniem warto uczyć się starszych technologii i języków programowania? Do czego może przydać się ich znajomość?

W branżach z którymi się zetknąłem, jeśli kod bazuje na dawno wykutych modułach, nie ma co spodziewać się nowości. C++11 powoli staje się standardem, jednak też nie w każdej branży i nie wszystkie jego mechanizmy. Szybkie wdrażanie nowości możliwe jest przede wszystkim w świecie software, na niższych poziomach programowania jest trudniej.

Ograniczeniem stosowania nowinek programistycznych jest na przykład hardware, na którym nasz program ma działać, narzędzia, którymi się posługujemy - w szczególności dedykowane kompilatory dla niektórych platform, a także wiedza programistów nauczonych starszych standardów i mających w nich doświadczenie. Wszystko to sprawia, że wdrażanie nowości może być dla projektu ryzykowne.

Kolejnym argumentem za znajomością także starszych języków programowania jest fakt, że spotkamy się z sytuacjami, w których klient końcowy będzie wymagał konkretnych rozwiązań i norm, a spełniające je narzędzia będą działały w oparciu o właśnie te “starsze” języki.

Praca programisty a innowacje. Rozmawiamy o legacy code, awansach i rozwoju w IT.

8. A praca tylko z najnowszymi technologiami i językami programowania? Jakie może mieć wady, zalety, co może być przeszkodą?

Z drugiej strony, jeśli znamy najnowsze standardy programowania, najprawdopodobniej dobrze damy sobie radę także w środowisku, w którym nie możemy ich użyć, bo te starsze rozwiązania stanowiące bazę dla nowych też pewnie znamy, albo szybko je “ogarniemy”. Choć to może trochę boleć, że nie możemy skorzystać z naszych ulubionych kontenerów.

Mam wrażenie, że język w dużej mierze, nawet w branżach innowacyjnych, pozostaje ten sam. Być może dlatego, że obracam się w tematach C i C++, a nie na przykład JAVA i Rust. Widzę, że pojawiają się ciekawe elementy, jak np. bardzo wydajny i bezpieczny μC Infineona, czy nowiutki ARM Cortex, gdzie projekt przewiduje uruchomienie na jednym wirtualnym core Linuxa na drugim vxWorksa, a na jeszcze kolejnym Windowsa. Jako programistę systemów wbudowanych bardzo mnie to cieszy.

Czy widzę tu jakieś przeszkody? Raczej sporo wyzwań, które przy odpowiednim zaangażowaniu na pewno uda się przejść.

9. Jak to wygląda z legacy code – stanowi dla Ciebie realną wartość, działającą i dającą efekty biznesowe czy ciągły problem do rozwiązania?

Moim zdaniem pomysł napisania wszystkiego od nowa, z którym czasami się spotykam w kontekście Legacy Code, to mrzonka. Ten zastany czy odziedziczony kod to coś, z czym po prostu musimy sobie radzić. Często nie jest taki zły i jakoś działa. Oczywiście niektóre fragmenty będą wymagać przepisania, wtedy musimy taką decyzję podjąć jako zespół i wynegocjować na to czas, pokazując możliwe zyski. Jest to możliwe tylko jeśli utrzymanie danego fragmentu istniejącego kodu faktycznie jest zbyt kosztowne. A to oznacza, że albo był słabo napisany, albo obrósł tak, że strach cokolwiek w nim zmieniać. To dla nas ważne sygnały, który nie powinno się bagatelizować, jednak w większości przypadków zadziała zasada “lepsze wrogiem dobrego”. Po kilku latach fragment, który na świeżo wyglądał tak pięknie, zaczyna być kodem do narzekania, bo ciągle przybywa nowych przypadków, których wtedy nie przewidzieliśmy i prędzej czy później refaktor będzie nieunikniony.

10. Co doradziłbyś młodym programistom po raz pierwszy mierzącym się z kodem dziedziczonym? Jak do tego podejść?

Pamiętajcie, że kod zastany to nie zawsze zły kod. Jeśli jest dobry – po prostu go nie popsujmy. A co do tego gorszego... cóż. Na pewno wymaga cierpliwości, a zanim do niego podejdziemy warto porozmawiać ze współpracownikami, pomocne będą też systemy kontroli wersji lub historia zmian. Wtedy może uda się uniknąć rzucania myszką ze złości.

Na pewno nie polecałbym wprowadzania przełomowych zmian, jeśli nie zostały wcześniej zaplanowane. Odpowiedni plan i bufor czasowy są niezbędne, bo takie zadania zawsze zabierają więcej czasu niż początkowo założymy. Na przykład, jeśli do danego kodu istnieją testy jednostkowe, to większe przeróbki kodu produkcyjnego oznaczają też sporo zmian także w nich.

Tym, co mogę doradzić każdemu to stosowanie dobrego skauta (chociaż w Polsce raczej dobrego harcerza) opisanej przez Roberta C. Martina w książce “Czysty Kod”: zostawmy zawsze ciut lepiej niż zastaliśmy - dodajmy lepszą nazwę, jakiś komentarz. Wiadomo, że i sto linii komentarza nie zastąpi lepszego kodu, ale jeśli nie chcemy nic w nim zmieniać, ułatwmy życie kolejnej osobie, lub nawet samemu sobie za jakiś czas.

Rozmówca: Michał (Bruno) Szulc – Senior Embedded Software Developer w ALTEN Polska

Zobacz również: Jak zostać programistą bez studiów.