Ścieżka programisty

1. Ścieżka kariery

Programiści mają również swoje stopnie w zależności od kwalifikacji. Kiedyś używano takich terminów jak „koder”, „programista” i „haker”, ale teraz wszyscy przechodzą na nazwy po angielsku z amerykańskiego IT.

Dla developera wyróżnia się 6 głównych stopni:

• Intern Software Engineer
• Junior Software Engineer
• Middle Software Engineer
• Senior Software Engineer
• TechLead
• Principal Software Engineer

Od kraju do kraju i nawet od firmy do firmy niektóre parametry mogą się różnić, ale ogólnie wygląda to tak:

• 🌱 Intern Software Engineer — to stażyści. Są na etapie nauki programowania, nie mają żadnego komercyjnego doświadczenia, ani udziału w dużych projektach. Zazwyczaj pracują pod okiem bardziej doświadczonych kolegów. Ich głównym zadaniem jest poznanie kodowej bazy i podstaw rozwoju oprogramowania, wykonując proste zadania kodowania i uczestnicząc w testowaniu.
• 🐣 Junior Software Engineer — to już programiści, ale bez poważnego doświadczenia komercyjnego lub z mniej niż rocznym doświadczeniem. Pracują pod kierunkiem bardziej doświadczonych deweloperów, realizując części projektów i biorąc udział w code-review. Ten etap kariery skupia się na pogłębianiu umiejętności technicznych i rozumieniu zadań projektowych.
• 🦾 Middle Software Engineer (lub po prostu Software Engineer): mają więcej samodzielności w podejmowaniu decyzji technicznych, odpowiadają za ważne części projektu, zaczynają mentorować mniej doświadczonych kolegów i aktywniej uczestniczą w dyskusjach architektonicznych. Zazwyczaj mają od 2 do 5 lat praktycznego doświadczenia.
• 🧑‍🔬 Senior Software Engineer: odpowiadają za projektowanie i realizację złożonych systemów, zapewniają mentoring i kierownictwo w zespole, uczestniczą w strategicznym planowaniu projektów i często reprezentują zespół w kontaktach z klientami i innymi interesariuszami. Zazwyczaj mają od 5 do 10 lat doświadczenia.
• 🧠 TechLead: odpowiada za końcowy efekt techniczny projektu, kieruje rozwojem, rozwiązuje najtrudniejsze zadania, dba o przestrzeganie standardów technicznych i koordynuje pracę deweloperów.
• 🏆 Principal Software Engineer: działa na najwyższym poziomie technicznym, często bierze udział w kształtowaniu strategii technicznej firmy, opracowywaniu innowacyjnych rozwiązań i ustalaniu standardów technicznych, pełni rolę głównego mentora dla liderów technicznych i jest kluczowym ekspertem w złożonych kwestiach technicznych.

To ciekawe. W dużych firmach mogą istnieć dodatkowe role i podrole. Na przykład w Google są takie role:

• Staff Software Engineer (L6): ma znaczący wpływ na politykę techniczną swojego działu.
• Senior Staff Software Engineer (L7): pracuje nad dużymi i skomplikowanymi projektami, wyznacza kierunek rozwoju technologicznego w firmie.

2. Lego-products

Było to dawno temu (w 1975 roku), kiedy Niklaus Wirth, twórca języka Pascal, napisał książkę „Algorithms + Data Structures = Programs”. Od tego czasu wiele się zmieniło. Współczesny produkt programistyczny to nie to, czym był 10 lat temu, a na pewno nie to, co 20 lat temu. O 1975 roku nie ma co mówić — minęło od tego czasu 50 lat ⏳

Współczesny programista już nie pisze programów ręcznie. Raczej je składa z gotowych części (bibliotek) i pisze kod, który pomaga tym częściom współpracować🧩. Nowoczesne produkty mogą składać się z dziesiątek i setek programów. Niektóre uruchamiają się na komputerze użytkownika, na jego urządzeniach mobilnych, a większość — na serwerach w data center.

Wiele z tych programów, takich jak web-server czy baza danych, jest już napisanych. Trzeba je tylko odpowiednio skonfigurować, żeby działały poprawnie. Chociaż z czasem proces konfiguracji może stać się tak skomplikowany, że praktycznie zamienia się w development 🤦‍♂️.

Programiści ciągle ze sobą walczą. Zamiast pisać podobny kod w różnych programach, tworzą biblioteki, które można konfigurować (ustawiać) pod własne potrzeby, a potem po prostu podłączać wszędzie tam, gdzie są potrzebne.

Przez ostatnie 20 lat programiści napisali bardzo dużo bibliotek, frameworków i open-source repositories. Jest ich naprawdę miliony. I teraz pisanie wszystkiego od zera to już niemodny trend. Zamiast tego, lepiej złożyć program z wysokiej jakości i sprawdzonych rozwiązań — bibliotek, frameworków, pakietów i modułów 🧱.

Ale i taki sposób już się starzeje. Tendencja ostatnich 10 lat — to migration to cloud, duże data centers, które zapewniają Twoim programom wszystko, czego potrzebują. Chcesz bazę danych? Mamy ich setki do wyboru. Chcesz rzadki, unikalny web-server? Też mamy! Każda zachcianka za odpowiednią opłatą.

3. „Ja jestem inżynierem” © Elon Musk

Już nie trzeba pisać skomplikowanych i nudnych rzeczy samodzielnie. Jeśli potrzebujesz jakiejś funkcjonalności — są już gotowe biblioteki i frameworki. Twoje zadanie: a) znać ich istnienie, b) znaleźć odpowiedni (często jest kilka alternatyw, z różną jakością i niuansami), c) zrozumieć, jak je zintegrować z własnym projektem 🎓.

Praca stała się przez to o wiele ciekawsza. Teraz możesz 10 razy szybciej dodawać nową funkcjonalność do produktu. 30 lat temu, jeśli potrzebowałeś web-servera, pisałeś go od zera. 20 lat temu — kupowałeś, instalowałeś i konfigurowałeś. A teraz — po prostu logujesz się do chmury Azure albo AWS i włączasz potrzebny serwis 🌐.

To, nawiasem mówiąc, jedna z przyczyn popularności języka C#. On świetnie nadaje się nie tylko do pisania dużych rozwiązań, ale też do „łączenia” różnych komponentów — przez .NET można integrować praktycznie z wszystkim, od baz danych, przez mikroserwisy, REST API, kolejki wiadomości, aż po chmurowe usługi.

W związku z tym, profesja C#/.NET developer od dawna przekształciła się w Fullstack .NET Software Engineer. Współczesny deweloper musi rozumieć, jak działa baza danych (SQL Server, PostgreSQL, MongoDB i inne), żeby poprawnie budować komunikację. Trzeba też znać frontend (HTML, CSS, JavaScript/TypeScript, Blazor), żeby konfigurować wymianę danych z backendem na C#. No i oczywiście, bez Docker już się nie da — to już standard branży. 🐳

Współczesne tworzenie oprogramowania jest bardzo różne od tego, co było 20 lat temu. Programista pisze kod nie więcej niż 50% czasu — reszta to czytanie dokumentacji, nauka nowych technologii, projektowanie i praca zespołowa na spotkaniach. Programiści solo to już raczej rzadkość.