Programista, programista i inżynier wchodzą do baru. Barman jest zdezorientowany, dlaczego jedna osoba opiera nogi na 3 stołkach barowych.

Jeśli kiedykolwiek przeglądałeś opisy stanowisk pracy dla osób zajmujących się pisaniem kodu, często zauważysz brak zgodności w sposobie tworzenia postów w różnych firmach. W większości przypadków zobaczysz stanowisko informujące, że firma poszukuje „programisty”, „programisty” lub „inżyniera”. Częściej jednak nie: te posty są pisane przez osobę z działu HR, która często nie zajmuje się żadnymi technicznymi aspektami pracy – i tak naprawdę nie myśli o konotacji, jaką niesie ze sobą każde słowo.

Ostatecznie dla osób wykonujących ten zawód; tak długo jak okażesz się skuteczny na swoim stanowisku, etykieta przydzielona Ci przez HR ma bardzo małe znaczenie i również możesz używać tych słów zamiennie. Ale jako profesjonalista techniczny być może konotacja tych słów ma ma dla ciebie znaczenie!

Jaka jest więc różnica między tymi trzema ściśle powiązanymi terminologiami? To temat, nad którym debatuje się od lat. Definicja, którą każdy sam opisuje, jest nieco niuansowa, jednak podstawowe zachowanie tych trzech ról jest dość stabilne w porównaniu z perspektywą wszystkich. Jestem bardzo wzrokowcem, więc myślę, że najlepszym sposobem na przedstawienie sposobu, w jaki interpretuję różnice, jest poniższy diagram:

Prawdopodobnie zastanawiasz się: „dlaczego trójkąt jest odwrócony do góry nogami”. Przez chwilę zastanawiałem się, dlaczego ciągle mam wizje odwróconego trójkąta. Jasność tego diagramu stanie się jasna, gdy przyjrzymy się każdej warstwie trójkąta, zaczynając od warstwy programisty.

Programista

Przekonasz się, że typowe zachowania programisty są związane z wykonywaniem prostych lub powtarzalnych zadań i próbą ich zautomatyzowania.

Programiści zazwyczaj pracują z jednym językiem i tworzą oprogramowanie, które wykona proste zadanie. Kod samego oprogramowania jest zwykle mocno rozdęty i może być zaśmiecony anty-wzorcami, ale mimo to spełnia swoje zadanie. Programista zazwyczaj jest w stanie napisać kod w wybranym przez siebie języku, ale tak naprawdę nie rozumie najbardziej efektywnego sposobu pisania kodu. Może również brakować wielu semantyki potrzebnej do współpracy w środowisku, w którym wiele osób tworzy ten sam kod.

Nie oznacza to jednak, że programiści są „niekompetentni”. Czasami nie potrzebujesz wysoce skalowalnego i niezwykle rozszerzalnego rozwiązania – możesz po prostu potrzebować czegoś, co po prostu działa. Rozwiązanie może nie zadziałać po może 6 miesiącach, ale rozwiązanie, którego wykonanie zajęło 10–20 minut i poprawiło produktywność lub zaoszczędziło czas na 6 miesięcy, jest nadal nieocenionym wyczynem; a możliwość stworzenia czegoś takiego to imponująca umiejętność.

Programiści to dosłownie tylko wierzchołek góry lodowej (lub odwrócony trójkąt), a „programowanie” to skuteczna umiejętność, która nie wymaga intensywnego szkolenia ani nauki, aby się uczyć. Jeśli nie jesteś specjalistą i czujesz, że mógłbyś napisać proste skrypty automatyzujące niektóre codzienne zadania, gorąco zachęcam Cię, abyś umieścił programowanie jako jedną z umiejętności w tylnej kieszeni.

Deweloper

Dość często zdarza się, że programista spędza godziny lub dni na pisaniu kodu, a następnie w końcu wychodzi z izolacji i przygotowuje się do przesłania swojej pracy. Następnie powiedziano im, że będą wymagać pewnych zmian…

Twórcy oprogramowania zazwyczaj pracują szybko. Zazwyczaj dobrze znają swój stos, dobrze rozumieją wybrany język (języki) i wiedzą, jak wdrażać projekty i pomysły za pomocą kodu. Jeśli potrzebujesz oprogramowania; programista dostarczy Ci wyniki, a nawet będzie gotowy do iteracji na tych wynikach przez cały okres istnienia oprogramowania.

SDLC: Cykl życia oprogramowania

Twórcy oprogramowania są bardzo dobrze zorientowani i zazwyczaj są na bieżąco z aktualnymi trendami, takimi jak nowe funkcje językowe, frameworki lub narzędzia programistyczne. Podobnie jak programiści, często starają się zautomatyzować swoje zachowanie za pomocą narzędzi i bibliotek, aby móc jeszcze szybciej się rozwijać.

Dlaczego więc miałbyś chcieć inżyniera, skoro możesz po prostu znaleźć programistę? Odpowiedź jest prosta, deweloper potrzebuje spójnego kierunku technicznego. Często musisz wyraźnie określić, czego oczekujesz od oprogramowania. Załóżmy na przykład, że chcesz zbudować witrynę internetową służącą do sprzedaży płyt DVD ludziom na całym świecie. Powiedzą Ci „nie ma problemu”, utwórz aplikację reagującą, połącz się/utwórz backend i udostępnij witrynę internetową, która pozwala ludziom kliknąć żądaną płytę DVD, a następnie wysłać ją do nich. Potem spojrzysz na to na telefonie i zapytasz: „dlaczego to tak wygląda”. To dlatego, że nie powiedziałeś, że chcesz, aby był przyjazny dla urządzeń mobilnych.

Programiści są bardzo zdolni; ale jeśli nie będziesz z nimi na każdym etapie procesu programowania, często rozwijają się w tak szybkim tempie, że nie myślą o żadnych przypadkach brzegowych. Ich kod często będzie wymagał częstej refaktoryzacji, a jeśli kod nie będzie sprawdzany zbyt długo, pozostaną góry długu technicznego. Możesz spojrzeć na kod programisty i zapytać: „ale dlaczego umieściłeś to wszystko tutaj?” lub „dlaczego zacząłeś używać etui na wielbłądy, a następnie przerzuciłeś się na środkową funkcję pojemnika na kebab?”. Programiści często nie troszczą się o przyszłość i skupiają się głównie na dostarczaniu wyników w teraźniejszości.

Inżynier

Kiedy zwracasz się do inżyniera z problemem, czasami nie udzieli on natychmiastowej odpowiedzi. Dadzą Ci 3–4 różne rozwiązania z zaletami i wadami każdej strategii, a nawet pomogą Ci podjąć najlepszą decyzję na podstawie wybranych wyborów.

Zakres inżyniera oprogramowania to całość odwróconego trójkąta. Oczekuje się, że będą mieli takie same możliwości jak programista i programista; oprócz konieczności posiadania własnego, unikalnego zestawu umiejętności. Można by pomyśleć, że inżynier oprogramowania jest absolutnym ekspertem w językach programowania, ale często inżynier spędza więcej czasu na przeglądaniu dokumentacji niż programista.

Inżynierowie oprogramowania nie unikają problemów, oni je analizują. Biorą problem, następnie tworzą podproblemy i więcej podproblemów, a następnie rozwiązują każdy z nich, korzystając ze swojego bogatego doświadczenia i arsenału teorii informatyki, takich jak bardzo znienawidzony temat „Struktury danych i algorytmy”.

Inżynierowie oprogramowania uwielbiają ideę skalowalności. Jeśli kiedykolwiek słuchasz inżyniera oprogramowania przedstawiającego swój pomysł i pytasz go „ale czy jest on skalowalny?” najprawdopodobniej zobaczysz, jak zatrzymują się na chwilę, a następnie podają kilka sposobów skalowania i w jakim stopniu. Nie muszą zapamiętywać funkcji i metod języka, ponieważ dokładnie wiedzą, w jaki sposób musieliby manipulować strukturą danych, z którą pracują, i dokładnie wiedzą, jak znaleźć tę metodę w dokumentacji językowej.

Inżynierowie oprogramowania często intensywnie współpracują i pracują nad zdefiniowaniem wszelkich możliwych przypadków brzegowych, a także starają się przewidzieć każdy możliwy błąd, z jakim mogą się spotkać, jeszcze przed napisaniem jakiegokolwiek kodu. Idąc o krok dalej, inżynierowie oprogramowania napiszą kod, który testuje kod, który piszą. Dzięki temu mogą natychmiast wyizolować problem i bezpieczniej przekazać kod.

Umiejętności inżyniera oprogramowania w zakresie projektowania systemów mogą być przerażająco dobre. Często potrafią przetłumaczyć proste systemy, którymi możemy się ze sobą komunikować jako ludzie (np. gra pacman), na tłumaczenie zrozumiałe dla komputera. Jeśli nie wiesz, komputery potrafią mówić tylko binarnie (01001000 01001001). Nie będziemy omawiać, w jaki sposób dość czytelny kod jest przekształcany na kod binarny, ponieważ jest to niezwykle obszerna dyskusja.

Mogę bez przerwy opowiadać o szerokim zakresie talentów i obowiązków inżyniera oprogramowania, ale wolę mówić o wadach pracy z inżynierem oprogramowania, a mianowicie: są kosztowni! Tak jak powinno być; są to ludzie, którzy potrafią realizować pomysły w nieskończenie skalowalnej i rozszerzalnej infrastrukturze. Rozwój z inżynierem oprogramowania może być znacznie wolniejszy, szczególnie na początku. Z czasem inżynier oprogramowania może zbudować tak solidną infrastrukturę techniczną, że może przyspieszyć rozwój do prędkości, która zszokuje nawet akcjonariuszy.

Zostanie inżynierem oprogramowania jest trudne, ponieważ jego praca to znacznie więcej niż nauka tajników języka. Istnieją koncepcje, które należy zrozumieć i odpowiednio zastosować w każdym scenariuszu. Musisz udowodnić, że potrafisz samodzielnie projektować systemy i potrafić dobrze komunikować swoje rozwiązania za pomocą dokumentacji i bezpośredniej komunikacji podczas współpracy. Inżynierowie oprogramowania wiedzą, że nie wiedzą wszystkiego, ale wiedzą też, że mogą się wszystkiego nauczyć.

Podsumowanie

Pomijając dziwny odwrócony trójkąt, mam nadzieję, że udało mi się skutecznie przekazać moje przemyślenia na temat różnic między tymi rolami. Chociaż dział HR może mieć dla Ciebie kod stanowiska, który nie odzwierciedla Twoich umiejętności, miejmy nadzieję, że możesz użyć tego trójkąta, aby określić, gdzie jesteś i gdzie chciałbyś być. Mam również nadzieję, że ten artykuł zapewni dobrą perspektywę i pomoże każdemu, kto szuka kogoś do „napisania kodu”. Zdecydowanie istnieją skuteczne przypadki użycia dla każdej warstwy trójkąta. Naprawdę nie musimy też zaczynać zawstydzać ludzi, jeśli nie widzą różnicy.