10 lat temu użytkownicy aplikacji byli mniej wymagający. Wywiad z Maciejem Galosem

Jak z perspektywy mobile developera z dziesięcioletnim doświadczeniem wygląda rynek pracy? Co przez dekadę zmieniło się w tej branży, a co pozostało takie samo? Na te i na wiele innych pytań odpowiedział Maciej Galos, Senior Android Developer w SpotOn.

Jak z Twojej perspektywy wygląda rynek pracy dla mobile developerów? Łatwo znaleźć pracę?

Rynek cały czas się zmienia. W tym momencie jesteśmy w czasie lekkiego kryzysu/dołka w branży IT i ofert pracy jest zdecydowanie mniej niż np. rok temu. Można też zauważyć, że widełki w ogłoszeniach od roku praktycznie nie rosną. Czy łatwo znaleźć pracę? Powiedziałbym, że to zależy od doświadczenia i umiejętności. Wykwalifikowani specjaliści nadal są potrzebni i raczej się nie nudzą. Moim zdaniem w tym momencie szczególnie trudno jest załapać się na staż czy dostać pierwszą juniorską posadę.

W ostatnim roku obserwowaliśmy, jak z branży technologicznej odpływa kapitał, czego skutkiem było zamrażanie budżetów firm, lub nawet cięcia etatów, a startupy miały większe trudności z pozyskaniem finansowania niż jeszcze jakiś czas temu. Wydaje mi się, że najtrudniejszy czas był wiosną tego roku i najgorsze za nami. Od jakiegoś czasu liczba ofert powoli rośnie, obserwuję też trochę większy ruch na platformie LinkedIn. To jednak nadal daleki poziom od tego sprzed dwóch lat, gdzie liczba ofert była ogromna, rekruterzy wręcz walczyli o kandydatów, a widełki rosły praktycznie z miesiąca na miesiąc.

Co było “standardowym zestawem umiejętności” dla mobile developera, kiedy zaczynałeś?

Są pewne uniwersalne umiejętności, takie jak: logiczne myślenie, znajomość algorytmów i struktur danych, znajomość wzorców projektowych czy umiejętność pisania czystego i testowalnego kodu oraz umiejętności komunikacyjne. Umiejętności te zawsze były cenione i są ważne niezależnie od czasu czy technologii. Kiedy 10 lat temu zaczynałem swoją przygodę z aplikacjami mobilnymi, oprócz wyżej wspomnianych umiejętności w przypadku Android Developera, wystarczyła znajomość Javy, Android SDK (który zresztą był dużo mniej rozbudowany niż teraz), wiedza na temat, w jaki sposób wspierać różne rozmiary ekranów, czy różne tłumaczenia aplikacji. Warto było też wiedzieć, w jaki sposób coś pobrać/wysłać na serwer, czy zapisać w lokalnej bazie danych. Aplikacje kiedyś były dużo prostsze niż teraz, a ich użytkownicy dużo mniej wymagający.

Jak ten zestaw wygląda dzisiaj?

Nadal uważam, że najważniejsze są te uniwersalne umiejętności, bo technologia to tylko narzędzie. A technologia zmieniła się bardzo przez ostatnie lata. W natywnym kodowaniu na Androida, Javę wyparł Kotlin, który moim zdaniem jest zdecydowanym gamechangerem, ale to “temat rzeka” zasługująca na osobny artykuł. Powstało wiele bibliotek czy frameworków, jak np. Hilt lub Koin – które załatwiają nam temat wstrzykiwania zależności. Retrofit znacznie ułatwia komunikację REST z serwerem. Room jest naprawdę świetnym ORM’em. Ewolucje przeżyliśmy też, jeżeli chodzi o wzorce architekturalne aplikacji, zaczynając od God Activity, poprzez MVC, MVP, MVVM aż do MVI. Java’owe wątki zostały zastąpione przez reaktywne strumienie czy korutyny.

W niedawnym czasie przeżyliśmy też rewolucję w kontekście sposobu tworzenia interfejsu użytkownika. Standardowy dla Androida XML jest powoli zastępowany przez Jetpack Compose. Developerzy mają również dużo więcej narzędzi do analityki, czy obserwowania stabilności produkcyjnej aplikacji. Dzisiaj aplikacje są dużo bardziej skomplikowane niż kiedyś, a użytkownicy dużo bardziej wymagający. Aplikacje muszą być niezawodne, szybkie oraz miłe dla oka. Kiedy zaczynałem, mało kto zwracał uwagę na aspekt UI czy UX, natomiast teraz jest to bardzo ważna kwestia.

Dzisiaj od Android Developera, oprócz znajomości Javy/ Kotlina i Android SDK wymaga się znajomości popularnych bibliotek i frameworków, umiejętności tworzenia zaawansowanych interfejsów użytkownika oraz animacji. Mobile Developer musi też wiedzieć, w jaki sposób optymalizować zasoby, tak by tworzona aplikacja nie zużywała za dużo pamięci czy nie wyczerpywała baterii. Co więcej, musimy umieć zadbać także o prywatność oraz bezpieczeństwo użytkownika.

Bardzo pomocna jest także wiedza z zakresu automatyzacji. Zautomatyzowanie procesów takich jak uruchamianie testów jednostkowych i statycznej analizy kodu podczas tworzenia pull request’u, czy zautomatyzowanie release’owania aplikacji pozwalają zaoszczędzić wiele czasu. Inną cenną umiejętnością jest znajomość technologii cross-platformowych, takich jak np. Kotlin Multiplatform, które pozwalają współdzielić części kodu pomiędzy Androidem i iOS, co przyśpiesza i obniża koszt wytworzenia aplikacji na obie platformy. Ostatnio też eksperymentuję trochę z pair-programmingiem, gdzie moim partnerem zamiast człowieka jest jeden z popularnych ostatnio modeli językowych AI. To bardzo ciekawe doświadczenie i myślę, że mocno zmieni sposób pracy developerów w najbliższych latach.

W jaki sposób dbasz o wydajność aplikacji?

Może zacznę od najbardziej ogólnych i oczywistych, ale bardzo ważnych rzeczy: unikam zagnieżdżonych pętli i rekurencji, wykorzystuję asynchroniczne operacje i wątki do oddzielania operacji UI od operacji długotrwałych. Uważnie zarządzam pamięcią; wykorzystuję narzędzia umiejące wykryć wycieki pamięci oraz analizuje pod tym kątem kod, który tworzę. Jeżeli chodzi o zasoby graficzne, dbam o to, by były rozmiarem i formatem dostosowane do różnych urządzeń i wielkości ekranu, wykorzystuję formaty kompresji tam, gdzie to możliwe – używam grafik wektorowych.

Staram się ograniczać ilość transferowanych siecią danych do niezbędnego minimum, pozwalającego spełnić logiczne wymagania biznesowe danej funkcjonalności. Monitoruję i minimalizuję użycie energii przez aplikację, szczególnie podczas korzystania z komponentów takich jak GPS czy Bluetooth. W przypadku konieczności wykonania jakichś operacji w tle korzystam z dedykowanych do tego rozwiązań, które pod kątem wydajności optymalizuje sam system Android.

Przykładem jest np. WorkManager, który zbiera z różnych aplikacji żądania wykonania operacji w tle (jak np. synchronizacja danych), aby wybudzić telefon raz, wykonać wszystkie zaplanowane zadania i ponownie uśpić telefon. Jest to dużo bardziej efektywne pod kątem zużycia baterii, niż np. wybudzanie telefonu, aby wykonać te operacje dla każdej aplikacji z osobna. Jest też wiele dobrych praktyk, specyficznych dla platformy Android, których należy przestrzegać. Przykładem może być; w przypadku list użycie RecyclerView czy LazyColumn/LazyGrid (dla Compose), które pozwalają efektywnie zarządzać widokami i minimalizują zużycie pamięci. Jest to natomiast temat znacznie bardziej obszerny, który nie sposób wyczerpująco opisać w kilku zdaniach.

Dla mnie osobiście aspekt wydajności aplikacji jest bardzo powiązany z kwestią UX. Dlatego uważam, że oprócz ogólnych dobrych praktyk, bardzo ważne jest projektowanie rozwiązań dostosowanych do konkretnego przypadku, który musimy obsłużyć, tak by były one zarówno wydajne, jak i dawały wartość użytkownikowi. Może podam przykład, by lepiej zobrazować, o co mi chodzi.

Większość z nas zna i korzysta z aplikacji Spotify. Kiedy wpisujemy w wyszukiwarce pierwsze litery tytułu muzycznego, którego mamy ochotę posłuchać, Spotify już w momencie wyszukiwania buforuje kilka najbardziej prawdopodobnych dla naszego zapytania rezultatów. Dzięki temu rozwiązaniu użytkownik, klikając na znaleziony utwór, słyszy muzykę natychmiast, bez żadnego opóźnienia.

Dla wielu początkujących zaskoczeniem jest to, że łatwiej tworzy się aplikację, niż później utrzymuje się ją i rozwija. Zgadzasz się z tym stwierdzeniem? Co zazwyczaj jest wyzwaniem, jeśli chodzi o utrzymanie aplikacji.

Tak, zgadzam się z tym stwierdzeniem. Tworzenie aplikacji to jedno z bardziej widocznych i ekscytujących etapów w cyklu życia projektu, ale utrzymanie i rozwijanie aplikacji to proces, który wydaje się w większym stopniu wymagający. W miarę rozwoju projektu coraz większą trudnością jest zarządzanie kodem źródłowym, który z każdą kolejną funkcjonalnością staje się bardziej złożony. Utrzymywanie porządku w kodzie, zapewnienie spójności i czytelności, a także unikanie tzw. „długu technicznego” jest niewątpliwie jednym z wyzwań.

W miarę rozwoju aplikacji także testowanie staje się bardziej złożone. Konieczne jest przeprowadzanie testów jednostkowych, testów integracyjnych i testów wydajnościowych, aby zapewnić, że aplikacja działa poprawnie. Aplikacje często korzystają z różnych bibliotek i zależności. Utrzymanie tych zależności, śledzenie ich aktualizacji i rozwiązywanie konfliktów między nimi również czasem bywa trudne.

Nowe wersje systemów operacyjnych i różnice w urządzeniach mobilnych mogą wprowadzać niezgodności i problemy z działaniem aplikacji. Konieczne jest dostosowywanie aplikacji do nowych platform i urządzeń. Kluczowy również jest temat bezpieczeństwa i ochrony danych. Wymagane jest regularne aktualizowanie aplikacji w celu usuwania luk bezpieczeństwa i utrzymywania zgodności z przepisami o ochronie danych.

Co w Twoim przekonaniu jest największym wyzwaniem w pracy mobile developera?

Myślę, że są to ciągłe zmiany technologiczne. Branża mobilna rozwija się bardzo dynamicznie, co oznacza, że developerzy muszą być na bieżąco z najnowszymi technologiami i frameworkami, aby tworzyć aplikacje zgodne z najnowszymi trendami. Zarówno Google, jak i Apple (regularnie wydają nowe wersje swoich systemów operacyjnych. Nowe funkcje, zmiany interfejsu użytkownika i poprawki bezpieczeństwa wymagają dostosowania istniejących aplikacji. Rozwijają się także popularne frameworki i narzędzia.

Developerzy muszą śledzić te zmiany i decydować, które narzędzia są najbardziej odpowiednie do ich projektów. Nowe urządzenia mobilne często wprowadzają innowacje w dziedzinie sprzętu, takie jak lepsze aparaty, czujniki czy możliwość obsługi rzeczywistości rozszerzonej (AR) czy wirtualnej (VR). To otwiera nowe możliwości, ale także wymaga dostosowania aplikacji do tych nowych funkcji. Wszystko to sprawia, że dużym wyzwaniem jest pozostanie na bieżąco, jednak jest to dla mnie równocześnie fascynujące, ponieważ cały czas się rozwijam. Jest to też czynnik, który niejako może nas uchronić przed wypaleniem zawodowym, bo ciągle robimy coś nowego, lub w inny sposób niż dotychczas.

Pracujesz z klientami z całego świata, a to znaczy, że stykasz się z wieloma kulturowymi barierami. Opowiedz o najciekawszych.

Do tej pory pracowałem z klientami z Polski, Europy Zachodniej (Niemcy, Holandia, Wielka Brytania) oraz USA. Jeżeli chodzi o bariery kulturowe w moim przypadku, to jedną z nich była nieznajomość języka niemieckiego, podczas pracy z niemieckim klientem. Mimo tego, że osoby w zespole po stronie klienta mówiły po angielsku, to niechętnie podchodziły do zmiany całej komunikacji na język angielski. Z tego, co słyszałem od znajomych z branży, większość klientów z Niemiec oczekuje od developerów, że będą znać ich ojczysty język. Była to dla mnie okazja do nauki niemieckiego, jednak projekt trwał zbyt krótko, by wyszło z tego coś sensownego.

W przypadku pracy z klientami ze Stanów barierą może być różnica czasu, która dla zachodniego wybrzeża wynosi aż 9 godzin. Dla niektórych osób może być to problematyczne, ponieważ czasem trzeba tak sobie poukładać dzień, aby być dostępnym wieczorem i dołączyć na spotkanie. Interesujące są też różnice w podejściu do współpracy klientów w zależności od kraju.

Osobiście, najlepiej pracowało mi się z klientami holenderskimi. Współpraca z nimi jest bardzo poukładana. Są cierpliwi, wykazują się zrozumieniem, dbają o jakość. Oczywiście nie chcę generalizować, ale zauważyłem, że klienci z USA mają bardziej kapitalistyczne podejście. Najważniejsza dla nich jest wartość, którą możemy dostarczyć tu i teraz. Czas to pieniądz, więc oczekują oni szybkich rezultatów.

Współpracując z klientem ze Stanów, developer musi się spodziewać, że będzie musiał poświęcić więcej energii na wytłumaczenie klientowi, dlaczego niektóre rzeczy zajmą daną ilość czasu, jeżeli nie chcemy iść na kompromisy względem jakości.

Dużo natomiast zależy też od konkretnej firmy. Obecnie pracuję jako Senior Android Developer w SpotOn. Jest to amerykański startup technologiczny, lecz model współpracy z biznesem przypomina bardziej ten znany mi z firm z Zachodniej Europy, co bardzo mi odpowiada. Decydenci wykazują się dużym zaufaniem do developerów, dzięki czemu czuję, że to, co robię ma znaczenie.

Co dało Tobie największego boosta w karierze? Być może był taki projekt, zadanie.

Myślę, że były dwa takie przełomowe momenty. Pierwszy to moja pierwsza praca, gdzie miało miejsce zderzenie mojej teoretycznej, podręcznikowej wiedzy, z tym, jak w praktyce wygląda praca nad komercyjnym produktem. Większość rzeczy była dla mnie wtedy nowa, więc bardzo szybko się uczyłem. Miałem też szczęście, ponieważ trafiłem na świetnych ludzi w moim zespole. Byli doświadczonymi developerami, z bardzo dużą wiedzą, którą chętnie się dzielili.

Kolejny przełomowy moment zdarzył się 4 lata temu, kiedy zmieniłem pracę i zacząłem pracować nad greenfieldowym, fascynującym projektem. Była to aplikacja mobilna, służąca do sterowania zaawansowanym aparatem słuchowym. Standardowe aparaty słuchowe są dość duże i widoczne. To urządzenie było bardzo innowacyjne, ponieważ było na tyle małe, że w całości mieściło się w uchu. Z racji rozmiarów urządzenia, nie zmieścił się w nim moduł Bluetooth. Jako że każdy aparat słuchowy posiada mikrofon, inżynierowie wpadli na pomysł, że komunikacja z tym urządzeniem, będzie przebiegać poprzez wysyłanie ultradźwiękowych komend z telefonu.

Komunikacja ta była jednostronna, więc bardzo dużym wyzwaniem było zapewnienie, aby stan, który aplikacja prezentuje użytkownikowi, odpowiadał dokładnie stanowi aktualnych ustawień aparatu słuchowego. Praca nad tym projektem zmuszała niejednokrotnie do nieszablonowego myślenia i wykraczania poza ramy tego, co standardowo robi Mobile Developer. Miałem okazję też wtedy pracować ze świetnymi developerami – Maćkiem Tomczyńskim, Filipem Radoniem oraz Danielem Rodakiem, od których również bardzo dużo się wtedy nauczyłem i których z tego miejsca serdecznie pozdrawiam.

Na koniec, więcej uczy dziesięć krótkich projektów niż jeden, nad którym pracujesz kilka lat?

Tworzenie wielu krótkich projektów może dostarczyć szeroką gamę doświadczeń w krótkim czasie. Można poznać różne technologie, narzędzia i dziedziny. Jest to szczególnie przydatne na początku kariery, kiedy chcemy zdobyć szeroką wiedzę. Przeskoczenie do nowego, krótkiego projektu, niewątpliwie wpływa również pozytywnie na doświadczonego programistę, ponieważ jest to świetna okazja do spróbowania nowej technologii czy podejścia.

Pracując nad jednym projektem przez dłuższy czas, mamy okazję zrozumieć go wnikliwie od początku do końca. Możemy lepiej poznać jego architekturę, przemyśleć jego długoterminowe cele i doskonalić swoje umiejętności w zarządzaniu kodem źródłowym. Możemy rozwijać swoje umiejętności komunikacyjne i zdolność do współpracy z innymi członkami zespołu. Dłuższy projekt może dać również okazję do zakorzenienia się w danej branży lub rynku, co może prowadzić do większych możliwości zawodowych.

Zarówno krótkie projekty, jak i długoterminowe projekty mają swoje zalety. Jeżeli od dłuższego czasu pracujemy zawodowo nad jednym projektem – świetnym sposobem, by być na bieżąco z nowinkami jest tworzenie prywatnych, pobocznych projektów, czy to do szuflady, czy jako open source.

---

Maciej Galos. Senior Android Developer w SpotOn. Android Developer z wieloletnim doświadczeniem, ponad wszystko ceniący logiczne myślenie. Entuzjasta Kotlina i czystej architektury. Prywatnie miłośnik psów, sportów motorowych i górskich wędrówek.