5 - 2020 | Programista też człowiek

Gorycz pracy programisty

Posted on 29 maja, 202024 sierpnia, 2023 by kalkus

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…

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

Posted on 26 maja, 202024 sierpnia, 2023 by kalkus

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.

Upadek informatycznej nomenklatury

Posted on 24 maja, 202024 sierpnia, 2023 by kalkus

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.

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

Posted on 22 maja, 202024 sierpnia, 2023 by kalkus

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ą…

Szach-mat w 2.27 KB

Posted on 17 maja, 202024 sierpnia, 2023 by kalkus

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:

Pytania do przyszłego pracodawcy

Posted on 14 maja, 202024 sierpnia, 2023 by kalkus

Podczas rekrutacji potencjalny pracodawca nas testuje. Zadaje nam pytania techniczne i miękkie, pyta o nasze sukcesy i porażki, mocne i słabe strony. To bardzo rozsądne. Czy jednak programiści zadają odpowiednie pytania pracodawcy? Czy warto pytać i jakie pytania warto zadać?

Gdybyśmy zastanowili się, czemu rekruterzy egzaminują nas technicznie i wypytują o umiejętności współpracy, udane projekty, naszą osobowość i temperament doszlibyśmy szybko do wniosku, że robią to w bardzo słusznym celu – dopasowaniu do zespołu, w jakim mamy się znaleźć. Lista pytań, jakie zadaje się kandydatom jest do pewnego stopnia standardowa i możemy być pewni, że jeśli zadano je nam, to zadano również wszystkim pozostałym kandydatom, by porównać nasze i ich odpowiedzi.

Z moich doświadczeń, jako rekrutera technicznego, wynika jednak, że zaskakująco mała ilość programistów zadaje pytania przyszłemu pracodawcy. Zwykle jest ich niewiele i są dość ogólne lub powierzchowne.

Nie wiem, czy wynika to z braku śmiałości, z przeświadczenia, że i tak nie dowiemy się prawdy, z zaślepienia stawką w nowej firmie, czy może z braku przygotowania i refleksji, ale uważam to za błąd. Moim zdaniem nieodpowiedzialne jest zgłaszać się do firmy, jako kandydat głównie z powodu technologii, w jakich realizuje ona projekt oraz pieniędzy. Zespół to ludzie, a praca programisty to nie tylko technikalia i warto pomóc przyszłemu pracodawcy w dopasowaniu się do zespołu.

Rekrutacja jest niezwykle kosztowna. Przejście programisty z jednej firmy do drugiej to gigantyczny koszt dla obu przedsiębiorstw, jak i stres dla pracownika. W interesie wszystkich stron jest jak najdoskonalsze dopasowanie do nowego zespołu i firmy.

Lista pytań

Szukając nowego projektu lub zmieniając pracodawcę warto stworzyć listę pytań, które będziemy zadawać podczas każdego procesu rekrutacyjnego. Pozwoli nam to w naukowy, rzeczowy sposób porównać projekty i kulturę organizacyjną przedsiębiorstw, w których będziemy mieli szansę pracować.

Na czym nam zależy?

Przygotowanie listy należałoby zacząć od zapytania samego siebie o nasze priorytety. Jeśli bardzo zależy nam na pracy z daną technologią, powinniśmy na przykład upewnić się, że nie zostaniemy zmuszeni do pracy z czymś innym. Jeśli nie lubimy spotkań, warto zapytać, ile ich jest. Jeżeli nie lubimy projektów utrzymaniowych, zapytajmy o czas trwania projektu, datę jego rozpoczęcia.

Przykładowa lista pytań do potencjalnego pracodawcy

z ilu osób składa się projekt?
jakie jest seniority programistów w zespole?
jak podzieleni są członkowie zespołu (np. ilu front-endowców, ilu back-endowców)?
jak długo trwa projekt?
jak długo będzie trwał projekt?
czy planowane są podróże służbowe i w jakim wymiarze?
ile godzin spotkań tygodniowo zespół odbywa?
na jakim sprzęcie będę pracował?
jakie narzędzia będę miał dostępne (oprogramowanie)?
ilu programistów dołączyło do zespołu i kiedy, ilu odeszło i kiedy?
jakie technologie używane są w projekcie?
czy mogę zmienić projekt i po jakim czasie?
jakie technologie używane są w innych projektach?
czego dotyczy projekt?
kto testuje kod?
czy tworzone są testy jednostkowe i jakie jest pokrycie kodu?
czy możliwa jest praca zdalna i w jakiej ilości dni tygodniowo?
jak zespół dba o jakość kodu (code review, analiza kodu)?
jak wygląda architektura rozwiązania (monolit, clean architecture, mikroserwisy, chaos)?
jak wygląda proces wdrożenia (manualnie, continuous delivery, gated checkins)?
jak często oprogramowanie jest releasowane?
jak bardzo „ocenzurowany” jest internet (np. blokada youtube)?
czy mogę używać dowolnych bibliotek i pluginów, jeśli nie to jak duża jest baza pluginów i bibliotek zweryfikowanych?
czy będę miał podnoszone biurko?
na jakim krześle będę siedział?
czy biuro ma klimatyzację?
gdzie położone jest biuro?
czy jest dostępny parking?
co w ciągu ostatnich trzech miesięcy zostało zrobione w firmie, by usprawnić pracę programistów?
czy jeśli projekt się skończy zostanę przeniesiony do innego?

Oczywiście nie wszystkie pytania trzeba i warto zadać, jest to tylko przykład. Wiele jednak może zaważyć na naszej satysfakcji z pracy oraz przyszłości. Sądzę, że warto wybrać kilka(naście) z nich i upewnić się, że pasujemy do projektu i firmy. Pozwoli to nam zostać dłużej, być zadowolonym oraz produktywnym, co przyniesie korzyść zarówno nam jak i pracodawcy.

Czy Angular umiera?

Posted on 12 maja, 202024 sierpnia, 2023 by kalkus

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

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

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

Tutaj z kolei widzimy spadek satysfakcji z pracy z Angularem:

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

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

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

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

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

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

Prawo Brooksa

Posted on 10 maja, 202024 sierpnia, 2023 by kalkus

Estymacja się nie udała, deadline nas pokonał, nie wyrobimy się. Manager dorzuca ludzi do projektu, ale okazuje się to być gaszeniem pożaru benzyną. Poznajcie prawo Brooksa.

Fred Brooks jest jedną z najbardziej znanych postaci z dziedziny rozwoju oprogramowania. W Polsce nie wiedzieć czemu jest stosunkowo nieznany, a szkoda. Brooks zrobił w życiu dwie wielkie rzeczy – solidnie przyłożył się do rozwoju produktów IBM, w tym OS/360 oraz napisał książkę Mityczny osobomiesiąc. To właśnie z niej, a konkretniej z tytułowego eseju pochodzi prawo nazwane jego nazwiskiem – prawo Brooksa.

Prawo Brooksa mówi:

„dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej”

Bardzo bym chciał, by świadomość tej reguły upowszechniła się nad Wisłą, bo oszczędziłoby to wielu programistom i menedżerom zbędnego stresu…

Dziewięć kobiet nie urodzi dziecka w miesiąc

W eseju opisującym prawo Brooksa, autor rozróżnia zadania na trzy rodzaje:

zadania idealnie podzielne
zadania niepodzielne
zadania podzielne, wymagające komunikacji

Zadania idealnie podzielne

Skręcanie długopisów lub zbieranie szparagów to przykłady zadań idealnie podzielnych. Dzielimy to, co jest do wykonania na części i przydzielamy różnym pracownikom. Nie istnieje potrzeba by się między sobą komunikowali. Chcąc wykonać pracę szybciej możemy wysłać na pole albo do skręcania więcej ludzi. Wyślemy dwukrotnie więcej, dwukrotnie szybciej skończą.

Zadania niepodzielne

Choćbyśmy do wymiany oleju w samochodzie przydzielili pięciu mechaników, to nie zrobią tego szybciej. Olej musi spłynąć, nowy musi być nalany. Nic nie da dodawanie ludzi.

Zadania podzielne, wymagające komunikacji

I tu właśnie dochodzimy do tworzenia programowania. Wykonanie nowej aplikacji wymaga koordynacji między członkami zespołu. Co więcej wymaga również wdrożenia nowych osób.

Poniższa grafika ilustruje, jak lawinowo rośnie potencjalna ilość interakcji w zespole w zależności od ilości członków. Każda interakcja, rozmowa, wymiana wiedzy między dwoma osobami kosztuje czas, czas tym cenniejszy im bardziej spóźniony jest projekt.

Nowi ludzie w projekcie

Najgorsze w prawie Brooksa jest to, że jest ono sprzeczne z intuicją. Wydaje się bowiem oczywiste, że jeśli jakieś zadanie będzie wykonywała większa ilość osób to muszą je skończyć szybciej. W końcu projekt to nie jedno, ale wiele zadań. Na tablicy „do zrobienia” są różne taski, więc wezmą je i zaczną działać. Co może pójść nie tak?

Wbrew pozorom – sporo.

Przychodzą nowe osoby. Konfigurują swoje komputery, instalują oprogramowanie, ściągają kod źródłowy. Niby coś robią, ale żadnego z tego widocznego efektu przez pierwsze godziny/dni. Wydaliśmy pieniądze, a nie zyskaliśmy jeszcze nic.

Wszystko jest technicznie gotowe, nowi mogą zacząć pracę. Muszą się jednak dowiedzieć, co mają do zrobienia. Organizuje się więc spotkania wyjaśniające naturę projektu. Teraz już nie tylko nowe osoby w projekcie nie posuwają pracy do przodu, ale też dotychczasowi członkowie zespołu przestali pracować nad tym co kluczowe.

Spotkania się zakończyły. Nowi mniej więcej wiedzą, co robić. Zaczynają pracę. Wydaje się, że postęp w końcu ruszy z kopyta. Tymczasem wszystkie okresowe spotkania w zespole zaczęły zajmować więcej czasu. Zakładając, że pracujemy w scrum – dłuższe stają się daily, refinementy, planowanie sprintu i retrospekcja.

Wszystko wydaje się iść do przodu, ale to, czego nie widać na pierwszy rzut oka, to nieustanne pytania nowych osób do starej części zespołu. Nie da się również zauważyć, że te pytania przerywając pracę rujnują ich skupienie. Czasami po kilku minutach rozmowy programista potrzebuje piętnastu minut lub pół godziny, by wrócić do produktywności sprzed rozproszenia. Co więcej programiści pracują przecież nad tymi samymi plikami w zespole. Kiedy było ich trzech nie wchodzili sobie za bardzo w drogę. Nagle okazuje się, że merge’owanie, scalanie plików po zmianach kolejnych trzech osób staje się zmorą i zajmuje dużo czasu. Wydajność wszystkich znacząco spadła, zadowolenie również, a postęp jest wolniejszy, niż się spodziewaliśmy. Dopadło nas prawo Brooksa.

To co, nic nie robić?

Co robić w przypadku opóźnionego projektu to oczywiście doskonałe pytanie, na które jak sądzę nie da się odpowiedzieć ogólnie. Nie byłbym na tyle ortodoksyjny, by stwierdzić, że na pewno nie można dodać kolejnej osoby do zespołu, ale sądzę, że warto się nad tym dobrze zastanowić, przemyśleć ile takich osób i na jak długo planujemy dokoptować, a także koniecznie trzeba porozmawiać z zespołem i zapytać, jak taki pomysł im się podoba.

W wielu przypadkach naprawdę nie ma sensu dodawać ludzi do spóźnionego projektu. Deadline i tak będzie przekroczony, praca zakończy się szybciej, niż gdyby nie dodawać nikogo, a koszt będzie niepotrzebnie zwiększony.

Co jednak bardziej istotne, czasami dodanie ludzi do zespołu może skończyć się autentyczną tragedią. Wtedy prawo Brooksa ujawnia się z całą jaskrawością. Jeśli termin jest naprawdę krótki, a ilosć osób już oscyluje wokół dziewięciu i chcemy dorzucić jeszcze czwórkę, może się okazać, że zespół się kompletnie komunikacyjnie zakorkuje i nie tylko nie dostarczy produktu na czas, ale dostarczy zdecydowanie później, niż byśmy się spodziewali i to absurdalnie większym kosztem.

User experience? Developer experience!

Posted on 8 maja, 202024 sierpnia, 2023 by kalkus

Zatrudniasz się jako programista. Dostajesz powolny komputer. Nie ma na nim oprogramowania, które pozwala na wydajną pracę. Sporo stron w internecie jest zablokowanych. Nie możesz wybrać sobie klawiatury ani myszy, krzesła też wszyscy mają takie same. Brzmi znajomo?

5S

Japonia posiada interesującą kulturę. Estetyka, porządek, pracowitość – to bez wątpienia ciekawy kraj. Jednym z jego wielkich sukcesów jest motoryzacja. Amerykański przemysł samochodowy – z legendarnym Detroit, z linią produkcyjną w fabrykach Forda – był dumą Stanów Zjednoczonych. Mimo wygranej wojny i lat doświadczeń, w latach 80 przegrał z Japońską motoryzacją, a System Produkcyjny Toyoty wszedł do podręczników organizacji i zarządzania.

Jednym z elementów Japońskiej kultury w tym obszarze jest 5S. Nie wchodząc w szczegóły, jest to organizacja miejsca pracy polegająca m.in. na:

usunięciu zbędnych przedmiotów
ograniczeniu zbędnego ruchu i wysiłku pracowników
utrzymaniu stanowisk pracy w czystości

Wdrożenie tych zasad pomaga stworzyć bezpieczne i efektywne miejsce pracy. Nie trzeba mówić, że pomaga to całej organizacji w utrzymaniu wydajności – co istotne, bez zwiększania wysiłku pracowników.

Alcoa

Alcoa to jeden z największych producentów aluminium na świecie. Ciekawą historię o firmie opisał Charles Duhigg w Sile nawyku. Otóż swego czasu pojawił się w Alcoa nowy CEO – Paul O’Neill. Po nominacji na stanowisko prezesa zaskoczył udziałowców, bo w swoim przemówieniu inauguracyjnym skupił się nie na wynikach, opłacalności biznesu, planach rozwoju, ale… na bezpieczeństwie pracowników. Było to jedyne, co poruszył. Zmniejszenie liczby wypadków przy pracy.

O’Neill zarządzał firmą od 1987 do 1999 roku. W tym czasie wartość rynkowa firmy wzrosła z 3 do ponad 27 miliardów dolarów, a dochód netto wzrósł z 200 milionów do prawie półtora miliarda.

Czy te pieniądze Alcoa traciła na wypadkach przy pracy?

Oczywiście, że nie. Traciła je z powodu złej, niedbałej, niechlujnej organizacji stanowisk pracy. Na tym, że były nieprzemyślane, nieergonomiczne i były takie od lat z powodu złych procesów oraz komunikacji. O’Neill wprowadził presję na ulepszenie organizacji produkcji, bezpieczeństwo stanowiska pracy było metryką doskonałości. Jak widać – skuteczną.

Ciągle im mało

Tak, wiem, jesteśmy roszczeniowi. Mamy game roomy, podnoszone biurka, dwa monitory i owocowe czwartki, ale ciągle nam mało – snujemy się po kolejnych firmach w poszukiwaniu Bóg jeden wie czego, ale pewnie pieniędzy, których ciągle nam mało.

Może tak jest.

Co jednak, jeśli nie?

Co jeśli jest jakaś głębsza przyczyna migracji koderów?

Stanowisko pracy programisty

W programowaniu duży nacisk kładzie się na optymalizację. Motywem przewodnim tej branży od lat jest efektywność. Nowe frameworki, które pozwolą zrobić to samo szybciej. Szybsze procesory, więcej pamięci, potężniejsze dyski. Algorytmy, które liczą sprawniej, lepiej niż starsze. Karty graficzne, które generują więcej klatek na sekundę. Branża technologiczna oparta jest o wiarę w to, że da się lepiej i szybciej, taniej i sprawniej.

Programista, kiedy siada do pracy, próbuje ją sobie zoptymalizować. Jeśli musi wykonywać powtarzalną czynność – napisze skrypt. Jeśli coś zajmuje dużo czasu – pomyśli jak zrobić to szybciej, innym sposobem.

Co więc może być bardziej irytującego dla programisty od sytuacji, w której coś spowalnia jego pracę, a jednocześnie nie da się obejść, usunąć, poprawić?

Tych mniejszych lub większych przeszkód na drodze do wydajności, w wielu miejscach pracy, jest zaskakująco dużo. Oto kilka przykładów:

komputer, na którym programujemy ma za mało pamięci / za wolny procesor / za mały dysk
internet w firmie działa powoli, np. przez proxy
oprogramowanie antywirusowe dramatycznie spowalnia komputer (choćby od czasu do czasu)
polityka firmy blokuje pewne strony (np. youtube, gdzie możemy znaleźć tutorial do rozwiązania problemu)
przyznanie praw dostępu przeciąga się w nieskończoność (np. by wykonać zadanie potrzebujemy dostępu do systemu x, ale musi je zaakceptować trzech managerów, a to trwa trzy tygodnie)
firma nie kupuje pewnych narzędzi albo robi to bardzo powoli (np. potrzeba jakiegoś narzędzia na za tydzień, ale akceptacja i zamówienie zajmuje trzy miesiące)
naprawa zepsutego sprzętu trwa bardzo długo (osobiście raz czekałem dwa tygodnie na naprawę mojego firmowego komputera)

Pamiętam pewnego managera, który dziwił się, jak to jest możliwe, że startupy są wydajniejsze? – przecież mają nieraz mniejsze budżety, czyli teoretycznie gorszych pracowników, a jednak dostarczają szybciej. Z mojej praktyki wynika, że to właśnie narzut organizacyjny zabija efektywność…

Skupienie

Poza czysto technicznym aspektem, jakim jest wydajność sprzętu i dostępność narzędzi warto jednak pamiętać również o ergonomii miejsca pracy programisty. W jej skład wchodzą zarówno wygodne, dostosowane do konkretnej osoby krzesło, czy klawiatura, jak i otoczenie.

W wielu firmach kupuje się kilkaset takich samych krzeseł, biurek, monitorów, klawiatur i przydziela każdemu nowemu programiście. To zrozumiałe. Stan tych narzędzi jest zresztą zazwyczaj bardzo dobry. Jest jednak część osób – może niskich, może otyłych, może wysokich albo czułych w jakimś sensie – którym taki standard będzie utrudniał życie. Będzie ich bolał kark albo nadgarstki, będą ich bolały oczy. Trudno wtedy o najważniejszą rzecz w pracy programisty – skupienie.

Programista, jeśli nie może się skupić, trwoni pieniądze firmy. Skupienie zaś nie jest tak łatwe jak przyjście do biura. Rozmowni koledzy, liczne spotkania w trakcie dnia, niewygodne krzesło, zapach ryby atakujący nas z biurowej kuchni… wszystko to może zburzyć delikatną materię flow.

DX

User experience stało się głośną ideą. Na tyle głośną, że specjaliści projektujący interfejsy wygodne dla użytkownika zagościli w wielu firmach tworzących oprogramowanie. Każdy dziś wie już, że ergonomia aplikacji jest ważna.

Analogicznie, należałoby stworzyć ideę DX – developer experience. Im gorszy, tym więcej pieniędzy utonie w projekcie, a to co powstanie może okazać się niewarte wysiłku. Im lepszy tym mniejsza rotacja w zespole, wydajność i motywacja programistów, mniej błędów, a więcej zysku.

Za zalążek DX uznać można słynny test Joela – listę punktów, jakie spełnia proces rozwoju oprogramowania. Im więcej, tym on dojrzalszy, ale również przyjemniejszy dla programistów uczestniczących w projekcie…

Starając się „dopieścić” koderów warto wyjść poza standardy. Nie muszą to być duże koszty. Zyski zaś i owszem.

Na koniec przypomnijmy, że i Microsoft nigdy nie był obojętny na developerów…

Stek w czasach zarazy

Posted on 5 maja, 202024 sierpnia, 2023 by kalkus

Japonia to niezwykły kraj. Jego kultura jest znana, ceniona i bogata. Samurajowie, Godzilla, manga i anime, Hokusai, gejsze, origami i tak dalej…

Swoją drogą, Godzilla w oryginale brzmi Gōjira i to właśnie stąd wzięła swoją nazwę znana nam wszystkim… Jira.

Sztuka kulinarna stanowi potężny element kultury kraju kwitnącej wiśni. Jednym z charakterystycznych jej przejawów jest teppan-yaki. Jest to smażenie potraw na wielkiej stalowej, podgrzewanej od spodu płycie. Wygląda to mniej więcej tak:

Cóż jednak począć, gdy COVID-19 szaleje, restauracje zamknięto, a głód puka w ścianki żołądka od wewnątrz?

W Japonii, kraju nowoczesności, istnieje tylko jedno wyjście. Technologia!