Życie programisty – IT od środka

Cześć! Dzisiaj wpis trochę inny niż zazwyczaj. Chciałbym poruszyć temat nie stricte techniczny i spróbować opowiedzieć Wam na czym w ogóle polega praca w IT, z naciskiem na tę programistyczną. Artykuł skierowany jest raczej do osób, które chciałyby bliżej poznać branżę – być może z ciekawości, a być może rozważając przyszłą ścieżkę kariery.

Zespół

Jedną z popularniejszych profesji związanych ze światem programowania jest ta programisty (lub programistki). Aczkolwiek nie samymi programistami realizuje się projekty 😉 Oprócz nich, w typowym środowisku informatycznym możemy spotkać:

• Testerów
• Dev Opsów
• Product Ownerów
• Architektów
• Scrum Masterów

Dwie ostatnie pozycje w tym zestawieniu są odrobine specyficzne – co wyjaśnię za moment. Oczywiście ta lista nie wyczerpuje wszystkich ról zaangażowanych w wytwarzanie oprogramowania. Mamy jeszcze UX Designerów, Administratorów, Inżynierów Wsparcia, a w zależności od wewnętrznej organizacji danej firmy Product i Project Managerów, Analityków, Service Delivery Managerów, itd. Dokładne rozróżnienie pomiędzy poszczególnymi rolami jest mocno płynne i zależy od konkretnego przedsiębiorstwa, jednak zestaw wymieniony powyżej daje dobry pogląd na to, jakie są główne kierunki rozwoju w IT i z kim współpracują programiści. Dokładne opisanie na czym polega praca Testera czy DevOpsa to temat na przynajmniej kilka artykułów, postaram się jednak w dużym skrócie przybliżyć poszczególne koncepcje. 

Jeżeli spojrzelibyśmy na powyższe stanowiska, z perspektywy miejsca zajmowanego przez nie w świecie Biznesowo-Technologicznym, to wyglądałoby to mniej więcej w ten sposób:

Developer

Czyli inaczej programista. To on implementuje poszczególne funkcjonalności. Posiada umiejętności techniczne pozwalające mu pisać programy, jednocześnie w pewnym stopniu musi rozumieć kontekst biznesowy analizowanego zagadnienia. W typowym zespole projektowym jest to zazwyczaj najliczniej reprezentowana grupa. Przez niektórych postrzegany jako maszynka zamieniająca kawę w kod (chociaż podobno są tacy, którzy nie piją kawy 😉 ). Szczegółami jego pracy zajmiemy się w dalszej części artykułu.

Tester

Jak wiadomo ludzie popełniają błędy. Programiści nie są w tej materii wyjątkiem i błędy w oprogramowaniu to nic zaskakującego. Testerzy upewniają się, że aplikacja spełnia odpowiednie wymagania jakościowe i działa tak jak powinna. Ich praca nie ogranicza się tylko do szybkiego klikania przycisków i wpisywania nieoczekiwanych wartości w pola formularzy. Testerzy, będąc z jednej strony inżynierami technicznymi, z drugiej działając stosunkowo blisko świata biznesu, pomagają w określeniu wymagań dotyczących systemu, przygotowują uporządkowane scenariusze testowe i weryfikują ich spełnienie. Realizują testy regresji zapobiegając psuciu istniejącej funkcjonalności. Optymalizują wykorzystanie dostępnego czasu, automatyzując testy najważniejszych funkcji systemu. Często weryfikują również takie cechy systemu jak wydajność czy bezpieczeństwo.

DevOps

Samo napisanie programu nie wystarczy żeby ktoś poza programistami mógł go efektywnie używać. Niezbędne jest zapewnienie użytkownikom dostępu do niego. W tym celu oprogramowanie umieszczane jest w odpowiednim środowisku. Prostym przykładem może być strona internetowa. Użytkownik otwiera w przeglądarce adres i może używać dostarczanych przez nią funkcji (np. wyszukać informacje, zalogować się). Jednak “pod spodem” znajduje się nie tylko sama aplikacja (kod napisany przez programistów), ale również serwer, baza danych, która przechowuje informacje, odpowiednie usługi sieciowe umożliwiające dostęp do strony, itd. Dbanie o środowisko – tzw. infrastrukturę systemu to zadanie DevOpsa. Zajmuje się on również wieloma zagadnieniami związanym z bezpieczeństwem systemu, jego wdrożeniem i późniejszym monitoringiem.

Product Owner

Dosłownie Właściciel Produktu, czyli osoba decydująca w jaki sposób ma być rozwijany Produkt, nad którym pracuje cały zespół. Product Owner rozumie domenę biznesową w której się porusza. Może to osiągnąć np. poprzez analizowanie jej wspólnie z klientem. Pracuje z osobami zainteresowanymi rozwiązaniem po stronie Biznesu nad określeniem celów, priorytetów i kierunku działań. Konkretyzuje i dokumentuje wymagania dotyczące aplikacji. Jest odpowiedzialny za określenie wizji oraz za wartość którą będzie przynosił Produkt. W pewien sposób łączy ze sobą świat Biznesu i Technologii. Z jednej strony rozmawia z ludźmi Biznesu, językiem celów i wymagań biznesowych. Z drugiej strony przekazuje te informacje do zespołu, tłumaczy cele, priorytety i wymagania, językiem biznesowo-technicznym.

Architekt

Rola ta jest specyficzna, gdyż w mojej opinii powinna być poprzedzona rolą Developera. W rzeczy samej, Architekt to również Developer. W branży słynne są przykłady nie programujących Architektów którzy z “wieży z kości słoniowej” zsyłają swoje decyzje projektowe. Nie tylko w branży IT problematyczne bywają decyzje podejmowane przez osoby, które mają nikłe doświadczenie w danym temacie, a ewentualne rozważania na ten temat odłożę na oddzielny artykuł 😉 Tak więc Architekt-Developer zanim nim zostanie najpierw jest “tylko” Developerem. Dlaczego? Otóż rola ta wymaga posiadania dość sporego doświadczenia. Co ważne ścieżka od Developera do Architekta nie jest jedynym możliwym kierunkiem rozwoju programisty. Na naszym obrazku Architekt znajduje się głównie po stronie Technologii jednak trochę wychodzi na obszar Biznesu. Wynika to z faktu, iż patrzy on na system z nieco wyższego punktu widzenia niż Developer. Podejmuje decyzje dotyczące ogólnego kształtu systemu (jego architektury) na podstawie wymagań biznesowych klienta. W celu dobrania odpowiednich rozwiązań technologicznych musi znać spektrum dostępnych możliwości, wady i zalety poszczególnych opcji. Jednocześnie powinien dobrze rozumieć cele i ograniczenia biznesowe klienta.

Scrum Master

Na obrazku rola ta znalazła się w dwóch miejscach. Scrum Master jest osobą odpowiedzialną za proces wytwarzania oprogramowania. Dba o dobrą komunikację, monitoruje i usprawnia działanie bieżącego procesu, edukuje zarówno osoby techniczne jak i Biznes. Usuwa przeszkody organizacyjne uniemożliwiające rozwój systemu. Dostarcza metryk i analiz opartych na danych. Dzięki nim łatwiejsze staje się podejmowanie decyzji odnośnie priorytetów i terminów. Scrum Master pomaga wszystkim, by mogli realizować wspólne cele z jak największą efektywnością. Pracuje zarówno z zespołem technicznym jak i Biznesem. W projektach informatycznych, w których ostateczny produkt jest niematerialny, komunikacja i wzajemne zrozumienie oraz dbałość o proces jest bardzo ważnym i niestety czasami niedocenianym wyzwaniem.

Dla pełnego wyjaśnienia zaznaczę, że role Product Ownera oraz Scrum Mastera pochodzą z metodyki Scrum i dokładny ich opis można znaleźć w Scrum Guidzie. Pomimo to, wiele firm stosuje tego rodzaju nazewnictwo również w nie do końca Scrumowych procesach. Jeżeli jesteś osobą zaznajomioną z ekosystem IT polecam sięgnąć do definicji tych ról i samego procesu Scrumowego (sam jestem jego wielkim fanem 😉 ). Niezależnie od tego na jakim poziomie zaawansowania jesteś, pamiętaj, że w tym artykule celowo użyłem pewnych uproszczeń, a role te przedstawiłem z punktu widzenia tego, jak zazwyczaj w praktyce są realizowane.

Backend czy Frontend? A może Mobile?

W kontekście programistów można spotkać się z tego typu określeniami. Czym zatem różni się programista backendowy od frontendowego? Jest to pewnego rodzaju specjalizacja. Zarówno backendowiec jak i frontendowiec posiadają pewne wspólne podstawy, na których budują bardziej specjalistyczne umiejętności. Jest to podobne do specjalizacji występującej w środowisku lekarzy. Chirurg i ortopeda najpierw poznają wspólną, uniwersalną wiedzę, następnie doskonalą się w swojej specjalizacji. Jeden i drugi jest lekarzem, natomiast ze względu na specjalizację, w swojej codziennej pracy wykonują nieco inne zadania i korzystają z nieco innych narzędzi. Oczywiście podział na programistów backendowych, frontendowych i mobilnych jest dużo mniej formalny niż ten regulowany prawnie w domenie medycyny. W wielu przykładach podział na frontend i backend obrazuje się jako górę lodową, której górna część (to co widzi użytkownik) to frontend, zaś dolna (pod wodą) backend. Jest to z grubsza prawda. Tak więc programista frontendu będzie implementował wygląd komponentów po stronie interfejsu użytkownika, to jak dane będą wyświetlane, wysyłane na serwer oraz logikę będącą “blisko” interfejsu użytkownika. Programista backendu implementuje trwałe zapisywanie oraz odczyt danych. Ta część systemu przyjmuje komendy i dane przekazane z komponentów frontendowych i zwraca odpowiednie komunikaty lub żądane informacje. Za poprawne działanie aplikacji odpowiedzialny jest zarówno frontend jak i backend. Tak jak chirurg ma nieco inny zestaw narzędzi niż ortopeda, tak do pracy na froncie i backendzie stosuje się różne technologie. Mówiąc konkretniej, programista frontendowy w przeważającej większości przypadków będzie w swojej pracy wykorzystywał jeden z języków programowania JavaScript lub TypeScript zaś backendowy Pythona, Javę, C#, JavaScript, PHP, Ruby’ego lub GO. Należy zwrócić uwagę, że podział na Frontend/Backend pasuje głównie do aplikacji udostępnianych poprzez przeglądarkę (aplikacjach webowych). Aczkolwiek w przypadku developmentu aplikacji mobilnych zazwyczaj korzysta ona również z serwera z modułem backendowym, tak więc w tym przypadku mamy Mobile/Backend. Podział ten nie jest jedyny, jednak Frontend, Backend oraz Mobile jest jednym z najbardziej popularnych rozróżnień, które pokrywa duży obszar możliwych projektów.

Python, JavaScript a może C#?

Oprócz określenia “programista backendu” spotkać się możemy również z pojęciami takimi jak  “programista Pythona” czy też “programista JavaScriptu”. Oznaczają one programistów specjalizujących się w konkretnych językach programowania. Po opanowaniu uniwersalnych podstaw programowania oraz zdobyciu pewnego doświadczenia, programista jest w stanie zrozumieć i w krótkim czasie opanować podstawy praktycznie dowolnego z wykorzystywanych szerzej języków programowania. Dlaczego więc mówi się o “programistach Pythona”? Otóż doświadczenie wynikające z lat pracy z daną technologią powoduje, że oprócz umiejętności jej zrozumienia, taka osoba posiada wysoką biegłość w różnych specyficznych dla danego języka konstrukcjach oraz dobrze orientuje się w dostępnych możliwościach. To tak jakby jedna firma specjalizowała się w budowaniu domów z drewna, a druga z cegły. Podstawowe zasady budowy domów są z takie same w obydwu przypadkach. Firma budująca z drewna, po poświęceniu pewnej ilości czasu na zapoznanie się ze specyfiką materiału ceglanego, byłaby w stanie zbudować budynek z cegieł. Jednak z drewnem poradzi sobie “z zamkniętymi oczami”. W świecie IT wygląda to podobnie.
Jaki język programowania wybrać na początek? W mojej opinii decyzja ta nie jest kluczowa. Podstawowych zasad konstrukcji domów można uczyć się ćwicząc zarówno na materiałach drewnianych jak i cegłach. Tak samo podstawowych praw programistycznych spokojnie nauczymy się zarówno w Pythonie jak i JavaScripcie, Javie, PHP, Ruby’m i C#. Dla niezdecydowanych polecam Python’a oczywiście 😉

Co konkretnie robi programista?

W mojej opinii na pracę programisty składają się dwa główne elementy. Pierwszy, będący niezbędny do opanowania drugiego, to tłumaczenie. Tłumaczenie języka naturalnego (polskiego, angielskiego, itp.) na język zrozumiały przez komputer. Przykładem może być poniższe zdanie zapisanie w języku naturalnym:

oraz przedstawione tak jak wyglądałoby to w kodzie Pythona:

Zauważcie, że po zaznaczeniu kolorami poszczególnych elementów wypowiedzi w języku naturalnym możemy odnaleźć ich odpowiedniki w języku Python. Oczywiście pracy przy tłumaczeniu jest dużo więcej. Człowiek rozumie co znaczy “pokrój”, komputer ma bardziej podstawowy zakres umiejętności. Tak więc poza zapisaniem dwóch powyższych kroków trzeba będzie mu jeszcze “rozpisać” co konkretnie znaczy “pokrój”, “połącz_składniki” itd. Jest jeszcze drugi, według mnie zdecydowanie ważniejszy i bardziej twórczy element. To projektowanie rozwiązań. Po pierwsze oznacza to zasugerowanie rozwiązań, które w naszym rozumieniu biznesu będą cele tego biznesu najlepiej wspierać. Tak jak od projektanta wnętrz oczekuje się, że po przedstawieniu mu ogólnego zarysu celu klienta (“chciałbym zdecydowanie oddzielić część kuchenną od salonowej”) zaproponuje konkretne rozwiązanie, tak programista powinien projektować rozwiązania przedstawionych problemów. Oprócz tego ważne jest takie zamodelowanie struktury programu, które najlepiej odpowiada aktualnym potrzebom biznesu, a w idealnym przypadku będzie łatwe do zmiany i dostosowania do przyszłych, dziś jeszcze nie znanych ale prawdopodobnych, potrzeb. W przykładzie z projektem wnętrz mogłoby to być “dzięki uniwersalności mebli zastosowanych w tym pokoju łatwo będzie zamienić go z gabinetu na pokój dla dziecka” ;). Wyzwania, które stawiane są przed programistami często dotyczą wzajemnie wykluczających się potrzeb po stronie biznesu. Rolą programisty jest opracowanie sprytnych rozwiązań, które w optymalny sposób są w stanie pogodzić najważniejsze wymagania funkcjonalne i jakościowe.

Morze projektów

Oprogramowanie jest o tyle specyficznym obszarem działalności człowieka, że jest ono wykorzystywane praktycznie w każdej branży. Aplikacje medyczne, rozrywkowe, przemysłowe, finansowe – wszędzie tam gdzie jest człowiek jest też kod. Dlatego właśnie projekty w IT są tak bardzo różnorodne. Inne wyzwania postawi przed nami system umożliwiający szybką wycenę nieruchomości, inne aplikacja wspierająca pracę kontrolera leków dopuszczanych do obiegu. Z drugiej strony zupełnie inaczej pracuje się w małej kilkuosobowej firmie a inaczej w wielkim korpo. Tak wielka różnorodność to jedna z bardzo ważnych cech branży, która powoduje, że dwa losowo wybrane projekty mogą się od siebie diametralnie różnić. Dodatkowo ciekawym elementem jest nauka na temat procesów i działania dziedziny, dla której przygotowujemy oprogramowanie. Pracując z rozwiązaniami medycznymi poznamy procedury obowiązujące w tym obszarze, pisząc system dla banku zobaczymy “od środka” proces udzielania kredytu hipotecznego itp.

Programowanie – ciemna i jasna strona mocy

Zbliżając się do końca, chciałbym jeszcze podsumować, co z mojej perspektywy w pracy programisty jest fajnego a co niezbyt. Zacznijmy od tej gorszej strony.

• Zabieranie pracy do domu. Problemy programistyczne mają to do siebie, że nie chcą człowieka “puścić”. Zdarza mi się, że po nieudanej próbie rozwikłania jakiejś kwestii i odłożeniu tematu na kolejny dzień nie przestaję myśleć o problemie. Po raz kolejny go analizuję, rozkładam na czynniki pierwsze, a nawet siadam “na pół godzinki” żeby jeszcze dziś się z tym zmierzyć.
• Presja czasu. Wiadomo, że niezależnie od branży najlepszy termin na wykonanie zadania to “wczoraj” Nie mam porównania z tym jak wygląda to gdzie indziej ale w IT presja czasu zdecydowanie jest obecna.
• Zależność od biznesu. Ostatecznie zazwyczaj budujemy rozwiązanie dla Biznesu. Pomimo sukcesów w naszym projekcie coś innego może się posypać w firmie, dla której implementujemy system. Wtedy, mimo tego, że “idziemy zgodnie z oczekiwaniami” mogą się skończyć fundusze na dalszy rozwój i ciężko jest w takiej sytuacji coś zrobić. A zawsze smutno jest zamykać dobrze zapowiadający się projekt  

No to dla równowagi – ta pozytywna strona

• Sprawczość i możliwość tworzenia. Jako programiści budujemy systemy, których wcześniej nie było. Trochę tak jakbyśmy tworzyli coś z niczego Rozmawiając z biznesem często wspieramy ich w kreowaniu ostatecznego rozwiązania, co daje nam realny wpływ na kształtowanie otaczającej nas rzeczywistości. Świadomość, że zaproponowane rozwiązanie ulepszy pracę tysięcy użytkowników jest dla mnie solidnym motywatorem.
• Różnorodność. Możliwość poszukiwania swojej drogi w firmach dużych i małych. Projektowanie systemów dla całkowicie odmiennych klientów – dla mnie to zdecydowanie recepta na nudę!
• Społeczność i praca zespołowa. Ludzie związani ze światem oprogramowania zbudowali imponującą i zróżnicowaną społeczność. Poznałem w niej mnóstwo niesamowitych osób, z którymi zarówno spotkanie przy piwie jak i wspólne projekty dają wielką satysfakcję. Osobiście bardzo lubię pracować z ludźmi w ogólności, a praca w IT to praca w 100% zespołowa.
• Praca detektywistyczna. Poszukiwanie problemów i ukrytych błędów często przypomina analizę wykonywaną na miejscu zbrodni. Coś się wydarzyło, widać efekty ale nie wiadomo która część systemu jest winna, gdzie kryje się błąd. Często znalezienie przyczyny bywa trudne, aczkolwiek dla mnie jest to zdecydowanie pozytywny proces, przypominający mi właśnie pracę detektywa z powieści kryminalnej. No i ta satysfakcja gdy już się znajdzie tę linijkę kodu!
• Wolność. Jako programista mogę pracować zdalnie, projektować rozwiązania na zlecenie klientów ze świata albo budować własny produkt, płacąc za development jedynie własnym czasem.

Ten artykuł powstał na podstawie przemyśleń związanych ze spotkaniem, które zrealizowaliśmy w ramach współpracy z Hakersami. Hakersi to społeczność tworzona przez Fundację Sarigato, która wspiera potrzebujące dzieci i młodzież w usamodzielnieniu się przez naukę programowania i robotyki. Aktualnie rozszerzają swoją działalność poza Trójmiasto i Kraków – na całą Polskę! Inicjatywa jest szczytna, dlatego zachęcam wszystkich do zajrzenia na ich stronę i wsparcia tej społeczności 🙂

PS: Slajdy z tego spotkania można pobrać tutaj.