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_borderGorycz pracy programisty

Programowanie jest pięknym zawodem. Jest stymulujące intelektualnie, pozwala na kreatywność, pomaga ludziom ułatwiając im życie i służy biznesowi redukując koszty. Czasami jednak ma smak goryczy.

W programowaniu jest duch wydajności. Od chwili, gdy na pierwszym komputerze udało się policzyć coś setki razy szybciej niż ręcznie, jesteśmy oczarowani możliwością uzyskania niespotykanej wcześniej efektywności. Pewnie dlatego programiści prześcigają się w tworzeniu narzędzi usprawniających pracę. Ergonomiczne edytory kodu, automatyczne testy pozwalające zwiększyć niezawodność oprogramowania, metodyki tworzenia programów sprawniej, szybciej, wydajniej.

Każdy programista, który kiedykolwiek pisał coś co dało się zoptymalizować zna to słodkie uczucie, gdy coś zadziała sprawniej. Swego czasu, gdy jeszcze studiowałem, pewien profesor zlecił nam napisanie programu kompresującego. Algorytm z tego co pamiętam był entropijny, czyli przypisywał słowom używanym w tekście najczęściej najkrótsze symbole, a tym mniej powszechnym dłuższe. Na początku program po prostu działał, jak zwykle w optymalizacji bywa – wolno. Potem trzeba było sprawić by działał szybko. Pamiętam, że chodziłem dzień lub dwa z problemem w głowie, aż w końcu zrozumiałem, że drzewo BST będzie odpowiednim narzędziem w tym przypadku (dekompresji tak konkretnie). Po zmianie program działał błyskawicznie. Satysfakcja była przeogromna.

Tak samo jest z programowaniem poza akademią. Kiedy widzimy sens w projekcie, w produkcie, gdy wiemy, że użytkownicy będą zadowoleni, że ułatwi to ludziom życie – jest pięknie. Praca nad czymś takim to czysta przyjemność.

Bywa jednak gorzko. Pracujemy, nieraz w dużej grupie, miesiącami, nad pewnym produktem, wkładamy w niego serce, pracę i czas, powołujemy go do życia, a potem z powodu jakiejś decyzji na szczeblach władzy dużej firmy projekt zostaje anulowany. Znam osobiście człowieka, który po takiej decyzji opuścił firmę. Ze swojego doświadczenia natomiast wiem, jak boli, gdy dopada nas tego rodzaju wydarzenie.

I o ile zdarza się to raz na kilka lat nie ma w tym większego problemu. Jednak jeśli powtarza się regularnie, jeżeli staje się normalnością, zaczyna rodzić cynizm. Jak przekonać programistę do zwiększania efektywności albo wzmożonej pracowitości, jeśli przez ostatnie kilka lat co drugi projekt w jakim uczestniczył został anulowany, a jego kod nigdy nie wszedł na produkcję? Nie wiem. Po prostu nie wiem. Sądzę, że taki pechowy programista zostaje na jakiś czas, być może na zawsze, zepsuty.

Jest taka mądra opowieść o testach i błędach. Jeśli bug jest wykryty chwilę po powstaniu, jego naprawienie kosztuje niewiele, jeśli tydzień, już więcej, a jeśli lata później, bardzo dużo. Podobnie jest z decyzjami projektowymi – błędne decyzje co do startu projektu albo jego kształtu kosztują ogromne pieniądze. Im mniej tych błędów tym również mniej frustracji wśród programistów w naszym przedsiębiorstwie, a więcej motywacji, efektywności i zysku. Dlatego warto prototypować i badać rynek. Przynajmniej jednak dobrze byłoby programistom wyjaśnić czemu ich praca poszła na śmietnik. Możliwe, że odrobinę zmniejszy to ich gorycz…

bookmark_borderIle ofert pracy mają programiści i dlaczego dwie na rok?

Jest taki stary, suchy dowcip, że bezrobocie programisty to najgorsze piętnaście minut w jego życiu. Pracuj.pl tworzy specjalny sub-portal z ofertami pracy dla IT. JustJoin.it i No Fluff Jobs konkurują od lat i wyświetlają nam setki ofert pracy dla programistów. Co więc ja tutaj bredzę w click-baitowym tytule, zapytacie?

Otóż ofert jest mnóstwo, to prawda. W chwili pisania tego artykułu JustJoin.it zwraca ich 1385. Do pewnego stopnia prawdą jest też, że programista szukający pracy dość szybko jest w stanie ją znaleźć, o ile jest doświadczony i ma nieco umiejętności autoprezentacji.

Tyle jednak, że jeśli jest się specjalistą, osobą która posiada rozbudowane doświadczenie w jakimś obszarze, adekwatne do tego oczekiwania finansowe i chęć rozwoju oraz pracy z narzędziami, które się zna, w tym, w czym się jest ekspertem, to te omal półtora tysiąca ofert może się skurczyć do jednej, dwóch na rok.

Po pierwsze, technologie. Wspomniane JustJoin.it wyświetla na głównej stronie następujące filtry: JavaScript, HTML, PHP, Ruby, Python, Java, .NET, Scala, C. Jest ich dziewięć.

Po drugie, specjalizacje. Ful-stack developer, front-end developer, back-end developer, mobile, tester, devops, embedded, security, game. Kolejne dziewięć.

Po trzecie, miasta. Warszawa, Łódź, Kraków, Wrocław, Poznań, Trójmiasto, Śląsk, Białystok, Bydgoszcz, Toruń, Rzeszów – można by jeszcze kilka średniej wielkośći miast dodać, ale poprzestańmy na tym. Mamy ich jedenaście.

Klikamy więc, wybieramy Pythona i Białystok. Mamy jedną ofertę. Druga próba – Scala, Trójmiasto. Zero ofert. PHP Śląsk – trzy oferty, w tym jedna dla backendowca.

Podzielmy więc, na głupio, oferty przez miasta – z 1385 robi się 125. Podzielmy dalej przez technologie. Mamy 13. Dalej przez specjalizacje i mamy 1.5. I prawdę mówiąc uśredniając tyle mniej więcej wychodzi. W Warszawie pewnie pięć, w Rzeszowie zero, o ile nie mamy szczęścia.

Fragmentacja branży, mam wrażenie postępuje od lat. Kiedyś web master znał HTML, CSS i trochę JavaScript. Dziś mamy już front-end developera z React, z Angularem albo Vue, a full-stack „to już w ogóle” cytując klasyka – front React, back .NET, front Vue, back Java, front Angular, back .NET, front Angular, back Python itd.

Z jednej strony pompuje to stawki osób, które są w dobrym miejscu i z dobrą specjalnością, ale z drugiej rujnuje życie osób, które w tym miejscu nie są, a przede wszystkim projekty. Osobiście byłem świadkiem angażowania backendowców doświadczonych w .NET do pisania frontu w React. Niestety ani oni szczęśliwi nie byli, ani transpilator TypeScriptu nie mdlał z zachwytu nad tym, co musiał przetwarzać. Za to doświadczona React deweloperka, która z tym kodem musiała potem pracować była momentami bliska mdłości.

Gorącą mam nadzieję, że wkrótce firmy pójdą po rozum do portfela i praca zdalna stanie się tą słynną już nową normalnością. Otworzy to projekty na prawdziwych specjalistów, nasze płuca na świeższe powietrze bez spalin w miastach, a może przy okazji zlikwiduje nieco bezproduktywnych spotkań w niedotlenionych salkach konferencyjnych z grzybem w klimatyzacji.

bookmark_borderUpadek informatycznej nomenklatury

Dawno temu, gdy pionierzy pchali informatykę i IT do przodu… nazwy miały sens i brzmiały poważnie. Mieliśmy komendę, monitor, katalog, procesor i kompilator. Po przetłumaczeniu na język polski wszystkie te słowa nadal wyglądają rozsądnie, bo i sensowne były w oryginale. Komenda, to polecenie, wykonanie polecenia to uruchomienie ciągu instrukcji. Monitor służy do monitorowania stanu komputera. Kompilator łączy fragmenty, czyli kompiluje. Wiadomo o co chodzi.

Po kilku dekadach zaczęły się dziać rzeczy niepokojące. Nowe słownictwo zaczęło brzmieć idiotycznie. Nie czujemy tego, bo nie tłumaczymy tych wynalazków na polszczyznę. Spróbujmy.

            Agile – zwinność, chyżość, ruchliwość, zwrotność

            Scrum – młyn

            Angular – graniasty, kanciasty

            Developer – rozwijacz?

            Developer Evangelist – rozwijacz ewangelista!

            Pipeline – rurociąg

            Pull request – prośba o ciągnięcie

            Kernel panic – panika jądra

            Smalltalk – pogawędka

            NestJS – gniazdo JS

Żeby doświadczyć upadku lingwistyki wystarczy porównać zdania, które można by wypowiedzieć kilka dekad temu i teraz.

Dawniej: nasi programiści są bardzo dobrze wyposażeni, mają monitory i kompilatory, programują na najnowszych systemach operacyjnych, gdzie pliki trzymają w katalogach i wykonują komendy.

Dziś: nasi rozwijacze oprogramowania pracują w chyżości, w trakcie sprintu robią wiele próśb o ciągnięcie, współpracują z mistrzem młyna i operują na najnowszych technologiach, większość przednio-końcówkowców pisze w graniastym, wdrażają na chmurę rurociągami każdego dnia, bo mamy w firmie dobrych roz-opnych, na tylnej końcówce mają gniazdo javaskryptu, a jeśli mają problemy wspiera ich rozwijacz ewangelista, który ma tyle lat doświadczenia, że zaczynał rozwijać w pogawędce.

bookmark_borderNadciąga tsunami juniorów! Czy to koniec eldorado w IT?

Opowieści o końcu eldorado w polskim IT powtarzają się regularnie, jak książki i artykuły o upadku Chin w zachodniej publicystyce. I tak jak od dwudziestu lat Chiny upaść nie chcą, a wręcz coraz mocniej prężą muskuły, tak od lat rosną wynagrodzenia w polskim IT. Czy nie czeka nas jednak potop?

Kto przez ostatnie lata nie siedział w piwnicy, ale rozmawiał z kimkolwiek zajmującym się rekrutacją w IT wie, że ilość CV nadsyłanych na juniorskie oferty pracy dochodzi do 300 (słownie: trzystu). Jednocześnie ilość ofert dla młodszych programistów skurczyła się do tak znikomych ilości, że w zasadzie ciężko je gdziekolwiek znaleźć.

Tymczasem firmy obsesyjnie rekrutują seniorów za coraz wyższe stawki. Dwa lata temu praktycznie nie pojawiały się oferty przekraczające 20 000 PLN netto na B2B, dziś w takich ofert jest już sporo, a w Warszawie można odnieść wrażenie, że co trzecia ma górne widełki dochodzące do 20k.

Jak to mówią – biedni biednieją, bogaci się bogacą.

Pytanie, jakie powinni sobie zadać seniorzy brzmi: czy jest coś co obroni nas przed tsunami juniorów?

Znam wielu, którzy słysząc takie słowa spoglądają pobłażliwie i odpowiadają serią epitetów w kierunku nowych adeptów programowania – ci juniorzy nic nie umieją, trzeba ich za rączkę, uczyć ich trzeba, tylko przeszkadzają…

Warto byłoby jednak na wspomniane pytanie odpowiedzieć sobie szczerze, bez przesadnej buty. Doświadczenie w programowaniu jest cenne, ale mało która branża równie dynamicznie się rozwija, co sprawia, że seniority to szybko staje się bezwartościowe. Wystarczy wymienić Visual Basic, Flash, czy ASP classic. Nowości pojawiają się nieustannie, a kiedy przychodzi nam zajmować się wychowaniem dzieci i pielęgnacją rodziców, ilość czasu na edukację spada. Maleje też zdolność przyswajania wiedzy. Starzenie się zabija elastyczność.

Każdy, kto dostatecznie długo pracuje zna smutek w oczach starszego programisty, gdy pojawia się bystrzejszy junior, który dowodzi seniorowi, że jego czas się skończył.

To jednak normalna wymiana pokoleniowa i rzecz jak świat stara. Są jednak zjawiska ciekawsze. Od paru co najmniej lat ekonomiści i ludzie z ulicy zastanawiają się, kiedy dodruk pieniądza spowoduje inflację. Banki centralne drukują i drukują, a inflacja nie eksploduje. Podobnie jest z juniorami w IT.

Tsunami juniorów, ich olbrzymia, biblijna ilość, bierze się oczywiście z kuszących stawek w IT. Każdy czytał i słyszał o artykułach chwalących wynagrodzenia programistów. Dla mnóstwa osób jest to praca marzeń. Na tej nadziei budują swoje biznesy bootcampy, szkoły programowania i kursy on-line, obiecujące adeptom sztuki kodzenia wejście na obfity rynek pracy.

Jak długo branża IT wytrzyma napór tego tsunami juniorów? Nie wiem. Nikt nie wie. Ja bym jednak budował arkę.

W okolicznych krajach widać jasno podział rynków na takie, w których programista zarabia jak każdy i takie, gdzie jest królem. Europa Wschodnia to królestwo IT. Zachodnia, z pewnymi wyjątkami, to obszar, gdzie programista jest jak każdy. Warto zauważyć, że kraje bardziej rozwinięte zwykle nie wynagradzają programistów nadzwyczaj dobrze w stosunku do innych zawodów (Japonia, Niemcy, Skandynawia, Singapur), to regiony outsourcingu (Europa Wschodnia) i kraje innowacyjne (USA, Szwajcaria) doceniają koderów. Polska nie jest przesadnie innowacyjną gospodarką, a możliwe, że w ciągu dekady, dwóch, z wolna zacznie dołączać do krajów bardziej rozwiniętych.

Logika podpowiada, że duża ilość junior developerów nie może się w końcu nie odbić na wynagrodzeniach w branży. Spadek najpewniej nastąpi. A przynajmniej zbliżenie zarobków do średniej krajowej.

Będąc doświadczonym programistą zastanawiałbym się, jakie działania podjąć, by nie zostać ponuro zaskoczonym nadchodzącą zmianą…

bookmark_borderSzach-mat w 2.27 KB

Programiści to bystrzy ludzie. Niektórzy z nich to jednak naprawdę piekielnie inteligentne bestie. Nic nie dowodzi tego lepiej niż perwersyjne zabawy z kodem…

Konkursów na dziwny kod jest sporo, wiele też jest konkurencji. Jedną z nich jest quine. Zabawa polega tu na stworzeniu aplikacji, która wypisze własny kod źródłowy. Problem zrozumiały, ale daleki od prostoty. W przypadku JavaScriptu przykładowy quine wygląda tak:

(function $(){console.log('('+$+')()');})()

Idea tworzenia quine’ów ma zresztą dość ciekawe początki. Nazwa pochodzi od nazwiska amerykańskiego filozofa Willarda Van Orman’a Quine’a, który zajmował się m.in. teorią poznania, empiryzmem i logiką. Szczególnie ważnym tematem zajmującym Quine’a w kontekście programowania była pośrednia auto-referencja. Ciekawą rzeczą jest też Paradoks Quine’a. Przyjrzyjmy się poniższemu zdaniu:

„zwraca fałsz, gdy poprzedza je cytat” zwraca fałsz, gdy poprzedza je cytat.

Zdanie to sugeruje, że jest fałszywe, co jest paradoksalne – ponieważ jeśli jest fałszywe, to, co stwierdza, jest prawdą…

Poza konkursami istnieją też szalone idee. Na przykład języki ezoteryczne – skomplikowane, złożone, nieczytelne i z pozoru bezsensowne języki programowania, które jednakże działają. Tak wygląda kod źródłowy programu wypisującego „Hello world” w jednym z nich, Brainfuck’u:

++++++++++[>+++++++>++++++++++>+++<<<-]>++.>+.+++++++
 ..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.

Na koniec zaś tytułowe szachy. Niejeden programista ma tendencję do uwielbiania programów krótkich, zwięzłych i konkurowania z innymi w skracaniu. „Usunął połowę i robi to samo” – brzmi dla wielu jak komplement. Konkursy na skracanie kodu idą tu o kilka kroków dalej. Jednym z barwnych przykładów są szachy Oscara Toledo napisane w JavaScript.

Program zajmuje 2.27 KB i… generuje szachownicę, figury, umozliwia nam grę i w dodatku gra z nami. Kod wygląda tak:

<script>//(c)2010 Oscar Toledo G.
var B,i,y,u,b,I=[],G=120,x=10,z=15,M=1e4,l=[5,3,4,6,2,4,3,5,1,1,1,1,1,1,1,1,9,9
,9,9,9,9,9,9,13,11,12,14,10,12,11,13,0,99,0,306,297,495,846,-1,0,1,2,2,1,0,-1,-
1,1,-10,10,-11,-9,9,11,10,20,-9,-11,-10,-20,-21,-19,-12,-8,8,12,19,21];function
X(w,c,h,e,S,s){var t,o,L,E,d,O=e,N=-M*M,K=78-h<<x,p,g,n,m,A,q,r,C,J,a=y?-x:x;
y^=8;G++;d=w||s&&s>=h&&X(0,0,0,21,0,0)>M;do{if(o=I[p=O]){q=o&z^y;if(q<7){A=q--&
2?8:4;C=o-9&z?[53,47,61,51,47,47][q]:57;do{r=I[p+=l[C]];if(!w|p==w){g=q|p+a-S?0
:S;if(!r&(!!q|A<3||!!g)||(r+1&z^y)>9&&q|A>2){if(m=!(r-2&7))return y^=8,I[G--]=
O,K;J=n=o&z;E=I[p-a]&z;t=q|E-7?n:(n+=2,6^y);while(n<=t){L=r?l[r&7|32]-h-q:0;if(
s)L+=(1-q?l[(p-p%x)/x+37]-l[(O-O%x)/x+37]+l[p%x+38]*(q?1:2)-l[O%x+38]+(o&16)/2:
!!m*9)+(!q?!(I[p-1]^n)+!(I[p+1]^n)+l[n&7|32]-99+!!g*99+(A<2):0)+!(E^y^9);if(s>h
||1<s&s==h&&L>z|d){I[p]=n,I[O]=m?(I[g]=I[m],I[m]=0):g?I[g]=0:0;L-=X(s>h|d?0:p,L
-N,h+1,I[G+1],J=q|A>1?0:p,s);if(!(h||s-1|B-O|i-n|p-b|L<-M))return W(),G--,u=J;
J=q-1|A<7||m||!s|d|r|o<z||X(0,0,0,21,0,0)>M;I[O]=o;I[p]=r;m?(I[m]=I[g],I[g]=0):
g?I[g]=9^y:0;}if(L>N||s>1&&L==N&&!h&&Math.random()<.5){I[G]=O;if(s>1){if(h&&c-L
<0)return y^=8,G--,L;if(!h)i=n,B=O,b=p;}N=L;}n+=J||(g=p,m=p<O?g-3:g+2,I[m]<z|I[
m+O-p]||I[p+=p-O])?1:0;}}}}while(!r&q>2||(p=O,q|A>2|o>z&!r&&++C*--A));}}}while(
++O>98?O=20:e-O);return y^=8,G--,N+M*M&&N>-K+1924|d?N:0;}B=i=y=u=0;while(B++<
120)I[B-1]=B%x?B/x%x<2|B%x<2?7:B/x&4?0:l[i++]|16:7;for(a=
"<table cellspacing=0 align=center>",i=18;i<100;a+=++i%10-9?
"<th width=60 height=60 onclick=Y("+i+") id=o"+i+
" style='line-height:50px;font-size:50px;border:2px solid #dde' bgcolor=#"+
(i*.9&1?"c0c":"f0f")+"0f0>":(i++,"<tr>"));
a+="<th colspan=8><select id=t style='font-size:20px'><option>♛<option>";
document.write(a+"♜<option>♝<option>♞</select></table>");
function W(){B=b;for(p=21;p<99;++p)if(q=document.getElementById("o"+p)){q.
innerHTML="\xa0\u265f\u265a\u265e\u265d\u265c\u265b  \u2659\u2654\u2658\u2657\u2656\u2655".charAt(I[p]&z);
q.style.borderColor=p==B?"red":"#dde";}}W();
function Y(s){i=(I[s]^y)&z;if(i>8){b=s;W();}else if(B&&i<9){b=s;i=I[B]&z;if((i&
7)==1&(b<29|b>90))i=14-document.getElementById("t").selectedIndex^y;X(0,0,0,21,
u,1);if(y)setTimeout("X(0,0,0,21,u,2/*ply*/),X(0,0,0,21,u,1)",250);}}
</script>

            Resultat zaś tak: