bookmark_borderProgramiście zawsze wiatr w oczy

Zarabiają te 15k, w pracy się nie spocą i co oni wiedzą o życiu… Poszliby do prawdziwej roboty, wstali o czwartej rano, wymrozili łapy, to by dopiero zrozumieli. I jeszcze narzekają. Że Fifa z zeszłego roku, że owocowe czwartki w pandemii nie wjeżdżają pod drzwi home office, że rekruterka pomyliła im imię… Ech.

Ja wiem, ja wiem, że nie mamy prawa narzekać. Kto jak kto, ale nie my, programiści. Jednak narzekanie to nasz sport narodowy. Pękłbym nie narzekając od czasu do czasu. Chcecie bym pękł?

Continuous deployment

O Jezu, jak miało być pięknie! Deploye miały się robić same, zły kod nie wchodzić na produkcję, bo testy automatyczne. A w ogóle to będziemy deployować trzy razy dziennie na produkcję, bo przecież w razie czego naprawimy za 5 minut.

Srali muchy będzie wiosna, trawa po kolana rosła!

Skonfigurowanie continuous deploymentu dla projektu legacy rozwijanego od 10 lat przypomina zadanie pytania na StackOverflow. Niby można. Wydawać by się nawet mogło, że to dobry pomysł. Jednak ilość pułapek, w które możemy wpaść sprawia, że z każdą kolejną godziną wykonywania tej roboty tracimy zapał. Co chwila i coraz szybciej spadają nowe klocki w tej układance, a my nie nadążamy ich układać. Tetris. Wygrał ktoś w to kiedyś?

Testy automatyczne – wspaniałość. Mokry sen inżyniera oprogramowania. Tyle tylko, że jakoś nikomu się ich nie chce pisać, a nawet jak chce to okazuje się, że aby się wszystko trzymało kupy nie wystarczą szybkie testy jednostkowe, ale powolne integracyjne. I wtedy na zakończenie builda czekamy tyle, że i trzy stoliki do piłkarzyków oraz pięć konsol nie rozładuje kolejki.

Deploye na produkcję trzy razy dziennie – to już była obietnica taka, że trochę nie wierzyliśmy od początku. I słusznie. Albowiem jak pisał poeta – nie udało się oddzielić dokładnie kodu od bugu, i wchodził na produkcję z nutką fakapu i commitem błędu. Poza tym proponuję przekonać kogokolwiek w bankowości do wdrożeń co trzy godziny.

Chmura

Będziemy sobie konfigurować infrastrukturę! Oh yes! Po co czekać na to aż admini zrobią nam serwer. Klikniemy trzy razy i… mamy fakturę na 50 tysięcy euro!? Bo Marek zapomniał wyłączyć te instancje, a potem się zwolnił i nikt o nich nie wiedział? Przecież to więcej niż 3 jego pensje. Olaboga.

Albo na przykład chcemy mieć chmurę, ale prywatną, bo mamy wrażliwe dane. Oczywiście deweloperzy będą mogli sobie sami wnioskować o zasoby, ale żeby niektóre z nich utworzyć będzie trzeba złożyć wniosek w ServiceNow z SLA 10 dniowym. Na resztę nałożymy korpo ograniczenia, żeby przypadkiem bitcoinów nie kopali sobie na dev instancjach, więc będzie wszystko działać wolniej niż przed chmurą. Ale elastyczność będzie. Quid pro quo.

Agile

Nie możemy planować przez dwa tygodnie rocznego projektu. W tym czasie biznes może się zmienić, a my musimy stać się zwinni i adaptować. Będziemy dostarczać co dwa tygodnie nowe funkcjonalności. Będziemy codziennie mówić nad czym pracujemy. Będziemy zmotywowanym efektywnym zespołem i będziemy dostarczać wartość biznesową.

Więc mówimy co rano… robiłem to samo co wczoraj i dzisiaj będę kończył, a poza tym to byłem na spotkaniu pół dnia.

Planować przez dwa tygodnie rocznego projektu nie możemy, ale planować przez cztery godziny dwutygodniowy sprint to już jak najbardziej. Po trzech miesiącach okazuje się, że jest reorganizacja i wszystko co zrobiliśmy idzie do piachu, więc zaczynamy od nowa. Oczywiście nadal jesteśmy zmotywowanym i efektywnym zespołem. W końcu co dwa tygodnie robimy demo. Ostatnio pokazaliśmy nowy przycisk na formularzu. Biznes był pod wrażeniem.

Podsumowanie

Oczywiście nie jest tak, że agile, chmura, czy continuous deployment są same w sobie złymi pomysłami. Wręcz przeciwnie, wynikają z historycznych uwarunkowań i rozwiązują dawne problemy. Dziś natomiast, nie pamiętamy już bolączek wczorajszych, za to doskwierają nam dzisiejsze. Przyznam jednak, że martwi mnie dość mocno jak pewne wspaniałe pomysły ulegają wypaczeniu w praktyce. Rozwiązania chmurowe potrafią naprawdę usprawnić pracę programisty, ale ich natura wymaga sporego zakresu swobody, którą często korporacyjne środowisko sprowadza do minimum. Odbiera to czasami sens całej transformacji. Stają się one tylko zmianami sterowanymi modą, trendami. Wszyscy mają chmurę, mam i ja!

Podobnie z Agile. W niektórych, szczególnie mniejszych organizacjach, widywałem ducha zwinności. Myślano tam jak zrobić coś prościej, jak implementować szybko, bez zbędnej komplikacji i narzutu. Natomiast w dużych projektach i firmach było z tym o wiele, wiele gorzej. Dużo więcej za to mówiło się o samej zwinności. Praktyka jednak była od niej dużo dalej.

Continuous deployment to natomiast przesadne oczekiwanie. Sam proces automatycznych wdrożeń, w połączeniu z testami jest niezwykle korzystny, pomaga nie tylko unikać błędów, ale też chroni przed niebezpiecznymi różnicami w środowiskach poszczególnych developerów. Natomiast obiecywanie biznesowi, że będziemy wdrażać na produkcję kilka razy dziennie to już ułańska fantazja, trzeba przyznać. Przynajmniej w większości firm.

bookmark_border7 oznak, że twój zespół jest zdemotywowany

Zdemotywowany zespół programistów to utrapienie. Kosztowne i nieprzyjemne. W przeciwieństwie do pracy fizycznej, którą latami wykonywano pod przymusem bata, praca umysłowa jest ciężka lub niemożliwa do wyegzekwowania siłą…

Oto siedem oznak, że zespół jest zdemotywowany:

1. Nierozmowność

Na spotkaniach on-line większość osób milczy, na spotkaniach na żywo bawią się telefonami.

2. Reaktywność

Członkowie zespołu zachowują się reaktywnie – nie wychodzą z inicjatywą, ale czekają na polecenia.

3. Wychodzenie jak najwcześniej, przychodzenie jak najpóźniej

Nie lubiąc pracy ludzie próbują spędzać w niej jak najmniej czasu – przychodzą idealnie o dziewiątej, wychodzą zaś punkt piąta. O ile robi tak jedna osoba, może to znaczyć, że mamy do czynienia z kimś bardzo zorganizowanym, jednak, jeśli wszyscy pracownicy uciekają pod koniec dnia jakby w biurze wybuchał pożar – wiedz, że coś się dzieje.

4. Częste obserwowanie zegarka, patrzenie za okno, przesiadywanie w kuchni, w toalecie

Każdy sposób jest dobry, by uciec od pracy, której się nie lubi. Kawa co godzina, siku co pół godziny, spacer do chillroomu trzy razy dziennie.

5. Bezproduktywność

Ostateczny skutek demotywacji – po prostu praca nie jest zrobiona albo jest zrobiona w absolutnie minimalnym stopniu.

6. Brak ochotników

Szef przychodzi do zespołu i szuka ochotników. Wszyscy patrzą w monitory, nikt nie podnosi ręki. Maciek wychodzi do toalety. Magda do kuchni. Bartek nawet nie zdjął słuchawek.

7. Absencja

Urlopy na żądanie, L-quattro, bóle głowy, menstruacje, kace, cokolwiek. Nie lubiąc miejsca pracy ludzie próbują z niego uciekać. Choćby jeden dzień bez patrzenia na ten nieszczęsny projekt jest dla nich wybawieniem.

***

Objawy demotywacji to jednak niekoniecznie problem jedynie zespołu. Łatwo jest zrzucić winę na konkretnych ludzi, na projekt, na kierownika. Wydaje się jednak rozsądniejszym, by spojrzeć na sprawę analitycznie. Może inne zespoły utrudniają naszemu pracę? Może walczą między sobą? Może procedury w przedsiębiorstwie są nieznośne? Może płace niskie? Może słaby sprzęt przeszkadza w pracy? Demotywacja jest jak gorączka. Trzeba ją zwalczać, by nie zabiła, ale też trzeba poznać jej przyczynę, bo faszerowanie się lekami przeciwgorączkowymi bez diagnozy może doprowadzić do tragedii.

bookmark_borderZalety programowania w parach

Programowanie w parach jest prostym i starym pomysłem, kojarzonym z technikami zwinnymi, w szczególności z extreme programming. Posiada sporo zalet, a mimo to obecnie jest omal nieużywane w projektach zdominowanych przez scrum. Czy słusznie?

Nie trzeba chyba pisać, że programowanie w parach polega na programowaniu w parach. Dwóch programistów siada przed jednym komputerem i razem pracują nad fragmentem kodu. Zwykle jeden więcej pisze, a drugi komentuje, ale nic nie stoi oczywiście na przeszkodzie, by wymieniać się klawiaturą i myszą od czasu do czasu. Co w tym takiego interesującego? Otóż ciekawe rzeczy dzieją się, kiedy posadzi się dwóch koderów obok siebie…

Po zerowe – rosną koszty “w Excelu”. Dwóch programistów siedzi nad jednym zadaniem! Toż to przecież jakby dwóch glazurników, dwóch hydraulików sobie rury, kafelki podawało i jeszcze gawędziło przy tym, zamiast robić równolegle. Koszmarna strata czasu, z perspektywy zarządzających, którzy nie dość dobrze znają specyfikę pracy programistów. Tylko, że jednak nie do końca tak jest, bo kodząc w parach programiści…

…obserwują się wzajemnie podczas pracy. To znaczy, że się uczą. Czasami rzeczy przydatnych, czasami trików. Swego czasu z kolegą w jednej z firm programowałem w parze. Zauważył on, że zamykam okno w Windows dwoma kliknięciami w lewy górny róg. Tak go to zaskoczyło, że zaczął chodzić po biurze i pytać innych, czy znali ten sposób. Co dla mnie dziwne niewiele osób go kojarzyło, co tym mocniej zachęcało go do odwiedzania kolejnych biurek. Nie jest to rzecz jasna przykład chwalebny, ale anegdota pokazująca, że pracując nawet wiele lat z jakimś narzędziem możemy nie czegoś nie dostrzegać. Wielokrotnie miałem okazję coś u kolegów i koleżanek podpatrzyć. I zawsze wpływało to pozytywnie na moje umiejętności.

Obserwowanie własnej pracy to nie tylko uczenie się trików. To także korygowanie szkodliwych nawyków. Sami możemy nie zauważyć, jak wiele czasu marnujemy na pewne czynności, dopóki ktoś inny nie zwróci nam uwagi, że można to zrobić lepiej, szybciej, prościej, wydajniej. Programując w parach uczymy się sprawności w działaniu, korygujemy się wzajemnie. To wielka wartość. Naprawdę. Programowanie to nie pisanie literek na klawiaturze, ale myślenie i nauka. Dlatego im szybsza edukacja, tym lepszy programista, tym sprawniejszy zespół.

Po drugie (pierwsze było po zerowym oczywiście) co dwie głowy to nie jedna i szybciej można wyłapać błąd. Błąd to taki nowotwór jest. Jak jest mały, no dwie komórki, trzy linie kodu, to cyk skalpelem, dwa kliknięcia, spacja i po kłopocie. Jednak jeśli się rozrośnie, jak poczekamy dwa lata to już będzie nie lada operacja. A jak przetrwa piętnaście lat, to już nikt go nie ubije, tego buga, za to bug może ubić produkt, czyli nosiciela. Po to robimy zresztą code review – żeby szybko bugi ubić. Jednak nic nie ubija buga szybciej, niż zauważenie go w momencie pisania kodu. Do tego trzeba jednak pisać kod we dwójkę.

Po trzecie kod jest jak podręcznik. Nikt nie lubi niezrozumiałych, bełkotliwych książek, z których nie idzie się dowiedzieć o co chodzi. Tak samo programiści nie lubią kodu, którego nie można zrozumieć po pierwszej lekturze, ale trzeba nad nim ślęczeć jak na wierszami Norwida. Jak mamy akurat Cypriana w zespole, to trzeba go okiełznać, bo się za pół roku nie połapiemy i będziemy jęczeć, że ideał naszego kodziku sięgnął bruku. Oczywiście code review da radę, ale można tam dyskutować dniami i sprintami, a we dwójkę przy kawie i jednej klawiaturze jest szybciej.

Po czwarte motywacja. Miałem w jednej pracy kolegę, który opanował do mistrzostwa sztukę zasypiania na siedząco. Oczywiście trzeba być empatycznym i jak ktoś ma akurat małe dziecko albo problemy życiowe, to niech śpi, na zdrowie, ale akurat ów koder był dość młody, bezdzietny i jego problemy polegały na grze do późna na plejce. Generalnie ciężko jest spać, jak ktoś siedzi przy naszym biurku. Ciężko też oglądać filmiki na YouTube, kupować na OtoMoto auto, a już najciężej wysyłać CV, bo i to podobno niektórzy robią. Programowanie w parach motywuje. Chcemy się wykazać, nie możemy się obijać – działamy sprawniej. Dlatego też zresztą trzeba stosować z umiarem, a nie osiem godzin dziennie, bo każdy potrzebuje odrobiny samotności w tłumie openspace’u przy własnym biurku. Natomiast godzina, dwie, może trzy dziennie mogą być zdrowo pobudzające.

Dużo zalet, mówiąc krótko. Czemu tak mało popularna ta technika? Sądzę, że scrum ma tu coś do rzeczy – nie można się choćby o ile mi wiadomo przypisać we dwójkę do jednego zadania. Również perspektywa nietechnicznego product ownera może być negatywna – z pozoru we dwójkę programiści zrobią więcej. Praktyka pokazuje, że zrobią więcej, ale bugów, ale to już ciężko zauważyć nie będąc na linii frontu. Wydaje się także, że sami programiści często nie przepadają za pracą w parach – boją się konfrontacji, nie chce im się tak aktywnie spędzać czasu, nie widzą takiej potrzeby, nie lubią tego. W sumie przywykliśmy wszyscy do pisania w pojedynkę. Osobiście jednak zachęcam, gorąco zachęcam do programowania w parach. Daje to zaskakująco wiele i zdecydowanie warto jest przynajmniej spróbować.

bookmark_borderDług techniczny / technologiczny – co to jest i czym grozi?

Jak mówi przysłowie – jeden obraz wart jest więcej niż tysiąc słów. Czym jest dług techniczny? Tym właśnie co na obrazku powyżej. Jest tymczasowym rozwiązaniem, które w miarę upływu czasu stało się problemem.

Czasami dług techniczny jest małym, czasami dużym zaniedbaniem. Im dłużej jednak zwlekamy z doprowadzeniem spraw do porządku, tym większe ryzyko, że nastąpi eksplozja, w wyniku której nasz projekt albo nasza firma pokryje się warstwą cuchnących ekskrementów. Bowiem dług technologiczny (czy też dług techniczny) jest w istocie jak dług – im dłużej odroczymy płatność, tym więcej odsetek przyjdzie nam zapłacić.

Można by zapytać – kto byłby tak bezmyślny, nieroztropny, niedbały i beztroski, by pozostawiać jakieś tymczasowe rozwiązanie na dłuższy czas! I słuszne byłoby to pytanie. I uzasadnione byłoby to oburzenie. Tyle tylko, że jak mówi programistyczna mądrość – tymczasowe rozwiązania są najbardziej trwałe. Czemu?

Bywa, że nie ma czasu. Bywa, że nie ma zasobów, sił. Albo jednych i drugich brak jednocześnie. Gdy tymczasowe rozwiązanie już powstanie, nie ma znów sił i czasu oraz zasobów, by się go pozbyć i zrobić rzecz zgodnie ze sztuką. Goni nas kolejny deadline, pojawia się następny projekt, a krótkotrwałe obejście, „hack”, żyje swoim życiem… Przez lata czasami, aż nie stanie się niebezpieczne, aż nie zagrozi biznesowi.

Dług techniczny, dług technologiczny istnieje w każdym projekcie IT. W innych formach zjawisko to pojawia się wszędzie. W naszym domu, kiedy zaczyna istnieć jakiś kąt, gdzie rośnie nieporządek – jak w przysłowiowym zamiataniu pod dywan – rośnie, rośnie, aż w pewnym momencie orientujemy się, że w całym mieszkaniu jest bałagan. W naszym ciele, kiedy kilka komórek wymyka się spod kontroli i zaczyna mnożyć, a po latach okazuje się, że lekarz diagnozuje nowotwór. Jak również w biznesie – na przykład, kiedy pracownik w podeszłym wieku, zajmujący się od lat częścią jakiegoś istotnego procesu biznesowego przechodzi na emeryturę lub umiera, a wraz z nim ginie wiedza i umiejętność wykonywania zadań, które okazują się kluczowe. I nagle cała firma wpada w tarapaty.

Dług technologiczny to ziarno chaosu. Odpowiedzialnością programistów oraz kierowników IT jest kontrolowanie go, niedopuszczanie do jego nadmiernego rozrostu. W przeciwnym wypadku, jeśli tylko pozwolimy mu wypuścić pędy, zapuścić korzenie, dług techniczny nas zniszczy – naszą pracę, naszą firmę, nasze życie. Nie pozwólmy mu rosnąć…

bookmark_borderPułapka 15k

Programista 15k – legenda polskiej branży IT, wzorzec sukcesu wykonany ze stopu pracowitości (90%) i pychy (10%), przechowywany w Raszynie pod Warszawą. To o nim pisane są artykuły o clickbaitowych nazwach. To przed nim drżą korporacyjne budżety. To o nim myśli rodzina, gdy słyszy, że jesteś programistą. Jak piękne jest życie programisty 15k? Czy jest usłane najczulszymi płatkami róż, oddzielonymi starannie od kolców?

Jak wykuwa się 15k

Programista 15k, wyjaśnijmy na początek nieświadomym, to osoba zarabiająca w tym zawodzie 15 tysięcy zł. Nomenklatura nie precyzuje, czy brutto, czy netto, czy B2B, czy UoP, ale bez względu na to, są to bardzo przyzwoite pieniądze w naszym nadwiślańskim kraju. Pieniądze pozwalające żyć wygodnie.

Programista taki – spróbujmy go scharakteryzować – z pewnością jest doświadczony. To nie jest osoba z rocznym czy dwuletnim, lecz raczej kilku, kilkunastoletnim doświadczeniem, oscylującym w okolicy 10 lat. Jest to koder, który z niejednego repozytorium klonował kod. Zna dobrze kilka technologii, umie się porozumieć z biznesem, ma dobrą prezencję. Jego CV imponuje i uwodzi rekruterów.

Co robi?

Ciężko powiedzieć co w zasadzie tak konkretnie robi programista 15k, bo oferty o wysokich stawkach pojawiają się właściwie w każdej specjalizacji. Obecnie najczęściej będą to specjaliści DevOps (o ile można ich nazwać programistami). Bycie full-stackiem jest dobrą ścieżką w kierunku 15k. Jednak również backendowcy, czy frontendowcy znajdą oferty pozwalające na dołączenie do tego elitarnego grona.

Jedno jest pewne co do zadań stojących przed takim koderem – albo musi być wybitny, a projekt jest nieprzeciętnie wymagający albo musi być doświadczony i dobry, a projekt jest nudny, nużący lub mało perspektywiczny, ewentualnie ryzykowny. W życiu nie ma nic za darmo. Pierwsza opcja jest oczywista, wymagający projekt wymaga nietuzinkowych koderów, a tych jest niewielu i mogą dyktować warunki. Efektem jest wysoka płaca.

W czym więc problem?

Problemem jest drugi przypadek – projekty nudne, żmudne, mordercze. Tak miażdżące programistów, że uciekają z firmy. Rośnie rotacja. Wdrożenie nowych zajmuje czas, a przy okazji znika z przedsiębiorstwa i projektu wiedza. Trzeba temu przeciwdziałać. Przekupujemy więc kolejnych kandydatów. Sprawiamy, że nigdzie indziej nie dostaną więcej i ich wytrzymałość na frustrację wzrośnie, bo ciężko jest jednak dobrowolnie zrezygnować z dajmy na to jednej trzeciej zarobków.

Jest co prawda jeszcze jedna możliwa ewentualność– potrzeba szybkiego zatrudnienia dużej ilości pracowników. Wtedy, by zachęcić kandydatów do natychmiastowej decyzji podbija się stawki, to jednak krótkotrwała i tymczasowa sytuacja…

W czym zatem problem? Otóż wbrew pozorom jest ich kilka.

Po pierwsze pieniądze. Owe 15 tysięcy to dużo i mało jednocześnie. Dużo, bo stanowi omal sufit wynagrodzeń w IT, a jednocześnie pozwala na wygodne życie. Do wygodnego życia łatwo się przyzwyczaić. Z kolei przez lata podwyżek i awansów programiści przywykli do stopniowego zwiększania dawek najbardziej uzależniającego z narkotyków. Programista 15k chciałby się zatem w jakiś sposób rozwijać, ale właściwie nie ma takiej możliwości. Rozwój finansowy? – nie może znaleźć lepiej płatnej pracy. Rozwój techniczny? – musi zrezygnować z pieniędzy, by zdobywać doświadczenie.

Jedyne możliwości zmiany sytuacji finansowej na lepszą to założenie własnej firmy lub zostanie managerem (co może tymczasowo znacząco obniżyć wynagrodzenie). Alternatywą jest trwanie na stanowisku, które oferuje dobre pieniądze, ale eroduje umiejętności, często przy tym krusząc duszę. Ludzie natomiast – a szczególnie ludzie, którzy od lat szli w górę – zawsze chcą więcej. Pojawia się wówczas frustracja.

Ten ból widoczny w oczach obserwowałem parokrotnie. Tych biednych, bystrych koderów, którzy przeszli już cały labirynt i nie znaleźli wyjścia. Kolejne projekty w weekendy, podcasty, szkolenia, inwestycje, wszystkie te próby przebicia sufitu sprawiają, że część z nich gorzknieje. Młodzi programiści, u progu kariery, mają błysk w oczach, nadzieję na tłuste lata, na wzrost, rozwój. Doświadczeni mają niestety często zmęczenie i strach w tych mądrych, dojrzałych oczach – strach, że nic ich już nie czeka, poza kolejnymi sprintami, buildami i bugami.

Bowiem IT to wbrew pozorom branża marzycieli. W wielu z nas tkwią nadal nastoletni chłopcy zafascynowani potęgą komputerów. Jedni z pokolenia, które obserwowało przegraną Kasparova z Deep Blue, inni z pokolenia, które patrzyło na szok i desperację Lee Sedola, gdy zwyciężało go AlphaGo. Każdy z perspektywą, że już niedługo zbudujemy RoboCopa, a najlepiej Motoko Kusanagi z Ghost In The Shell – że spod naszych palców wyjdzie kod przełomowy, że oprogramujemy autonomiczne samochody i inne genialne gadżety. Programiści 15k to zwykle ci, którzy wiele już napisali, a mało z tego co napisali sprawiło im prawdziwą dumę (mimo, że było wartościowe dla gospodarki). To ci, którym do emerytury pozostało trzydzieści lat, a którzy nigdy już w swoim zawodzie nie awansują, to ci, którzy umieliby napisać coś ambitnego, ale nie mają w Polsce takich projektów, to ci którzy stanęli na szczycie i mimo, że są szczyty wyższe, to muszą z niego zejść, przeprawić się przez rzekę i zacząć wspinać się na kolejny, inny, a sił im już brak…

bookmark_borderCzy Angular umiera?

Angular.js był przełomowym frameworkiem, który zredefiniował nasze myślenie o front-endzie i znacząco podniósł produktywność. Kolejna jego wersja, łamiąca kompatybilność oraz opublikowana z poślizgiem otworzyła pole do ekspansji Reacta. Czy Angular zaprzepaścił swoją szansę na dominację? Czy Angular umiera?

Portal The State of JavaScript publikuje regularnie świetne raporty na temat ekosystemu współczesnego JavaScriptu. Analizowana jest popularność i satysfakcja z używania front- i back-endowych frameworków, bibliotek do testowania oraz zarządzania stanem i danymi w aplikacji.

Wzmianki o Angularze nie są optymistyczne. Poniżej diagram zainteresowania frameworkiem, ukazujący wyraźny trend spadkowy:

malejace zainteresowanie angularem

Tutaj z kolei widzimy spadek satysfakcji z pracy z Angularem:

Zadowolenie z pracy z frameworkiem jest według raportu The State of JavaScript tak niskie, że większość programistów, która ma z nim doświadczenie nie chce go ponownie używać. 21.9% ankietowanych osób zna i lubi Angulara, ale kolejne 35.8%, które również Angulara używało nie chce tego robić w przyszłości.

Aż 32.4% osób nie jest zainteresowanych zaznajomieniem się z frameworkiem.

satysfakcja pracy z angular

Statystyki NPM wydają się być dla Angulara równie nieubłagane:

Warto zauważyć, że Angular nie tylko nigdy nie dogonił popularności Reacta, przynajmniej w tym zestawieniu, ale wręcz stracił przewagę nad Vue.

Na polskim rynku pracy wyraźnie dominuje React i Angular, aczkolwiek w ostatnich miesiącach daje się zauważyć zarówno pączkowanie ofert z Vue, jak i bardzo dobrze płatne oferty z Angulara. Może to świadczyć o spadku popularności tego drugiego – być może developerzy nie wierzą już we framework i nie chcą z nim pracować, dlatego trudno znaleźć chętnych do pracy i podbija to stawki. Możliwe też jednak, że Angular lepiej się przyjął w środowisku dużych korporacji, które mają potężne budżety…

Ciężko o jednoznaczną opinię i wyrok. Nie czas może jeszcze stawiać kreskę na Angularze, ale warto być czujnym i obserwować rynek.

bookmark_borderPrototyp, głupcze!

Tworzenie oprogramowania jest jednym z najbardziej złożonych przedsięwzięć, jakich podejmuje się nasza cywilizacja. Nie dotyczy to co prawda każdego projektu, istnieją rzeczy proste, trywialne, ale nawet za nimi ciągnie się ogon bibliotek, systemów operacyjnych, procesorów i całej koncepcji programowania, wraz z algorytmami, maszyną turinga i językami formalnymi. Są jednak również projekty same w sobie niezwykle skomplikowane – systemy tradingowe, symulacje fizyczne, oprogramowanie symulujące zwijanie białek…

Rękodzieło

Mimo całej tej złożoności, jest w programowaniu duch rękodzieła.

Pracujemy nieraz nad arcydziełami koronkowej abstrakcyjnej twórczości, rozpiętymi na setki tysięcy linii kodu w sposób jakbyśmy toczyli wazę za czasów dynastii Han.

Poniżej przykładowa waza. Piękna rzecz, ale od czasu panowania dynastii Han, 206 BC–220 AD, trochę czasu minęło…

Co złego w toczeniu wazy? Niby nic. Tyle, że w przypadku wazy można, jak sądzę, nadać jej jakiś początkowy kształt, a potem malować kolejne fragmenty nieco improwizując. Tutaj smok, tam feniks, jakiś ornamencik.

I często wychodzi ładnie.

Gorzej jednak, kiedy przełożymy to na programowanie. Robimy jakieś MVC, tam dwa przyciski, tu jakiś dropdown, pod spodem kontrolerek i repozytorium i jakoś to będzie.

I czasami wychodzi ładnie.

Warto by jednak było, zanim zaczniemy implementować, lepić, klecić i klepać, zastanowić się, co tak w zasadzie system ma robić. Bo co waza ma robić, to wiadomo, a czy będzie miała dwa smoki i i trzy feniksy, czy też pięć ornamentów i jednego smoka, to już detal, o ile się je ładnie namaluje. Trochę też krócej się tworzy taką wazę. Gorzej jednak, jak w trakcie lepienia naszej wazy-MVC przychodzi klient i mówi, że chce czajnik. I jeszcze raz za dwa tygodnie i dodaje, że elektryczny…

Agile w dwójnasób

Wydawać by się mogło, że brak planu na początku projektu może wynikać z dominacji Agile na rynku. Promuje ona tworzenie jak gdyby ad hoc, w krótkich odcinkach czasu. Sądzę jednak, że brak planu to coś naturalnego, amatorskiego. Tak projekty tworzą studenci. Siadają do kompilatora i próbują. Próbują, piszą, nie planują. Miło jest coś zacząć, dać się pochłonąć entuzjazmowi. Mniej sympatycznie jest tworzyć plan, analizować, przewidywać problemy, a potem tego planu się trzymać.

Jest taka słynna grafika w świecie Agile. Ilustruje tworzenie MVP na przykładzie budowania samochodu. Znalazłem swego czasu ciekawszą:

Przez pewien czas sądziłem, że w istocie jedynie dolny rysunek ukazuje właściwą drogę, a tradycyjny przykład z hulajnogą, rowerem, motocyklem i samochodem jest błędny.

Tymczasem oba są poprawne. W zależności jednak od sytuacji.

Wyróżniłbym dwa modele tworzenia produktu:

  • kreatywny
  • konserwatywny

Produkt tworzony kreatywnie może wyewoluować w dowolnym kierunku. Przykładowo – projektujemy pierwszy smartphone. Nie wiemy jak ma wyglądać. Produkt może ewoluować znacząco, a feedback od klienta jest kluczowy i ma prawo kompletnie zmienić produkt.

Produkt tworzony konserwatywnie jest czymś, co już istnieje na rynku i nie planujemy go rewolucjonizować (albo czymś coś wręcz wiemy jak ma wyglądać, bo wynika z regulacji rynku, ustawy itp.). Chcąc zbudować nowy model samochodu nie ma sensu tworzyć hulajnogi. Możemy poeksperymentować z nadwoziem, wyposażeniem, ale nie z samą koncepcją auta.

Prototyp

Wydawać by się mogło, że prototypowanie jest czymś oczywistym. Pisarze tworzą pierwsze szkice, które potem udoskonalają, ubierają w szczegóły, a czasami zupełnie przerabiają. Malarze zwykle zaczynają obraz od zarysowania głównych jego elementów, również tworząc na początku coś w rodzaju prototypu. Projekty samochodów zawsze zaczynają się od produkowanych w jednym, czy kilku egzemplarzach wersji demo. Tymczasem w oprogramowaniu bywa różnie.

Widziałem projekty, gdzie nigdy niczego nie prototypowano. Proces tworzenia oparty był o pełną implementację w każdym sprincie. Zupełnie bezrefleksyjnie marnotrawiono czas, choć można było narysować na kartce propozycje rozwiązań i dojść do konsensusu miesiące szybciej.

Moim zdaniem każda aplikacja, która posiada interfejs graficzny (co stanowi sporą część, jeśli nie większość rynku) MUSI zacząć się od designu, następnie przejść w „klikalny” prototyp, by w końcu zostać w pełni zaimplementowana.

Stworzenie designu ułatwia zrozumienie produktu i zadawanie właściwych pytań. Większość osób jest wzrokowcami i potrzeba im wizualnej reprezentacji tego, nad czym mają podjąć pracę.

Prototyp z kolei pozwala dostarczyć klientowi coś namacalnego w czasie o wiele szybszym od pełnej implementacji. Rozwiązuje to frustrację biznesu związaną z czekaniem na pierwszy rezultat. Nic pewnie nie irytuje bardziej, niż słuchanie przez dwa miesiące technicznych sprawozdań bez możliwości ujrzenia wyniku pracy, jeśli zainwestowało się kilkadziesiąt lub kilaset tysięcy złotych w rozwój produktu.

W wielu firmach specialiści od UI i UX są bagatelizowani lub w ogóle się ich nie zatrudnia. To błąd. To gigantyczne przeoczenie. Ich praca to nie tylko rysowanie okienek – ich wysiłek ułatwia wszystkim zrozumienie produktu oraz pracę nad nim. Projekty zaczynajmy od szkicu, designu, przechodźmy do prototypu, a kończmy na implementacji!

bookmark_borderNienawidzę programistów, tych książąt, nierobów

Pandemia COVID-19 odsłoniła zarówno piękne, szlachetne, jak i ponure cechy rodzaju ludzkiego. W dobrych czasach łatwo być miłym. Stąd przecież mądre powiedzenie, że przyjaciół poznaje się w biedzie. Wrógów również w biedzie się poznaje.

Od kilku już lat dało się słyszeć głosy krytyki wobec programistów w Polsce. Słynny już artykuł „IT arystokracja” wszedł do słownika frazeologicznego naszego pokolenia. Przyprawiono w nim programistom gębę rozwydrzonych dzieciaków klikających w komputer i zarabiających piętnaście tysięcy na rękę. Nomen omen – programista15k stał się równie nośnym hasztagiem, co IT arystokracja hasłem.

Póki bezrobocie malało, a gospodarka rosła, było to jeszcze do przełknięcia dla większości osób spoza branży. Obecnie jednak, gdy wykluczenie z rynku wielu branż zasiało panikę, a na horyzoncie tli się gospodarcza pożoga – łaska dla IT się skończyła.

W coraz większej ilości miejsc czytam zjadliwe komentarze:

  • wam to łatwo mówić, bo sobie pracujecie zdalnie
  • w końcu się skończy eldorado dla programistów
  • teraz i wam się dostanie, książęta z IT
  • wywalą was to się przekwalifikujecie na magazynierów i zobaczycie jak życie wygląda
  • w kryzysie widać kto nic nie robi i jest zbędny
  • skoczą się konsole i piłkarzyki

Gorycz wykrzywia usta, bo nie czuję, by programiści otrzymywali swoje wynagrodzenia bezprawnie, żeby te pieniądze gwałtem, przemocą wyciągali od Bogu ducha winnych ludzi. Większość z nas ciężko pracowała przez ostatnie lata, uczyła się wytrwale nieraz przez dekady i wnosi solidny wkład w gospodarkę. Dzięki nam powstają systemy automatyzujące produkcję, ułatwiające pracę, dające rozrywkę. Posady w IT nie są państwowymi synekurami, ale miejscami, gdzie weryfikuje się umiejętności pracowników, nieraz bezlitośnie, w trwających godzinami testach. Programisci mojego pokolenia nie mieli nawet od kogo nauczyć się zawodu, bo ich ojcowie i matki programistami nie byli. Większość z nas to prawdziwi self-made mani.

Wielką szkodą jest, że społeczeństwo widzi w nas często jedynie rezultat naszych działań – mieszkanie, samochód, czy człowieka przed komputerem. Bardzo bym chciał, żeby dostrzeżono też lata studiów, dekady pasji i zaangażowania, skrzywione kręgosłupy, zaczerwienione oczy, młodość przed kompilatorami, wyrzeczenia, trud tej pracy łączącej w sobie wymagania wielu dziedzin (kreatywność, sumienność, matematyczny rygor, lingwistyczne zacięcie). I żeby nie zignorowano wpływu IT na jakość życia – tego, że dzięki programistom nie trzeba już stać w kolejce na poczcie po odbiór listu, w kolejce do okienka w banku, by wysłać przelew, że można rozmawiać z rodziną w UK na Skype, obejrzeć serial na żądanie, a nie w danej godzinie, słuchać dowolnej omal piosenki bez polowania na album w sklepie muzycznym i jechać przed siebie bez postoju i zaglądania w mapę oraz pytania przechodniów o drogę…

bookmark_borderProblem nazw w programowaniu

Czytanie kodu źródłowego jest trudniejsze, niż jego pisanie. Przyzna to każdy kto pracował z odziedziczonym repozytorium i próbował zrozumieć jego działanie. Przebijanie się przez tysiące linii kodu, przez setki definicji funkcji i zmiennych, w próbie zrozumienia co autorzy mieli na myśli jest ciężkim, męczącym, okrutnie wyczerpującym zadaniem.

Dlaczego tak jest?

Czy zrozumienie przepisu kuchennego jest trudne?

Czy jest trudniejsze od napisania go?

Czy zrozumienie przepisu kuchennego sprzed trzydziestu lat jest trudniejsze od zrozumienia przepisu sprzed tygodnia?

Nie sądzę.

Czemu więc czytanie kodu źródłowego staje się trudniejsze z każdym kolejnym miesiącem od jego powstania? Dlaczego nowy kod jest czytelny, a stary niezrozumiały? Jaka może być przyczyną „gnicia oprogramowania” i nienawiści do legacy code?

Zastanówmy się nad czynnością czytania kodu źródłowego. Co robimy próbując zrozumieć program, wgryźć się w kod?

Działamy jak komputery, tylko mniej wydajnie. Przeglądamy kod, czytamy go, napotykamy na zmienne i funkcje. Nie będąc maszynami nie jesteśmy w stanie spamiętać każdej wartości oraz ciągu konstrukcji. Próbujemy więc „zrozumieć” kod. Napotykając na nazwę zmiennej staramy się domyślić, co oznacza i w jakim kontekście jest używana. Nazwy funkcji lub procedur również próbujemy zrozumieć, najlepiej bez wnikania w ich treść.

Dokładnie tak samo działamy w świecie rzeczywistym. Gdy w przepisie napotykamy na słowo „marchew” wyobrażamy sobie marchew. Rozumiemy ideę marchewki bez zapoznawania się że szczegółami takimi jak jej masa, kolor, DNA, czy temperatura.

Kod źródłowy jednak – mimo starań obozu oprogramowania zorientowanego obiektowo – nie jest jak świat rzeczywisty. Odstaje od niego znacząco.

W świecie rzeczywistym dysponujemy ogromną, lecz ograniczoną ilością słów w naszych słownikach. Języki naturalne przetwarzane są przez ludzkie mózgi zupełnie inaczej niż kod źródłowy przez kompilatory. Krzesło na przykład to dla człowieka nie tylko konkretne krzesło, ale idea krzesła jako takiego. W większości przypadków zbędne nam są szczegółowe informacje na temat obiektów by przetwarzać i rozumieć język naturalny, w którego zdaniach te obiekty, reprezentowane przez słowa, występują. Tam z kolei gdzie jest nam potrzebna precyzja definicji (jak w prawie na przykład) napotykamy na spore problemy.

Świetnym przykładem ilustrującym, co by było gdybyśmy przetwarzali język naturalny tak jak komputery przetwarzają kod źródłowy jest ten filmik:

Wróćmy do czynności czytania kodu przez programistów. Cóż robi developer? Czyta nazwę zmiennej lub funkcji i próbuje zgadnąć, co ona oznacza. Póki kod jest „czysty” i niezbyt stary instynktowne zrozumienie jest stosunkowo poprawne. Czytanie idzie mu dobrze i praca z kodem jest sprawna.

Kłopot zaczyna się, gdy nie jest w stanie poprawnie domniemać znaczenia nazw.

Problem jest jednak znacznie poważniejszy. Jest to jedna z fundamentalnych trudności w rozwoju oprogramowania. Częściowo oddaje to poniższy cytat:

There are only two hard things in Computer Science: cache invalidation and naming things

Phil Karlton

Chodzi o nazewnictwo.

Nazewnictwo jest punktem styku pomiędzy światem maszyn i ludzi. Jest jednocześnie przepaścią między jednym, a drugim. W świecie rzeczywistym, gdzie język ludzki rozumiany jest przez mózgi, które są w stanie instynktownie zrozumieć klasy obiektów / idee przedmiotów rzadko tworzone są nowe słowa. W kodzie źródłowym nowe słowa tworzone są nieustannie.

Co dzieje się, gdy tworzymy nowe słowo w ludzkiej mowie? Uczymy się go. Powstaje nowe słowo – na przykład „komputer” – i wszyscy ludzie na świecie uczą się, że oznacza ono taką, a nie inną rzecz. Nie ma znaczenia, czy mowa o MacBooku, Dellu XPS, ENIACu, czy PC-cie. Nie tworzymy odrębnych słów opisujących komputery stojące w każdym z departamentów firmy, nie tworzymy innych słów na różne modele MacBooka mające inną wielkość pamięci RAM. Nie ma takiej potrzeby. Nowe słowa tworzymy rzadko. Za nowym słowem kryją się duże grupy obiektów. 

Inaczej jest w przypadku kodu źródłowego. „Użytkownik” znaczy co innego w każdym omal programie, jaki do tej pory napisano. W jednych jest to imię i nazwisko, w innych również data urodzenia, w jeszcze innych płeć. W niektórych imię i nazwisko może się składać tylko z liter łacińskich, w pewnych mieć maksymalnie 20 znaków. I tak dalej, etc.

Mówiąc krótko: w kodzie źródłowym niczego nie da się nazwać poprawnie. Żadna nazwa, jak dobrej byśmy nie wybrali, nie będzie odpowiadała znaczeniu słów wyjętych z języka naturalnego, ze świata ludzi.

Możemy być tylko zbyt precyzyjni („user”) lub zbyt ogólni („userWithNameAndSurnameAndSexAndDateOfBirth). Nigdy omal nie będziemy idealnie precyzyjni w nazywaniu zmiennych, czy funkcji. Nigdy te nazwy nie będą znaczyły tego, co nam się wydaje. Zawsze musimy nawigować się do definicji i czytać implementację. Za każdym razem, gdy dołączamy do istniejącego projektu musimy „nauczyć się jego języka”. Nauka nowego języka jest zawsze trudna, żmudna i męcząca. Dlatego właśnie, ze wszystkich wymienionych powyżej przyczyn, czytanie kodu źródłowego jest trudne.

bookmark_borderDlaczego programiści tak dużo zarabiają?

Zarobki programistów w Polsce obrosły legendą. Gazety rozpisują się o nich regularnie. Bywa, że w tonie chwalebnym, bywa, że w tonie nagannym. Jedni ich bronią, twierdząc, że programiści to pożyteczni specjaliści. Inni atakują – wyczekują pęknięcia „bańki” i zrównania zarobków z innymi zawodami. Wiele osób zadaje sobie jednak pytanie – dlaczego programiści zarabiają tak dużo?

Sytuacja w Polsce

Zacząć by należało od tego, że sytuacja w Polsce jest dość specyficzna. Większość osób zajmujących się w naszym kraju oprogramowaniem pracuje dla zagranicznych klientów. Napływ kapitału (głównie z Europy zachodniej) wzmożył popyt na programistów i w naturalny sposób podniósł cenę ich pracy. Kwestią otwartą jest, jak długo sytuacja ta potrwa, ale na pewno jest korzystna dla Polskiej gospodarki w tym sensie, że eksportujemy nasz talent techniczny otrzymując w zamian, mówiąc językiem PRLu, dewizy – czyli zagraniczne waluty, a także przy okazji importujemy zachodnie praktyki zarządzania projektami, doświadczenie organizacyjne i nawiązujemy kontakty biznesowe z bogatszymi krajami wspólnoty europejskiej.

Często mówi się, że w przeciwieństwie do innych zawodów, programiści w Polsce, pracując dla zagranicznych klientów zarabiają „po zachodniemu”. Prawdę powiedziawszy jest nawet lepiej. Pensje programistów w Portugalii, czy Włoszech są wręcz niższe, niż w Warszawie, czy innych dużych miastach Polski. Z drugiej strony średnie wynagrodzenia są nadal niższe niż w Berlinie, Paryżu, czy – szczególnie – Zurychu lub Nowym Jorku.

Sukces Polski (oraz szerzej – Europy wschodniej) wynika z wysokiego poziomu edukacji, bliskości kulturowej z krajami zachodu, niewielkiej odległości geograficznej, niezłej znajomości angielskiego oraz oczywiście niższych wynagrodzeń. Na chwilę obecną sytuacja wygląda tak, że kluczowe projekty odbywają się w centrach korporacji, te mniej istotne w krajach takich jak Polska, czy Rumunia, a te najbardziej kosztowo zoptymalizowane w Indiach. Ulotki dla inwestorów prezentują Europę środkową jako kompromis między jakością i ceną.

Z drugiej strony istnieje w Polsce pokaźna grupa programistów, którzy pracują za kwoty co prawda wyższe od średniej krajowej, ale również dalekie od słynnych 20 000 PLN. Grupa ta nadal jest słabiej wynagradzana od kolegów z krajów zachodu. Lepiej rzecz jasna od wielu zawodów w Polsce, jednak ciężko ją uznać za realnie zamożną.

 Sytuacja w Europie

Programiści w Europie zarabiają bez wątpienia nieźle, jednak w stosunku do innych grup zawodowych ośmielę się stwierdzić, że nie odbiegają od średniej tak jak specjaliści w Polsce. W pewnej mierze wynika to z konkurencji środkowo-europejskiej. W pewnych krajach niemile widziane jest duże rozwarstwienie dochodów. W innych po prostu miejsc pracy dla programistów nie ma aż tak wielu, bo bardziej opłacalnym i „wygodnym” jest bycie zarządcą – a sporo krajów Europy zachodniej stoi wyżej w światowym podziale pracy.

Kraje, które w stosunku do kosztów życia płacą programistom najlepiej to Szwajcaria, Wielka Brytania, Niemcy i Francja. Kraje, w których być programista się nie opłaca to na przykład Włochy, czy Portugalia.

Sytuacja na świecie

Na dwa kraje warto zwrócić szczególnie baczną uwagę: USA i Chiny.

Na USA z uwagi na tzw. military-industrial complex, czyli nieformalny sojusz pomiędzy przemysłem zbrojeniowym, a armią. Na Chiny z podobnego powodu, ale o tym za chwilę.

stany Zjednoczone dysponują nowoczesną – w wielu obszarach najnowocześniejszą na świecie – armią. Jest to armia nieustannie modernizowana, przesiąknięta nowinkami technicznymi, wyposażona w sprzęt pełen elektroniki.

Dość powiedzieć, że GPS był opracowany na potrzeby armii USA. Dla pełni obrazu można wspomnieć o dronach oraz przypomnieć, że roboty Boston Dynamics budowane były na zamówienie DARPA – agencji zaawansowanych projektów badawczych w obszarze obronności.

Ma to niebagatelny wpływ na rynek pracy inżynierów oprogramowania w USA. Boston Dynamics, Lockheed Martin, Facebook – wszystkie te firmy i wiele innych, zatrudniających setki tysięcy programistów stanowi fundament obronności kraju. Od automatycznych systemów jak drony, czy roboty, po wywiad i cyberbezpieczeństwo, tworzą one ogromny popyt na programistów za oceanem.

Z wolna podobnie sytuacja zaczyna się kształtować w Państwie Środka. Wzrost Chin powodujący inflację ambicji chińskiego narodu sprawił, że przywództwo zaczęło stawiać śmiałe cele. Jednym z kluczowych obszarów w Chińskich planach jest sztuczna inteligencja. Innym, oczywistym, jest rozwój armii. Rzut oka na oferty pracy w Szanghaju, czy Shenzhen pokazuje, jak mocno Chiny stawiają na AI.

Wbrew powszechnej w Polsce opinii, że Chińczycy pracują „za miskę ryżu” wynagrodzenia programistów z ofert pracy w większym mieście posiadającym przedsiębiorstwa z branży militarnej (Chengdu) oscylują wokół 20 000 RMB miesięcznie (ok 11 200 PLN). Daleko im oczywiście do wynagrodzeń oferowanych w Stanach, ale z powodu tych samych czynników, co w USA, można się spodziewać wzrostu popytu.

Dlaczego to się opłaca?

Nie rozumiem, czemu programista zarabia 15 000, kiedy ja zarabiam 4 000 – powie osoba spoza branży.

Tymczasem to proste.

Informatyzacja robi w zasadzie dwie rzeczy:

  1. automatyzuje pewne czynności sprawiając, że można zatrudnić mniej osób
  2. czyni możliwym rzeczy wcześniej nieosiągalne

Punkt pierwszy, przykład – swego czasu by sporządzić raport sprzedaży w jakimkolwiek sklepie, trzeba było usiąść przed stosem kartek i wykonać dziesiątki, setki operacji matematycznych. Dziś wystarczy kilka kliknięć i mamy wartości i wykresy, a to wszystko w kilka sekund. Jeśli w jakimś przedsiębiorstwie istniała osoba zajmująca się przygotowywaniem raportów (będących powtarzalnymi operacjami przetwarzania danych) można ją zwolnić. Raz opracowane narzędzie do generowania raportów posłuży tysiącom przedsiębiorstw, zaś wykonanie i aktualizacja tych narzędzi zajmuje o wiele mniej czasu i wymaga mniej etatów od tych, które dzięki owemu narzędziu stały się zbędne.

To tylko najbardziej prymitywny przykład automatyzacji. Dużo lepszym są choćby roboty spawające szkielety samochodów w fabrykach:

Zaprogramowany raz robot wykonuje pracę za darmo. Spawacz za każdą minutę bierze pieniądze.

Punkt drugi dotyczy nowych możliwości. Przykłady można mnożyć. Najlepszym bodaj będzie smartfon. Dzięki pracy między innymi programistów możemy dziś nawigować w terenie, słuchać muzyki, komunikować się ze światem i robić dziesiątki innych rzeczy na kilkuset gramowym urządzeniu wielkości połowy banana. Płacimy za nie producentom nieraz tysiące złotych. Dla wyprodukowania takiego cudeńka warto zatrudnić programistów.

Programowanie jest kluczowym narzędziem trzeciej rewolucji przemysłowej. Prawidłowo użyte, wykorzystane z głową potrafi podnieść produktywność przedsiębiorstwa o rzędy wielkości. Przykładem niech będzie Amazon. W porównaniu do tradycyjnego sklepu, Wal-Mart, generuje on dwukrotnie więcej dochodu na pracownika.

Najbardziej wydajną firmą, złożoną głównie z programistów, jest Apple. Jeden jej pracownik zarabia dla firmy prawie dwa miliony dolarów rocznie.

Źrodło: https://businessinsider.com.pl/international/these-tech-companies-make-the-most-revenue-per-employee/xh60rk9

Właśnie dlatego programiści mogą zarabiać dużo. Nie tylko nie ma ich nadmiaru na rynku pracy, lecz także są w stanie generować dla firm zysk o wiele większy, niż przedstawiciele pozostałych profesji.