Autor: kalkus

bookmark_borderOrtopeda rekrutowany jak programista

Posted on by kalkus
Ortopeda scifi

Za mną już 15 lat doświadczenia w ortopedii, przeróżne przypadki, skomplikowane operacje, ale i wielkie sukcesy. Te lata, choć niesamowicie rozwijające, sprawiły, że zacząłem szukać nowych wyzwań. W tym celu postanowiłem zaaplikować na kilka ofert pracy, aż w czterech różnych miejscach. Dwa z nich postawiły przede mną zadania domowe, co było nie lada wyzwaniem.

Pierwszy etap każdej z tych rekrutacji to rozmowa z HR. Pytania standardowe, ale staram się za każdym razem odpowiedzieć tak, by podkreślić moje zainteresowanie nowymi technologiami i rozwojem zawodowym. Jestem przekonany, że to właśnie moje doświadczenie i pasja do medycyny mogą być moimi największymi atutami.

Tuż po rozmowie z HR, przed rozmową z zespołem, nadeszły te niespodzianki – zadania domowe, nowość w świecie opieki zdrowotnej. Pierwsze z nich, choć wymagające, zdołałem wykonać w zaledwie 2 godziny. Drugie zaś – to już był prawdziwy test mojego doświadczenia i wytrwałości. Spędziłem nad nim całą sobotę, łącznie 8 godzin, analizując trzy skomplikowane przypadki, wymagające nie tylko głębokiej wiedzy, ale i kreatywnego podejścia do problemu. Było to coś, co w pełni angażowało moje umiejętności i pasję do medycyny.

Po zadaniach domowych przyszedł czas na rozmowy techniczne z zespołami. Każda z tych rozmów była dla mnie okazją do podzielenia się doświadczeniem, dyskusji o trudnych przypadkach i przedstawienia własnych metod leczenia. To były rozmowy na wysokim poziomie, które wymagały ode mnie nie tylko dogłębnej wiedzy medycznej, ale i umiejętności komunikacyjnych.

Ostatnim etapem były rozmowy z dyrektorami placówek. Tutaj czułem, że nie tylko moje kompetencje techniczne są na pierwszym planie, ale również moja wizja rozwoju zawodowego, umiejętności interpersonalne i dopasowanie do kultury organizacyjnej. Dyrektorzy chcieli wiedzieć, jakie mam plany na przyszłość, jak widzę swoją rolę w zespole i jakie innowacje mogę wprowadzić do ich ośrodków.

Przechodząc przez ten maraton rekrutacyjny, czuję, że każde zadanie, każda rozmowa przybliżała mnie do realizacji mojego celu – znalezienia miejsca, w którym będę mógł nie tylko pracować, ale przede wszystkim rozwijać się, wprowadzać innowacje i mieć realny wpływ na rozwój medycyny. Teraz, oczekując na decyzje, jestem pełen nadziei i gotów na nowe wyzwania, które niosą ze sobą przyszłe miejsca pracy. Bez względu na to, gdzie ostatecznie się znajdę, wiem, że ten proces był dla mnie bezcennym doświadczeniem.

W tym całym rekrutacyjnym zamieszaniu, przypomniała mi się historia mojego kolegi, także lekarza, który również szukał nowych możliwości rozwoju zawodowego. Podobnie jak ja, przeszedł przez różne etapy rekrutacji – od rozmów z HR po techniczne dyskusje z zespołami. Jego doświadczenie było jednak bardziej… nietypowe.

Po podpisaniu NDA, czyli umowy o poufności, co jest dość standardową procedurą, gdy rozmawia się o szczegółach pracy w medycynie, zwłaszcza w nowoczesnych ośrodkach stosujących zaawansowane technologie, dostał dość niekonwencjonalną propozycję. Firma, z którą był na etapie zaawansowanych rozmów, chciała, aby wykonał 1/3 operacji laparoskopowej na pacjencie. Tak, dobrze słyszycie. Nie chodziło o symulację czy teoretyczne opracowanie przypadku – ale o realną operację.

Argumentowali to testem kompetencji w realnych warunkach. Mój kolega był zszokowany. Z jednej strony, rozumiał potrzebę sprawdzenia umiejętności praktycznych, ale propozycja przeprowadzenia części operacji, jako etap rekrutacji, wydawała mu się przekraczaniem granic. Co więcej, kwestie etyczne i prawne takiego działania budziły poważne wątpliwości. Ostatecznie odmówił, uznając, że żadna praca nie jest warta ryzykowania swojej licencji medycznej lub, co ważniejsze, zdrowia pacjenta.

Ta historia stała się dla nas przestrogą. Niezależnie od tego, jak bardzo pragniemy danej pozycji i rozwoju zawodowego, musimy pamiętać o etyce zawodowej i nie przekraczać pewnych granic. W końcu, jako lekarze, przysięgaliśmy przede wszystkim nie szkodzić. Moja własna droga poszukiwania nowej pracy była intensywna, ale na szczęście nie musiałem stawać przed tak trudnymi dylematami, jak mój kolega.

bookmark_borderRozkład oprogramowania

Posted on by kalkus
canaletto obraz

Od lat zajmuje mnie rozkład. Jędrne, gładkie ciała obumierają w zmarszczone, poplamione truchła. Imperia pełne chwały i potęgi rozpadają się na symetryczne zgliszcza gruzu, obmywane deszczem i spiekane słońcem. Lśniące atomowym blaskiem gwiazdy zapadają się w parujące oddechem wymarłych światów czarne dziury. Nic nie jest wolne od rozkładu, bo panta rhei kai ouden menei. Również to, co spod naszych palców wyrasta – oprogramowanie.

Kod oczywiście jest doskonały, cyfrowy, nie poddaje się entropii. Tak samo jak nie poddaje się jej choćby Odyseja Homera. Tyle, że stworzony dawno temu program, jak i wieki temu spisana Odyseja nie żyją w próżni. Powstały dla odbiorców. I tak jak dziś inni są Europejczycy od Greków sprzed tysiącleci, tak samo ewoluuje ekosystem, w którym przychodzi egzystować oprogramowaniu.

Choć jest właściwie jeszcze gorzej. Programy bowiem powstają latami. Rozwijane są nowe funkcjonalności, aktualizowana jest ich integracja ze światem zewnętrznym, czasami wręcz zmianie ulegają technologie, z jakich aplikacje się składają.

I tu pojawia się rozkład. I błędne koło.

Na początku program tworzy się szybko. Stąd pewnie zachwyt wielu początkujących programistów (oraz gorycz doświadczonych). Im więcej kodu, tym więcej zmartwień, jak i w przysłowiowym lesie więcej drzew im głębiej. Zaś im więcej ludzi w projekcie tym już piekło jest wybrukowane…

Pierwsi programiści w projekcie często są bardzo doceniani. Siadają, piszą, działa. Można wdrażać na produkcję albo pokazać klientom lub przełożonym. Sukces. Za ten sukces zwykle są nagradzani. Awansują albo są kierowani do kolejnych nowych projektów. Ci mniej lubiani trafiają zaś do projektów już istniejących. Im niżej w hierarchii dziobania tym do starszych i bardziej zapleśniałych.

Sęk w tym, że bodźce kształtujące zachowanie są zwykle rozłożone niekorzystnie. Tworzy to koszmarne zjawiska i prowadzi do wspomnianego błędnego koła. Błędnego koła tworzenia, próchnienia i burzenia.

Programiści tworzący projekty greenfield (nowe, od zera) nie zmagają się z konsekwencjami swoich czynów. Mogą pisać co chcą, jak chcą, byle wytrwać z rok, czy dwa, do odkorkowania szampana i wdrożenia projektu. Mogą eksperymentować, ale też nagradzani będą ci, którzy jak najszybciej i jak najtaniej zaimplementują zestaw podstawowych funkcjonalności. Bodźce więc są proste – pisz szybko, byle jak (choć nie za bardzo), używaj nowych technologii, które ładnie wyglądają w CV, a jak napiszesz to oczekuj, że trafisz do nowego projektu albo poszukaj go na rynku pracy. Co dalej z kodem? Pal licho, nie twój interes.

Programiści utaplani w błocie legacy z kolei mają małe albo wręcz żadne – w zależności od stopnia rozkładu – szanse na poprawienie sytuacji. Jeśli projekt jest jeszcze względnie nowy, mogą próbować coś ratować, ale nie mogą uciekać od tworzenia nowych funkcjonalności. W każdym wypadku wypadną gorzej od pierwotnych twórców – będą zawsze pisać wolniej. Dlatego, że twórcy narobili bałaganu, w którym teraz trzeba się odnaleźć albo dlatego, że kodu jest więcej i jest trudniej nawet jak jest schludnie albo też jest średnio i trzeba posprzątać, więc również robi się to wolniej, niż na początku. Bodźce są takie, że najlepiej nic nie sprzątać i nie usprawniać, bo za to chwały nie będzie. Więc zwykle się nie sprząta. Tym bardziej, że biznes również tym sprzątaniem nie jest zainteresowany – kosztuje to, skutki bałaganu nadejdą za rok, dwa, pięć, gdy już ich nie będzie, a poza tym trzeba klepać nowe ficzery, bo to przynosi zysk.

Finalna faza rozkładu oprogramowania to legacy dojrzałe. Taka gorgonzola cremoso. Już nie tylko pleśń zielonymi żyłkami przecina nam kod jak w Matriksie, ale też sama struktura jest miękka i z lekka galaretowata. Poprawić nic się nie da, jak nie da się skleić szklanki. Można ją tylko – cytując klasyka – pogryźć i połknąć. I to też robią całymi dniami deweloperzy skazani na opiekę paliatywną nad projektami u progu śmierci. Bug za bugiem, debug za debugiem, w beznadziei dnia codziennego. Nikt nie porywa się tam na zmiany. Zmienić można co najwyżej pracę, ale i o to trudno, bo pracuje się przecież w starych technologiach, a i zapomniało się już nawet jak pisać przyzwoicie, patrząc przez dłuższy czas na starcze wynaturzenia – zrakowiałe struktury danych, zdegenerowane algorytmu i ułomne, antyczne narzędzia o finezji cepa bojowego, ewentualnie wekiery…

Programowanie w ostatniej fazie czeka na decyzję. Na decyzję o przepisaniu go od nowa. I tak zamyka się błędne koło – projekt dostają programiści z ładnym CV, którzy zawsze robią greenfieldy, potem ci mniej bohaterscy, którzy utrzymują systemy wieku średniego, aż w końcu trafia on znów do pielęgniarzy i pielęgniarek, którzy ostatnim ticketem zamkną mu oczy i wyślą na wieczny odpoczynek do krainy wiecznych pętli.

Tyle, jeśli chodzi o diagnozę. Pytanie – co z receptą? Nie umiem sobie do tej pory na nie odpowiedzieć. Wydaje się, że większość systemów informatycznych kończy właśnie w taki sposób i jest to jakimś naturalnym biegiem w cyklu życia oprogramowania. A wy, znacie jakieś alternatywy?

bookmark_borderParada atrakcji

Posted on by kalkus
bareja

Programowanie to przygoda. Naprawdę. Siadając do komputera i chcąc coś zaprogramować igracie z losem. Jesteście jak bohater antycznej tragedii, który jakby się nie szarpał, jak nie manewrował i tak przeżyje przygody jakich się nie spodziewał. Może nawet polegnie.

Dziś poległem ja.

Nie jest to nic nowego. Dzień jak co dzień w życiu programisty. Pomyślałem jednak, że warto to zanotować nie dla koderów, ale dla – tak zwanego – biznesu, dla osób bez koderskiej praktyki, które dziwią się, że programiści nie lubią wyceniać zadań, że spóźniają się z wykonaniem projektów i że wykonanie prostej czynności zajmuje im kilka dni. Muszą się lenić ci arystokraci IT najpewniej! Czyżby?

Historia zaczyna się niewinnie: chcę wizualnie odświeżyć bloga. Nie lubię jednak – jak większość frontendowców – PHP, więc nikły jest mój entuzjazm w kwestii tworzenia nowego szablonu WordPress. Niewielki research i szybko pojawił się w główce głupi pomysł. Zrobię w Gatsby. Nowy, seksowny framework, oparty na React, musi być przyjemnie i ciekawie!

Zaczynam więc. Szybka instalacja, nieco dokumentacji i jedziemy z dewelopmentem. Już na wstępie nadzieja, że będzie łatwo pada ofiarą rzeczywistości. Gatsby niby to ma coś wygenerować z endpointa GraphQLowego, ale w gruncie rzeczy nie generuje nic. Trudno, napiszę „z palca”.

Do WordPressa dodaję pluginy WP GraphQL i WP Gatsby, jak kontrybutor w dokumentacji przykazał. I nawet udaje się coś pobrać. Tyle, że jakby nie wszystko. GraphQL zwraca jedynie posty po angielsku. No tak – bloga prowadzę w dwóch językach. Trzeba więc wymyślić, jak pobrać te drugie. Łatwo to jednak tylko brzmi. Okazuje się bowiem, że plugin Polylang do obsługi wielu języków rozkłada na łopatki plugin WP Gatsby. Trzeba użyć innego – WP GraphQL Polylang, który jednak odbiera nam możliwość korzystania z wbudowanego w Gatsby klienta GraphQL.

Zainstalowałem zatem klilenta Apollo. Wydawał się działać. Ucieszony napisałem prosty komponent wyświetlający listę postów. Nagłówki, pięknie, wyświetlały się. Tyle, że już nie treść. Treść przychodziła z backendu pusta. Co ciekawe plugin to samo zapytanie inaczej rozwiązywał po stronie klienta i w oknie pluginu WordPress. Ciekawy przypadek. Ciekawy…

Tak był ciekawy, że godzinę co najmniej spędziłem na analizowaniu różnic, nie dopatrzywszy się żadnych istotnych. Kolejne pół godziny zaś na przeszukiwaniu Google w próbie rozwiązania tej zagadki. Tak jednak niestety się okazało, że jest to dość świeża sprawa i w zasadzie nikt o tym nie pisze. Wreszcie znalazłem kanał Slack pluginu i udało mi się w jego historii odnaleźć wzmiankę o autentykacji. Potencjalnie więc brak treści postów wynika z braku uwierzytelnienia. No to już pewnie jesteśmy w domu…

Niefortunnie droga do tego domu okazuje się prosta jak u Barei. Żeby dokonać autentykacji należy zainstalować – i to ręcznie, ściągając samemu z repozytorium Githuba – plugin WPGraphQL JWT Authentication, a następnie wygenerować gdzieś sekret, wkleic go do pliku konfiguracyjnego wp-config, a także upewnić się, że serwer wspiera nagłówek HTTP_AUTHORIZATION. A żeby wspierał trzeba w apache skonfigurować .htaccess i…

I zrobiła się pierwsza w nocy.

Nad tak banalnym zadaniem jak wyświetlenie listy postów pobranych z backendu oraz jego konfiguracja spędziłem dobre 8 godzin i udało mi się jedynie wyświetlić ich nagłówki. To, co miało być najprostsze (konfiguracja backendu) okazało się piramidalnie trudne, a tego, nad czym planowałem spędzić większość pracy (layout frontu, routing, struktura stron) nie udało mi się nawet zacząć.

Owszem – są to w większości technologie mi nieznane, ani z Gatsbym, ani z pluginem  WPGraphQL wcześniej nie pracowałem – ale jednak nie są to tak zupełnie obce mi kwestie. Mimo wszystko kompletnie ugrzęzłem w bagnie ustawień, nieprzewidzianych zależności, specjalnych przypadków i niedoróbek opensource’owym oprogramowaniu.

I tak się proszę państwa uprawia tę deweloperską rolę, co łamie pług i plecy łamie.

bookmark_borderCzytanie kodu

Posted on by kalkus
matrix code

Jako programiści robimy przede wszystkim dwie rzeczy: piszemy nowy kod i czytamy kod stary. Jest to rzecz tak oczywista, że nikt się nad tym nie zastanawia. Mnie samemu wydawało się to banałem. Oczywiście prawie zawsze, żeby napisać jakiś nowy kod trzeba przeczytać istniejący. Często nie trzeba nawet zbyt wiele dodawać, wystarczy zmiana kilku linijek, by wykonać zadanie.

I tak w gruncie rzeczy więcej tego kodu czytamy niż piszemy. Tymczasem od studiów i kursów, przez konferencje, aż po szkolenia – wszystko kręci się wokół pisania. Czysty kod, nowe języki, nowe frameworki. Na rekrutacjach proszą nas o napisanie jakiejś funkcji, na meetupach pokazują jak ładnie i sprawnie pisać przy użyciu nowych narzędzi. I nikt – ale to naprawdę nikt! – nie skupia się na tym, na czym spędzamy większość czasu w pracy: na czytaniu kodu.

Ile znacie narzędzi pomagających w pisaniu? Formatery, lintery, wtyczki do refaktoryzacji, test runnery, podkreślanie błędów, podpowiadanie nazw metod – cuda wianki. A ile znacie narzędzi pomagających w czytaniu? Kolorowanie składni i debugger? Coś jeszcze?

Powiem więcej. Wymienicie choćby trzy książki, które dotyczą czytania kodu?

Ja znam tylko jedną – Praca z zastanym kodem. Najlepsze techniki, Michaela Feathersa. Co więcej jest to książka raczej mało popularna, choć ceniona i polecana…

Oczywiście niełatwe jest stworzenie takich narzędzi. Czytanie kodu to tak naprawdę nauka, to próba zrozumienia pewnego modelu rzeczywistości, który stworzył inny programista. To żmudny proces poznawania struktur danych i algorytmów. Lecz mimo wszystko jest to esencja zawodu programisty. I prawie nikt się nad tą kwestią nie pochyla.

Nienawidzimy brzydkiego kodu, uciekamy z pracy przed spaghetti, przed legacy, a jednocześnie w każdym projekcie spotykam się z debugowaniem przez console.log / printf / WriteLine i brakiem albo co najmniej niedoborem testów jednostkowych. Jest to chyba nasz wspólny grzeszek, że tak mało serca wkładamy w czytanie kodu…

bookmark_borderSyzyfowe korpo prace

Posted on by kalkus
syzyf

Jak pisał Herbert – warto z uporem powtarzać stare zaklęcia ludzkości: bajki i legendy. Wszyscy znamy historię Syzyfa – ulubieńca bogów, który naraziwszy się Zeusowi padł ofiarą srogiej kary. Przyszło mu w nieskończoność wtaczać na szczyt ogromnej góry wielki głaz, który tuż przed osiągnięciem celu miał zawsze już wymykać mu się z rąk, spadać w dół zbocza i zmuszać go do rozpoczęcia zadania raz jeszcze. Bezsensowna, pozbawiona efektu praca, od tysiącleci jest więc symbolem tortury.

U zarania dziejów nie było zajęć beznadziejnych. Rozpaczliwa była kondycja ludzka – krótkie życie, łatwa śmierć, choroby, głód i chłód. Cierpieliśmy dzień w dzień pod wiecznie smutnym niebem. Niebezpieczne i nużące polowania, żmudna uprawa roli – straszna to była niedola. Jedno, jednakże rzec trzeba – miało to sens. Kto ubił dzika, zjadł go i przeżył, kto zboże zasadził i zebrał nie mógł powiedzieć, że spędził miesiące na bezsensownych czynnościach. Różne nas sprawy wówczas torturowały, ale praca mogła dawać satysfakcję.

Trzeba było kilku tysięcy lat, by sytuacja uległa odmianie. Dość radykalnej, bo w zasadzie obróceniu o 180 stopni. Mało co nas dziś zabija, a pod względem wysiłku wymaganego do przeżycia znaleźliśmy się na przeciwnym biegunie. Trudniej dziś umrzeć niż przeżyć (do czasu starości oczywiście). Złożoność społeczeństwa i gospodarki eksplodowała tak bardzo, że choć zasadniczo wszystko co robimy za pieniądze ma jakiś sens globalnie, to lokalnie już nie zawsze.

Przychodzimy do pracy. Współtworzymy jakiś-tam produkt cyfrowy. Bierzemy za to pieniądze, kupujemy produkty wytworzone przez innych ludzi z innych kontynentów. Niby wiemy, że do czegoś ta nasza praca się przydaje, że jest gdzieś na wysokim poziomie jakieś jej uzasadnienie, ale z perspektywy mikro ono po prostu, zwyczajnie nie istnieje.

Słyszałem o tak wielu przykładach deweloperskiej udręki, że nie wiem, czy nie należałoby wypłacać niektórym programistom dodatku za pracę w ciężkich warunkach…

  • W projekcie ABC kilku koderów pracowało nad projektem przez ponad kwartał, w nadgodzinach, pod presją – tylko po to by dowiedzieć się, że zmieniła się koncepcja, ich praca wyląduje w koszu i mają zacząć od nowa w większym gronie.
  • W projekcie BCD programista tworzył narzędzie dla dosłownie dwóch managerów wysokiego szczebla.
  • Projekt CDE został po dziewięciu miesiącach zamknięty, ponieważ okazało się, że międzynarodowa korporacja prowadziła na całym świecie w tym samym czasie pięć identycznych przedsięwzięć i ktoś postanowił zakończyć cztery z nich.
  • Projekt DEF trwał już dobre pół roku, kiedy pewien programista dowiedział się z pewnego źródła, że jest to już piąta z kolei próba implementacji tego samego oprogramowania. Żeby było zabawniej po kolejnym kwartale projekt został anulowany.
  • Pewien pracownik po odbytej wideokonferencji oświadczył, że dzwoniono do niego z prośbą o wymyślenie jakiegokolwiek projektu, ponieważ osoba dzwoniąca ma trzysta tysięcy euro budżetu do spożytkowania.

Na szczęście nie każdy projekt tak wygląda. Tego typu syzyfowe prace są najczęściej domeną albo korporacji albo ledwie co założonych startupów. W tych drugich produkt może po prostu nie zdobyć wystarczającej ilości użytkowników i roczna lub dwuletnia praca trafia do piachu. W przypadku tych pierwszych natomiast spora grupa projektów powstaje nie z uwagi na realne zapotrzebowanie albo hipotezę rynkową, którą postanowiono zweryfikować, ale ze względu na politykę. Prezes mówi „internet of things” i dwór zarządza by całe jego królestwo rozsiane po kontynentach rozpoczynało projekty pod tym hasłem. Dwa lata później okazuje się, że trend się zmienił albo większość z nich była jedynie na szybko montowanymi chochołami nie mającymi prawa przetrwać w rzeczywistości.

W ogóle projekty podzielić można na zasadniczo trzy kategorie:

  1. Utrzymanie starych, rentownych produktów
  2. Budowa nowego produktu (9 na 10 nie przetrwa roku)
  3. Rozwój produktu o rosnącej bazie użytkowników

Do każdej z nich nadają się inne osoby, z czego dwie pierwsze są bliskie definicji tortury.

Nieustanne tworzenie nowych produktów, które nigdy nie wchodzą na produkcję przypomina akademickie klepanie programów na zaliczenie. Z jednej strony osoby kreatywne mogą się w tym jakoś odnaleźć, bawiąc się architekturą i eksperymentując z nowymi technologiami, z drugiej jednak na dłuższą metę dojdą do nieuchronnego wniosku, że ich praca to zabawa, że nic w gruncie rzeczy światu nie dają, że budują papierowe samoloty, zamki z piasku…

Utrzymanie starych, rentownych produktów z kolei bliskie jest zazwyczaj szambo-nurkowaniu. Są to projekty beznadziejnie nudne, w których czas spędza się jedynie na łataniu taśmą bugów w beznadziejnych próbach utrzymania rozpadającego się truchła w kształcie przypominającym to, czym dawniej było. Jest to skazana na porażkę walka z entropią i gniciem oprogramowania. Jest to mieszanka oddziału gerontologicznego i onkologicznego. Przede wszystkim jednak jest to morderstwo własnego CV, bo można się tam nauczyć jedynie cierpliwości.

Jedyna przyjemna i nieliczna kategoria to produkty o rosnącej bazie użytkowników – aplikacje, które powstały stosunkowo niedawno, przyjęły się na rynku i są rozwijane. Znajdziemy je w najczęściej udanych startupach, które ewoluują już w kierunku średnich firm.

Do tworzenia nowych produktów nadają się osoby kreatywne. Mają się w nich okazję wyżyć, wyszumieć w swoich twórczych popędach, eksperymentować do woli, często i bez konsekwencji. Można się w nich też wiele nauczyć – często używa się tam najnowszych technologii. Jeśli tempo prac nie jest zbyt duże można nawet pokusić się o rozsądne zaplanowanie architektury i z tego etapu naukę oraz doświadczenie wynieść.

Do projektów utrzymaniowych z kolei, nadają się ludzie cierpliwi. Ktoś, kto ma już swoje lata jako programista, nie czuje się na siłach, by zgłębiać nowe techniki i paradygmaty, może tam odnaleźć swój przedemerytalny zakątek. Także osoby potrzebujące odreagować od pędu ku nowoczesności mogą w nich przycupnąć i odsapnąć od pogoni za nowymi frameworkami. Kto jednak kreatywny, kto nie znosi chaosu i lubi zbawiać świat – popadnie w tych projektach w szał. Trzeba do nich ludzi spokojnych, pogodzonych z niedoskonałościami, ludzi, którzy przyjdą każdego dnia, potaplają się w bagnie, westchną i wyjdą o piątej do własnego życia…

Jedynie w miarę ustabilizowane projekty, o rosnącej bazie użytkowników, napisane niedawno, rozrastające się dadzą schronienie osobom pomiędzy tymi dwoma światami. Nie będzie tam frameworków sprzed tygodnia, ale nie będzie też sprzed dwóch dekad. Coś da się poprawić, choć architektury się nie zmieni. Bugi będą, bo są zawsze, ale będą też nowe funkcjonalności. Co najważniejsze jednak – będzie sens. Użytkownicy docenili produkt i chcą go używać. Piszemy coś fajnego, co ludzie lubią i z czego korzystają. Nie łatamy starego systemu, którego wszyscy nienawidzą. Nie robimy eksperymentalnego produktu, który może się nie przyjąć. Robimy prawdziwą, w starodawnym duchu, poczciwą, przydatną pracę. Czego wszystkim życzę.

bookmark_borderProgramista. Przewodnik po zawodzie

Posted on by kalkus

Właśnie ukazała się w druku moja pierwsza książka – „Programista. Przewodnik po zawodzie”. Napisałem ją dla osób zainteresowanych programowaniem, które szukają odpowiedzi na pytanie – jak to jest być programistą? Skierowana jest do nastolatków zapatrzonych w kod źródłowy, do studentów informatyki oraz do dojrzałych ludzi myślących o przebranżowieniu. Nie jest to kurs programowania – tych jest już wystarczająco wiele. To opowieść o zawodzie.

Z książki tej dowiecie się na czym polega praca w charakterze programisty. Poznacie specjalizacje, wady i zalety zawodu, ścieżki awansu i kariery, zarobki. Przeczytacie w niej o podstawach teoretycznych: systemie binarnym, działaniu procesora, językach programowania, bazach danych i narzędziach, jakich używają w pracy programiści. Dowiecie się, czy programista musi znać matematykę oraz jakie predyspozycje pomogą wam w byciu koderem. Poznacie też kilka słów z programistycznego slangu. Mówiąc krótko – przeczytacie o wszystkim, co was spotka, jeśli wybierzecie zawód programisty.

Jeśli zastanawiacie się, czy programowanie jest dla was, jeśli lubicie je, ale nie wiecie, jaką karierę wybrać, jeśli zastanawiacie się, czy warto się przebranżowić – zachęcam do lektury. Książka jest dość krótka, ale odpowiada na większość pytań.

Mam nadzieję, że „Programista. Przewodnik po zawodzie” wzbudzi entuzjazm wśród tych z was, którzy programowanie lubią i się w nim odnajdują. Wierzę, że przygotuje was do pracy lepiej niż studia albo kurs – bo tam nauczycie się tylko podstaw teoretycznych. Zwykle jednak nikt wam nie powie na czym tak naprawdę ta praca polega. A nie polega tylko na pisaniu programów…

Zachęcam do lektury i powodzenia w kodzeniu 🙂

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

Posted on by kalkus
pieniądze

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

Posted on by kalkus
narzędzia

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

Posted on by kalkus
wilki jakieś

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

Posted on by kalkus
Caravaggio - Maria Magdalena

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.