6.1 Ścieżka kariery
Sami programiści mają również swoje poziomy zależnie od kwalifikacji. Kiedyś używane były takie terminy jak „koder”, „programista” i „haker”, ale teraz wszyscy przechodzą na nazwy z amerykańskiego IT.
Dla dewelopera istnieje 6 głównych poziomów:
- Intern Software Engineer
- Junior Software Engineer
- Middle Software Engineer
- Senior Software Engineer
- Tech Lead
- Principal Software Engineer
W poszczególnych krajach niektóre parametry mogą się różnić, ale ogólnie sprawa wygląda tak:
Intern Software Engineer — to stażyści. Są w trakcie nauki programowania, nie mają ani komercyjnego doświadczenia, ani doświadczenia w dużych projektach. Zwykle pracują pod nadzorem bardziej doświadczonych kolegów. Ich głównym zadaniem w pracy jest nauka bazy kodu i podstaw tworzenia oprogramowania, wykonując proste zadania związane z kodowaniem i uczestnicząc w testowaniu.
Junior Software Engineer — to już programiści, ale bez poważnego komercyjnego doświadczenia lub z doświadczeniem poniżej roku. Pracują pod kierunkiem bardziej doświadczonych deweloperów, realizując części projektów i uczestnicząc w cyklach code review. Ten etap kariery skupia się na pogłębianiu umiejętności technicznych i zrozumieniu zadań projektowych.
Middle Software Engineer (lub po prostu Software Engineer): mają więcej samodzielności w podejmowaniu decyzji technicznych, są odpowiedzialni za znaczące części projektu, zaczynają mentorską rolę wobec mniej doświadczonych kolegów i aktywniej uczestniczą w dyskusjach architektonicznych. Zwykle mają 2–5 lat doświadczenia praktycznego.
Senior Software Engineer: są odpowiedzialni za projektowanie i realizację skomplikowanych systemów, zapewniają wsparcie mentorskie i prowadzenie w zespole, uczestniczą w strategicznym planowaniu projektów i często reprezentują zespół w kontaktach z klientami i innymi zainteresowanymi stronami. Zwykle mają 5–10 lat doświadczenia.
Tech Lead: jako lider techniczny, ponosi odpowiedzialność za końcowy wynik techniczny projektu, kieruje rozwijaniem, rozwiązuje najtrudniejsze zadania, zapewnia przestrzeganie standardów technicznych i koordynuje działalność deweloperów.
Principal Software Engineer: działa na najwyższym poziomie technicznym, często uczestnicząc w formowaniu strategii technicznej firmy, tworzeniu innowacyjnych rozwiązań i ustanawianiu standardów technicznych, służy głównym mentorem dla liderów technicznych i jest kluczowym ekspertem w rozwiązywaniu złożonych kwestii technicznych.
Duże firmy mogą mieć dodatkowe role i podrole. Na przykład, w Google istnieją takie role:
- Staff Software Engineer (L6): ma znaczący wpływ na politykę techniczną swojego działu.
- Senior Staff Software Engineer (L7): pracuje nad projektami na dużą skalę i złożonymi, określa strategiczny kierunek rozwoju technicznego w firmie.
6.2 Produkty Lego
Dawno temu (w 1975 roku) Niklaus Wirth, twórca języka Pascal, napisał książkę "Algorytmy + Struktury danych = Programy". Od tego czasu wiele się zmieniło.
Współczesny produkt programowy to nie to samo, co 10 lat temu, a już na pewno nie to samo, co 20 lat temu. O 1975 roku nie ma co mówić: od tego czasu minęło 50 lat.
Współczesny programista już nie pisze programów ręcznie. Raczej zbiera je z gotowych części (bibliotek) i pisze kod, który pomaga tym częściom w interakcji.
Współczesne produkty programowe mogą składać się z dziesiątek i setek programów, z których niektóre są uruchamiane na komputerze użytkownika, jego urządzeniach mobilnych, a większość na serwerach w centrum danych.
Wiele z tych programów, takich jak serwer internetowy czy baza danych, jest już napisanych. Trzeba je po prostu odpowiednio skonfigurować, aby działały jak należy. Chociaż z czasem proces konfiguracji może stać się na tyle skomplikowany, że faktycznie zmienia się w tworzenie. 🤦♂️
Programiści ciągle zmagają się z samymi sobą. Zamiast znów pisać podobny kod w różnych programach, piszą biblioteki, które można skonfigurować (dostosować) do swoich potrzeb i po prostu włączają je we wszystkie wymagane miejsca.
W ciągu ostatnich 20 lat programiści stworzyli bardzo wiele bibliotek, frameworków i otwartych repozytoriów. Rzeczywiście są ich miliony. I teraz pisanie całego kodu od podstaw jest uznawane za złą praktykę. Zamiast tego należy złożyć program z jakościowych i sprawdzonych rozwiązań — bibliotek, frameworków, pakietów i modułów.
Ale i to podejście już się starzeje. Trendem ostatnich 10 lat jest migracja do chmur — duże centra danych, które dostarczają twoim programom wszystkiego, czego potrzebują. Chcesz bazę danych? Mamy ich setki do wyboru. Chcesz rzadki unikalny serwer internetowy? Mam ich na pęczki. Każda zachcianka za twoje pieniądze.
6.3 „Jestem inżynierem” (c) Elon Musk
Nie trzeba już pisać skomplikowanych i nudnych rzeczy. Teraz, jeśli potrzebujesz jakiejś fajnej skomplikowanej funkcjonalności, na tą okazję zawsze istnieje jakaś biblioteka. Wystarczy, że: a) wiesz, że ona istnieje, b) znajdziesz właściwą (mogą być dziesiątki analogów różnej jakości), c) nauczysz się, jak ją zintegrować ze swoim projektem.
Praca stała się dzięki temu tylko ciekawsza. Teraz możesz 10 razy szybciej dodawać do produktu nową funkcjonalność. 30 lat temu, jeśli potrzebny był ci serwer www, musiałeś go napisać. 20 lat temu — kupić, zainstalować i skonfigurować. A teraz — po prostu zalogować się do panelu administracyjnego „chmury” i włączyć.
To, nawiasem mówiąc, jedna z przyczyn popularności Frontendu. Skomplikowany backend teraz można pisać na JavaScript z użyciem Node.js, lub po prostu „włączyć” różne usługi w centrach danych chmurowych. Frontend przestał być mocno zależny od ograniczeń backendu i rozwinął się w pełni. I sądząc po jego popularności, świetnie spełnia swoją rolę.
No i sama profesja Frontend-dewelopera przekształciła się w Frontend Fullstack Software Engineer. Współczesny Frontend-deweloper musi rozumieć, jak działa baza danych, aby umiejętnie z nią pracować. Rozumieć HTML & JavaScript, NginX, aby dostosować działanie frontendu z backendem. No i Docker jest potrzebny — to już po prostu standard branżowy.
Współczesna produkcja oprogramowania w ogóle nie przypomina tego, co było jeszcze 20 lat temu. Współczesny programista pisze kod nie więcej niż 50% swojego czasu. Resztę czasu spędza na czytaniu dokumentacji, nauce nowych technologii i uczestniczeniu w spotkaniach (naradach). Samotne wilki programistyczne odeszły w przeszłość.
GO TO FULL VERSION