Branża IT i praca programisty są bardzo popularne oraz oferują szeroki zakres możliwości nie tylko dla osób, które od dziecka związane są z programowaniem ale również dla tych, które postanawiają się przebranżowić i zostać programistą.
Ten wpis będzie poświęcony pracy programisty i odpowiemy sobie na pytanie jak wygląda i na czym polega praca programisty, czy praca programisty w każdej firmie wygląda tak samo, oraz czym praca programisty różni się w zależności od doświadczenia.
Praca programisty wiadomo, że nigdy nie będzie wyglądała tak samo bo każda firma jest inna i w każdej pracuje się inaczej na swój sposób. Aczkolwiek zakres zadań i kompetencji na podobnych stanowiskach jest porównywalny i dlatego chciałbym Ci przybliżyć jak to wygląda “za kurtyną”, czyli od środka.
Pamiętam jak bardzo interesowało mnie to jak tak na serio wygląda praca programisty, gdy uczyłem się programowania. Słyszałem różne historie i na szczęście te negatywne zdecydowanie były przesadzone i dobrze, że nie dałem się zniechęcić przez osoby, które niewiele wiedzą jakie są realia.
Z drugiej strony moje doświadczenie jest dość krótkie bo pracuję jako programista od lutego 2022, aczkolwiek pracowałem już w 3 firmach, poznałem sporo osób i dlatego piszę teraz jak to wygląda z mojej perspektywy po takim czasie a w przyszłości zrobię pewnie update z perspektywy kilku/ kilkunastoletniego doświadczenia i sam zobaczysz jak moje postrzeganie się zmieniło.
Na czym polega praca programisty?
Gdybym miał odpowiedzieć na to pytanie jednym zdaniem to powiedziałbym, że jest to rozwiązywanie problemów, tworzenie kodu, testowanie kodu, naprawianie błędów w kodzie, dokumentowanie kodu, współpraca z innymi i wiele więcej.
Aczkolwiek postanowiłem trochę bardziej opisać te wymienione obszary pracy programisty ale w związku z tym, że to wszystko jest bardzo elastyczne i przeplata się na wielu poziomach to podszedłem do tematu bardziej ogólnie.
Praca programisty W takim ogólnym założeniu polega na tworzeniu oprogramowania. Aczkolwiek na proces tworzenia kodu składa się wiele mniejszych czynności i są one równie ważne a czasem nawet ważniejsze niż sam etap pisania kodu i tworzenia oprogramowania.
Trzeba mieć na uwadze, że zazwyczaj przed rozpoczęciem jakiegokolwiek projektu i przed napisaniem pierwszej linijki kodu występuje etap planowania zarówno architektury jak i konkretnej aplikacji lub konkretnego projektu. Jest to bardzo ważny proces ponieważ na podstawie opracowanych koncepcji I założeń podejmowane są dalsze kroki.
Dlatego jeśli spartolimy coś od samego początku to te błędy będą dawały o sobie znać na kolejnych etapach realizacji projektu co może finalnie skończyć się koniecznością zmiany podejścia lub drastycznych kroków.
Nie będę się skupiał tutaj na kwestiach związanych z podejściem biznesowym kwestiach architektury oprogramowania i innych ważnych elementach bo myślę, że interesuje Cię bardziej to jak wygląda zwykły dzień pracy programisty.
Zarządzanie projektem
W zależności od tego do jakiej firmy trafisz, spotkasz się z różnymi podejściami odnośnie zarządzania projektem. Jeśli to będzie firma do 30/50 osób a ja w takich do tej pory pracowałem to wiele z tych firm stosuje zarządzanie projektem zgodnie z metodą Agile czyli w formie na przykład dwutygodniowych sprintów.
Czyli załóżmy, że na początku miesiąca spotykamy się wszyscy, lub spotykają się osoby na stanowiskach kierowniczych i menedżerskich a następnie ustalają cele sprintów. Wiadomo, że z tyłu głowy mamy cały czas ogólną koncepcję projektu i to jaki cel chcemy osiągnąć, ale żeby było łatwiej to dzielimy sobie ten Big Idea na mniejsze części, które są prostsze do zarządzania i kontrolowania czy zmierzamy w dobrym kierunku.
W zależności od tego jak wygląda struktura firmy i hierarchia to otrzymujesz zadanie od swojego przełożonego bezpośrednio, lub Twój team leader otrzymuje zadanie a następnie dzieli to na mniejsze porcje i układa pracę w swoim zespole.
W zależności od tego jakie to będzie zadanie no to tak dobiera zasoby żeby przede wszystkim założony cel na ten spring był osiągnięty i wiadomo, że to jest kwestia bardzo elastyczna bo to nie jest coś na zasadzie produkcji gdzie większość rzeczy można zmierzyć zważyć i konkretnie zaplanować Ile czasu zajmie wykonanie danej czynności bo jest to proces powtarzalny.
W przypadku tworzenia oprogramowania te z pozoru prostsze zadania mogą czasem zajmować więcej czasu niż te trudne i skomplikowane, które w rzeczywistości mogą okazać się łatwymi taskami do zrealizowania.
Gdy zadania są podzielone, wówczas rozpoczynamy pracę i w zależności od tego jak to wszystko funkcjonuje w firmie, z pewnością zadania będą przydzielane w jakimś systemie takim jak na przykład Click up, gdzie będziesz miał podgląd do swoich aktualnych tasków.
Jeśli zadanie będzie wymagało współpracy z innymi osobami lub będziesz osobą, która dopiero zaczyna i inny bardziej doświadczony programista będzie Cię wprowadzał to wiadomo, że ta osoba będzie Ci wyjaśniała wszystko co robimy i będzie do twojej dyspozycji żeby w razie czego pomóc.
Pisanie kodu i rozwiązywanie problemów
Zazwyczaj będzie to tak wyglądało, że dostaniesz jakiś konkretny problem lub konkretną rzecz do wdrożenia a na samym początku będą to drobne rzeczy żebyś po prostu sobie z tym poradził i dopiero z czasem będą to coraz trudniejsze i bardziej skomplikowane zadania.
Gdy otrzymujesz takie zadanie no to wiadomo, że najpierw musisz dokładnie zrozumieć jaki jest problem i jaki jest cel tego, czyli co masz konkretnie zrobić. Zawsze warto upewnić się żeby nie okazało się, że Twoje założenia były całkowicie odmienne od tego co miało być zrealizowane. Dlatego najlepiej gdy dostajesz zadanie od konkretnej osoby to utwierdź się w przekonaniu, że to jak Ty to rozumiesz i postrzegasz jest na pewno zgodne z tym co masz osiągnąć.
Jeśli masz już pewność, że Twój tok rozumowania jest prawidłowy to rozpoczynasz od tego żeby najpierw zrozumieć problem i to co należy zrobić a następnie podzielić sobie na mniejsze etapy, które pozwolą Ci zrealizować ten cel i rozwiązać dany problem lub wdrożyć daną funkcjonalność.
Wiadomo, że tutaj nie będę mówił o tym jak wygląda jakieś wdrożenie, konfiguracja środowiska i tak dalej bo zakładam, że już jesteś po tym etapie tylko po prostu otrzymałeś zadanie i masz teraz zrobić coś konkretnego.
Czyli już jesteś wdrożony w firmie, wszystko u Ciebie działa, możesz uruchomić projekt lokalnie go developować. Następnym krokiem jest rozkminienie sobie co ja mam zrobić i następnie podzielić to sobie na mniejsze elementy, które będziesz mógł realizować i na bieżąco raportować co robisz.
Warto mieć również na uwadze fakt żeby podzielić zadanie na takie mniejsze klocki które będziesz mógł na bieżąco zapisywać i przesyłać aktualną wersję projektu na przykład do GitHuba bo dzięki temu w przypadku jakichkolwiek zmian czy utracenia aktualnej wersji projektu, będziesz mógł wrócić do tego co zrobiłeś i nic nie zostanie utracone.
Tak jak już było powiedziane we wstępie programista tworzy kod czyli jest odpowiedzialny za pisanie kolejnych linijek kodu w celu osiągnięcia jakiegoś rezultatu. Może być to naprawienie błędu dodanie jakiejś nowej funkcjonalności refaktoryzacja kodu i inne rzeczy.
Czyli dostajesz zadanie i piszesz kod aby je zrealizować, ale w zależności od podejścia firmy Twoje zadania mogą dotyczyć nie tylko samego tworzenia kodu ale również testowania tego kodu, konfiguracji środowiska no i co tylko można sobie wymyślić.
Zazwyczaj jest tak, że Im mniejsza firma to tym bardziej jedna osoba realizuje wiele zadań i nie zawsze związanych stricte z specjalizacją. Czyli pomimo tego, że jesteś na stanowisku załóżmy frontend developera to możesz dostać zadanie skonfigurowanie serwera i jakiś innych prac devopsowych lub backendowych.
W większych firmach większy nacisk kładzie się na specjalizację bo jest więcej osób, są większe zasoby finansowe a więc raczej jest tak, że każdy jest specjalistą w swojej dziedzinie i skupia się na zadaniach z nią związanych.
Kontrola wersji i zapisywanie zmian
Dodatkowo poza samym pisaniem kodu równie ważne jest zarządzanie projektem w czasie i na bieżąco zapisywanie zmian w repozytorium i przesyłanie ich do repozytorium zdalnego.
Czyli dobrą praktyką jest częste commitowanie tylko z takim założeniem, że ta funkcjonalność, którą wysyłasz do repozytorium zdalnego i ogólnie z której robisz już commita powinna być działającą wersją.
Czyli nawet jeśli to nie jest załóżmy wizualnie jakieś piękne i nie jest to w pełni funkcjonalne rozwiązanie to staraj się zapisywać taką wersję projektu, która działa a nie taka, która jest w połowie skończona.
Jest to dobra praktyka bo może się okazać, że w międzyczasie dostaniesz jakiegoś szybkiego taska, który potocznie nazywa się jako hot fix czyli załóżmy na produkcji pojawi się jakiś błąd i jak najszybciej trzeba to poprawić.
Dlatego odsuwasz obecne zadanie na bok i skupiasz się na tym konkretnym problemie żeby po prostu go naprawić jak najszybciej. No i może być taka sytuacja, że po jakimś czasie gdy ogarniesz już ten obecny problem wrócisz do swojego taska no i nie będziesz pamiętał o co tam chodziło co tam się działo i dlaczego to nie działa.
Natomiast jeśli zacommitujesz już kod, który działa przynajmniej w podstawowym zakresie no to kolejne kroki będą polegały na rozwijaniu tego i na ulepszaniu a nie na pracy od początku czyli rozkminianiu czemu to nie działa i co tam należy zrobić.
Testowanie kodu
Warto również pamiętać o testowaniu kodu i w zależności od podejścia firmy albo sam będziesz testował napisany przez siebie kod albo ekipa testerów będzie pod każdym względem sprawdzała Twój kod i w przypadku wykrycia nieprawidłowości dostaniesz informację co nie działa i będziesz musiał to poprawić czyli debugować kod.
Debugowanie kodu czyli usuwanie błędów
Debugowanie kodu polega najogólniej mówiąc na usuwaniu błędów i sprawianiu żeby wszystko działało prawidłowo. Nie ma reguły i czasem Twoje taski będą polegały tylko na usuwaniu błędów.
Błędy pojawiają się wszędzie, czasem coś może być nawet dobrze przetestowane, czyli podjęliśmy kroki żeby uniknąć tych błędów ale z czasem jakaś wersja się mogła zmienić, weszły jakieś aktualizacje i okazało się, że mamy problem i trzeba sprawić żeby projekt działał prawidłowo.
Tworzenie dokumentacji
Kolejna kwestia to tworzenie dokumentacji. Skoro jesteś autorem jakiegoś kodu to najlepiej opiszesz co w nim się dzieje, jak działa itd. żeby kolejne osoby, które dołączą do projektu, będą mogły się szybko dowiedzieć co w tym kodzie się dzieje, jak wygląda struktura itd. Po prostu zrozumieć działanie kodu.
Współpraca i spotkania
Zazwyczaj jest tak, że wraz z doświadczeniem rośnie liczba spotkań i ogólnie innych aktywności, które nie są związane stricte z pisaniem kodu ale innymi rzeczami, które są niezbędne aby ten kod powstał i działał prawidłowo.
Chodzi tutaj o współpracę z innymi, ocenę kodu innej osoby, dodawanie sugestii dotyczących zmian i co mogłoby być napisane inaczej lub lepiej, tworzenie architektury, planowanie, ustalanie celów, dzielenie pracy na mniejsze zadania i ustalanie priorytetów.
To między innymi z takimi zadaniami mierzą się osoby bardziej doświadczone. Aczkolwiek nie ma reguły i to co tutaj napisałem może sprawdzić się w części firm ale nie wszystkich.
Programiści często pracują w zespołach, współpracując z innymi programistami, kierownikami projektów i interesariuszami w celu stworzenia oprogramowania, które spełnia potrzeby ich klientów lub użytkowników. Mogą również pracować niezależnie, wykorzystując swoje umiejętności do tworzenia własnego oprogramowania lub aplikacji.
Czy praca programisty w każdej firmie wygląda tak samo?
Nie, praca programisty może się znacznie różnić w różnych firmach ponieważ to jak będzie ona wyglądała zależy od wielu czynników.
Między innymi trzeba wziąć pod uwagę profil firmy, czy będzie to startup, software house, lub może jedynie dział IT do wsparcia innego projektu. W konsekwencji rodzaj tworzonego oprogramowania jest całkiem inny. Kolejna kwestia to rola, jaką taki programista pełni w swoim zespole.
Przykładowo, jeśli będziesz pracować w mniejszej firmie / małym zespole programistów lub w startupie to zazwyczaj będziesz miał szerszy zakres obowiązków i będziesz pracować nad różnymi rzeczami na raz. Z kolei programista w większej firmie lub korpo, będzie miał bardziej wyspecjalizowane role i zazwyczaj będzie skupiać się na jednym projekcie lub produkcie.
Trzeba mieć również na uwadze narzędzia i technologie wykorzystywane przez programistów w danej firmie lub projekcie. Dodatkowo, może być tak, że jednego dnia będziesz pracować nad nową funkcją lub projektem, a za kilka dni możesz debugować i naprawiać błędy w istniejącym kodzie.
Dlatego też codzienna praca programisty może się znacznie różnić w zależności od organizacji i projektu. Nie poruszam tutaj kwestii związanych z pracą zdalną/ biurową, ilością spotkań i ich zasadnością itd. Są to bardzo indywidualne kwestie i co kraj to obyczaj.
Wiadomo, że można znaleźć wzorce ale tak naprawdę to wszystko wychodzi w praktyce i nie ma się co za bardzo tym przejmować bo na początku najważniejsze będą Twoje umiejętności techniczne i to jak podchodzisz do rozwiązywania problemów i jak działasz w teamie.
Czym praca programisty różni się w zależności od doświadczenia?
Praca programisty zazwyczaj różni się w zależności od jego poziomu doświadczenia. Nie ma reguły ale zauważyłem taką tendencję, że wraz z poziomem doświadczenia, programiści piszą mniej kodu a więcej czasu poświęcają na inne obowiązki takie jak prowadzenie projektów, mentorowanie mniej doświadczonych osób, planowanie, tworzenie architektury i optymalizacja oraz wyszukiwanie usprawnień .
Juniorzy zazwyczaj większość czasu w pracy spędzają nad mniejszymi zadaniami, takimi jak naprawianie błędów lub wdrażanie nowych funkcji, podczas gdy seniorzy realizują zadania wyższego poziomu, takie jak projektowanie architektury oprogramowania, opracowywanie złożonych algorytmów lub współpraca z klientem w celu określenia wymagań projektu.
Dodatkowo, w miarę coraz większego doświadczenie, bedziesz mógł zdecydować w którym kierunku chcesz podążać. Czy wybierasz specjalizację w wybranej technologii, lub kilku technologiach, czyli taką stricte techniczną ścieżkę. Czy może zdecydujesz się pójść w kierunku team leadera, zarządzać projektem, określać wymagania, mentorować innych itd.
Wiadomo, że tutaj również nie ma reguł i każda firma ustala wewnętrzne zasady. Jedno jest pewne, im mniejsze doświadczenie posiadasz, tym konkretniejsze zadania dostajesz. Czyli jako junior dostaniesz zadanie z opisem co i jak konkretnie masz zrobić, bo już to ktoś za Ciebie rozkminił i Ty po prostu jesteś osobą odpowiedzialną za napisanie tego kodu.
Natomiast wraz ze wzrostem doświadczenia i umiejętności, dostaniesz trudniejsze i bardziej zagmatwane zadania. Wówczas to Ty będziesz musiał rozkminić co i jak zrobić, tak żeby było dobrze. Wiadomo będziesz mógł się podpytać i doradzić ale wiadomo, że zadania nie będą już takie łatwe i proste, tylko zazwyczaj coraz bardziej odpowiedzialne i skomplikowane.
Podsumowanie
Pamiętaj, że ten wpis oparłem głównie o własne doświadczenia i doświadczenia moich znajomych. Nigdy nie będzie tak, że te praktyki i zadania w 100% pokrywają się z tym co będziesz robił Ty, w swojej pracy.
Chciałem mniej więcej przybliżyć jak to wygląda od środka i jak sam możesz zauważyć, często bywa tak, że wraz z doświadczeniem programiści piszą mniej kodu ale robią inne rzeczy, które są niezbędne, żeby kod który powstanie był dobrej jakości i działał tak jak powinien, przy uwzględnieniu masy czynników.
W tym wpisie opisałem niektóre z kluczowych aspektów pracy jako programista, w tym różne role i obowiązki, codzienną pracę programistów oraz to, jak praca programisty może się różnić w zależności od doświadczenia i wiedzy specjalistycznej.
