bookmark_borderBezwzględne metody negocjacji podwyżek wśród programistów

Pieniądze w IT to gorący temat. Jak zresztą w każdym zawodzie. W branży cyfrowej jednak o tyle gorący, że pieniądze są zwykle większe. Podwyżka programisty może być równa jednej trzeciej albo i połowie pensji kelnera, więc jest się czym emocjonować…

Kto zyska, kto straci?

W książce Negocjacje z potworami Igor Ryżow przytacza ciekawą anegdotę. Miał się on udać wraz z szefem ekipy remontującej jego mieszkanie do sklepu w celu nabycia materiałów. Sprzedawca sprzeczał się z remontowcem na temat jakości kabli, namawiając go na inne. Ten jednak uparcie odmawiał. Nagle pracownik sklepu odezwał się do właściciela mieszkania: „Zdaje sobie pan sprawę, co się stanie, jeżeli te kable się zapalą?”.

Anegdota ta uczy nas, że negocjować należy z tymi, którzy mają najwięcej do stracenia w wyniku podjętej decyzji. Przypomina mi to pozornie sprytną strategię jednej z firm IT w Polsce. Wynajmowała ona programistów klientom końcowym, zarabiając na pośrednictwie. Popularny model biznesowy, wygodny dla wszystkich stron. Do procesu negocjacji podwyżek nie włączano jednak klientów. Rozmowa odbywała się między pośrednikiem, a programistą. Dawało im to doskonałą pozycję – w zdecydowanej większości przypadków twardy negocjator zbywał prośby inżynierów o podwyżki. Na krótko wygrywał.

Co tracił manager z firmy pośredniczącej odmawiając programiście? Nic. Czy coś ryzykował? Niewiele. W najgorszym dla niego przypadku deweloper po jakimś czasie się zwalniał i odchodził do konkurencji, a klient zlecał zatrudnienie kolejnego. Uzasadniało to istnienie sporego działu rekruterów, dawało im pracę, a nawet w pewnym sensie pozwalało zatrudniać kolejnych inżynierów drożej. Bo w końcu łatwiej wytłumaczyć klientowi, że nikogo taniej nie sposób było znaleźć, niż że ten, który pracował rok za x PLN na godzinę, teraz chce x + 20 PLN. A wyższa stawka to większy zysk dla firmy pośredniczącej, pobierającej pewien procent wynagrodzenia kodera.

Z pozoru przegrywał programista – w końcu musiał się godzić na pracę za niesatysfakcjonującą stawkę lub zmianę pracy w poszukiwaniu większej miski deweloperskiego ryżu.

Kto jednak tracił tak naprawdę? Czy nie klient? Wdrożenie programisty w projekt – szczególnie, że w tym przypadku były to projekty dość złożone – zajmuje sporo czasu. Odnalezienie się w strukturach przedsiębiorstwa również. Nawiązanie kontaktów też. Mówiąc krótko – nowo zatrudniony inżynier jest dość nieefektywny. Z punktu widzenia klienta lepiej byłoby mieć zespół składający się z ludzi obeznanych z firmą, sprawdzonych w boju i usatysfakcjonowanych z pracy. Każda nowa osoba wprowadza do projektu nieco chaosu, a także niesie ryzyko niedopasowania, a nawet katastrofy.

Warto zatem – dla skuteczności własnych negocjacji, ale i dla dobra tej części biznesu, która nas żywi – rozmawiać o podwyżkach najpierw i przede wszystkim z tymi, których to najbardziej dotyczy. To klienta, to lidera zespołu programistów, w którym pracujemy dotknie nasze potencjalne odejście albo demotywacja. Nie ważne z kim podpisaliśmy umowę, z kim formalnie jesteśmy związani. Ważne kto jest ostatecznym odbiorcą naszych usług.

Potrzeba matką podwyżki

Pewnym ideałem promowanym w środowisku programistów jest to, że dobrze zorganizowany projekt pozwala nowemu inżynierowi na szybkie dołączenie do zespołu. Oczywiście jest to nieco utopijne, bo w przypadku złożonych produktów musi upłynąć nieco czasu, nim nowy pracownik go pozna, ale generalnie przyjemnie jest szybko po zatrudnieniu czuć się efektywnym i wykonywać zadania. Jest to też pozytywne dla biznesu – możemy spokojnie udać się na urlop nie będąc niezbędnym, jesteśmy wszak tylko małym, zastępowalnym trybikiem w wielkiej maszynie projektu.

Niestety, z punktu widzenia naszej pozycji negocjacyjnej taka zastępowalność jest fatalna. Zastanówmy się – jeśli każdego programistę da się szybko wymienić, po co dawać nam podwyżkę?

Większość artykułów w internecie pełna jest sztampowych porad w stylu – najpierw pokaż, że jesteś więcej wart, bierz na siebie więcej obowiązków, rób szkolenia, bądź pozytywny itp. Jest to oczywiście pewna droga, ale też prawdę mówiąc niewielu w IT ona interesuje. Po co programista ma się przesadnie wysilać przez kilka miesięcy, udowadniać swoją wysoką wartość i wykazywać się nadzwyczajnym zaangażowaniem, skoro może iść na rozmowę kwalifikacyjną do konkurencji i dostać 20 procent podwyżki za 30-45 dni?

Poza powyżej opisaną, pozytywną ścieżką, istnieją dwie ciemne i makiaweliczne. Wbrew pozorom jednak obierane przez sporą część naszych kolegów i koleżanek i wcale nie kończące się wygnaniem z zawodu. Pierwsza to groźba natychmiastowego odejścia, a druga to stanie się niezbędnym w projekcie.

„Rzucenie papierami” często jest zaskakująco efektywne. Poradniki zazwyczaj twierdzą, że jest to najgorsze co możemy zrobić i już następnego dnia pracodawca będzie szukał zastępstwa na nasze miejsce. Być może w innych zawodach tak jest, natomiast w branży IT widywałem już wielu szantażystów, którzy pracowali przez wiele miesięcy po uzyskaniu podwyżki tym brutalnym sposobem. Zastanówmy się zresztą, jak to w praktyce może wyglądać…

Szantażysta może zażądać mniej, tyle samo lub więcej, niż oferuje obecnie rynek. Jeśli mniej – świetnie. Owszem, było niemiło, ale zasadniczo nadal zyskujemy. Jeśli zażąda tyle, ile rynek – wciąż nieźle, nadal zyskujemy. W końcu jest doświadczonym pracownikiem, a nowego w tej samej cenie będzie trzeba wyszkolić. Jeśli więcej – możemy dać tyle, ile oferuje rynek lub zwyczajnie odmówić. Więcej nie damy. Innymi słowy – jeśli dojdzie do porozumienia, to zawsze będzie ono korzystne dla managementu. Tylko z punktu widzenia emocji może być niekorzystne. Czy jednak możemy zakładać, że kierownicy nic innego nie mają do roboty, niż ignorować interes firmy i pielęgnować własne negatywne emocje? Być może. Sądzę jednak, że spora część myśli trzeźwo…

Drugą makiaweliczną opcją jest stanie się niezbędnym. To wbrew pozorom bardziej ryzykowna opcja, bo kiedy management zorientuje się, że jeden pracownik jest wąskim gardłem i jego brak oznacza katastrofę, z pewnością podejmie próbę zaradzenia takiej sytuacji. Jest to też opcja bardziej czasochłonna. Powinniśmy się zatem uzbroić w cierpliwość i przygotować na kontratak. Trzeba jednak zdawać sobie sprawę, że jest to ścieżka możliwa do realizacji tylko w długo trwających projektach i raczej w małych firmach bez procedur i ustalonego ładu korporacyjnego. O ile jednak uda nam się stać członkiem zespołu, bez którego projekt się posypie – uzyskujemy doskonałą pozycję do negocjacji podwyżki. To my możemy odejść od stołu, a druga strona straci bardzo wiele. Nie tylko możemy odejść, ale najpewniej też przez jakiś czas będziemy błagani o powrót i przekazanie wiedzy. O ile scenariusz ten jest mocno emocjonalny i ryzykowny, o tyle na małą skalę stanie się niezbędnym może dobrze działać. Wystarczy, że będziemy zwyczajnie dużo bardziej użyteczni od większości innych programistów, że będziemy mieli jakieś specjalne umiejętności, dużo większą wiedzę o projekcie, że będziemy na szczycie piramidy, że każdy to z nami będzie konsultował pracę. Powinno to być wręcz celem każdej osoby, która planuje długotrwałą karierę techniczną w danym projekcie. I samo to powinno wystarczyć do uzyskania przewagi w negocjacjach.

bookmark_borderTechnologiczno-narzędziowa zasada Pareto

Reguła Pareto jest ciekawą i dość znaną obserwacją. Mówi o tym, że większość rezultatów ma swoje źródła w mniejszości przyczyn. Na przykład w 1989 roku na najbogatsze 20% populacji przypadało 80% światowego PKB. Innymi słowy – to co z pozoru niewielkie zwykle wiele znaczy. To zaś co dominujące często nie jest aż tak ważne.

Jakiś czas temu rozpocząłem współpracę z nowym klientem. W kwestii używanych technologii nie różni się od innych – te same frameworki, języki i charakter pracy. To co go wyróżnia to podejście do narzędzi. Zamiast przeciętnego laptopa z Windowsem i mnóstwem korpo-oprogramowania konsumującego zasoby – MacBook. Zamiast siermiężnych Teamsów – Slack. W miejsce Outlooka – Google Workspace.

Wydawać by się mogło, że 80% wyniku powinny dawać technologie. Tymczasem okazuje się, że narzędzia, które zdają się być tymi paretowskimi dwudziestoma procentami – potrafią zabić lub ożywić produktywność programistów.

Z pozoru niewielkie spowolnienie powodowane przez ociężałe, niedostosowane do wymagań działów IT korporacyjne proxy, antywirusy i innego rodzaju oprogramowanie monitorujące jest w stanie ograniczyć wydajność programisty – moim zdaniem – nawet o połowę. Coś co w normalnych warunkach zajmuje 2 minuty może w takim środowisku zająć minut 10, a to już wystarczająco, by deweloper się zirytował i rozproszył. 2 minuty pozwolą pozostać we flow, a 10 minut frustracji przerodzi się w wizytę w kuchni albo chill-roomie, a następnie w kolejne kwadranse spędzone na powrocie do skupienia.

Podobnie sprawa ma się w zasadzie ze wszystkimi narzędziami. Oczywiście wybór dramatycznie złej technologii może mieć nawet poważniejsze konsekwencje – zastanówmy się jednak, czy tak naprawdę mamy wybór? Rynek pracy w ostatnich latach jest zdecydowanie rynkiem pracownika. Rekruterzy piszą już nawet ogłoszenia wierszem i ogłaszają się na egzotycznych portalach, byle tylko zachęcić koderów do zmiany pracodawcy. To trendy rynkowe decydują obecnie o wyborze technologii, a nie rozsądna, chłodna, inżynierska analiza. Mało kto będzie dziś na tyle odważny by prowadzić projekt np. w Ext JS. O narzędziach jednak decydować wciąż można. I często decyduje się zdecydowanie wbrew preferencjom programistów. A choć gazety lubią się w sensacyjnym tonie rozpisywać o ich rozpieszczeniu, to jednak ich sympatie względem pewnych narzędzi wynikają po prostu z tego, czy są one wygodne, czy nie. Wygodne, czyli pozwalające sprawnie wykonywać pracę. A mało co potrafi być tak irytujące jak codzienne pytanie na daily – czy coś cię blokuje – gdy wiemy, że są to narzędzia, których firma nie ma ochoty zmienić.

Dlatego warto przemyśleć, jakie narzędzia lubimy, które uważamy za najlepsze. Jeśli zarządzamy i decydujemy – dobrze słuchać w tej materii koderów. Jeśli zaś programujemy – warto przed zmianą pracodawcy lub klienta zapytać, z jakich narzędzi będziemy mogli korzystać? Może to być o pytanie o wiele ważniejsze niż mogłoby się wydawać…

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.