Efekt? Wolni zostali już praktycznie sami juniorzy i stażyści, choć i to się zmienia. Zdesperowani rekruterzy obniżają progi wymagań; widać to dobrze w ewolucji widełek doświadczenia w ogłoszeniach o pracę – stanowisko „Regular”, dawniej zarezerwowane dla pracowników z (minimum!) 4 – 5 letnim stażem, obecnie wymaga o połowę mniejszego doświadczenia. Przy wyższym wynagrodzeniu!

Jednym z chyba największych czynników, leżących u podłoża całej tej sytuacji, jest stosunkowo duża bariera wejścia w zawód. Bycie programistą wymaga nie tylko predyspozycji – zdolności logicznego myślenia, kompetencji matematycznych, zamiłowania do spędzania długich godzin przed monitorem. Aby osiągnąć poziom zaawansowania gwarantujący samodzielność projektową kandydat musi spędzić naprawdę długie godziny przyswajając podstawy, ucząc się składni i semantyki danego języka programowania i zdobywać doświadczenie rozgryzając coraz bardziej skomplikowane zagwozdki w kodzie. To nie dzieje się z dnia na dzień.

Takie uwarunkowanie skutecznie eliminuje sporą część społeczeństwa – nie każdy może i chce zostać programistą. Próg wejścia jest wyższy niż w przypadku wielu innych zawodów i przebranżowić się – wbrew obietnicom bootcampów – nie jest łatwo. Zwłaszcza w starszym wieku, kiedy – chyba wszyscy się zgodzimy – umysł nie jest już tak chłonny jak przed dwudziestką i przyswajanie nowej wiedzy, uczenie się nowych języków (również programowania!) nie przychodzi nam tak łatwo.

Dodając do siebie wszystkie te spostrzeżenia, wyłania mi się niezbyt optymistyczny obraz sytuacji. Programistów jest za mało, zapotrzebowanie na nich rośnie dramatycznie, a przyrost nowych kandydatów jest zbyt wolny.

I co teraz?

W krótkim terminie niewiele da się z tym zrobić – potrzebne są zmiany systemowe, w skali całego społeczeństwa. Modyfikacja nie tylko programów nauczania, ale wręcz całej filozofii. Dalsze, zintensyfikowane działania prowadzące do wyrównania proporcji kobiet i mężczyzn na studiach technicznych. Globalna zmiana myślenia o przygotowaniu młodych ludzi do zawodów przyszłości.

Albo wstrząs… patrząc wstecz, dopiero dramatyczne wydarzenia, takie jak wojna, przyspieszały przemiany zjawisk społeczno-ekonomicznych i prowadziły do znajdowania rozwiązań pozornie nierozwiązywalnych trudności. A czym innym, jak nie właśnie taką trudnością, jest obecna sytuacja na rynku IT, już teraz paraliżująca poniekąd cykl wytwarzania dóbr opartych na rozwiązaniach programistycznych? Więc ewolucja lub rewolucja.

Potrzebna nam zmiana sposobu myślenia i programowania. Uproszczenie procesów. Nie rozwiązania no-code, to za mało – chociaż one są na pewno wyraźnym przejawem rozpoczynającego się trendu. Większa automatyzacja, wykorzystanie sztucznej inteligencji do tworzenia algorytmów, aż do… stopniowej eliminacji ludzi?

Staram się wyobrazić sobie możliwe scenariusze, bazując na historii. Myślę o rewolucji technicznej, stymulowanej zbyt wolno zaspokajanymi potrzebami społeczeństwa i biznesu. Jednym z jej efektów było zastąpienie wytwarzania ręcznego przez produkcję fabryczną, ludzi – maszynami. Czy u progu takiej rewolucji stoimy?

Programista jak elektronik?

A co jeżeli w ciągu najbliższych 20 lat programista wyginie? Jak elektronicy z lat 80’, kiedy na rynek wprowadzono montaż SMD i zamiast przez tydzień naprawiać usterkę elementu przy pomocy inżyniera – można było już po prostu wymienić całą płytkę. Dzisiaj nie do pomyślenia, ale wtedy elektronik był dzisiejszym programistą. Większość maszyn produkcyjnych, całe biznesy opierały się na komponentach elektronicznych – elektronik był ekspertem, niezastępowalnym specjalistą, dobrem trudno dostępnym i sowicie opłacanym. Do czasu.

Ofiarą tej przemiany padł mój Tata, który był kierownikiem utrzymania ruchu i świetnym elektronikiem konstruktorem. Czuwał nad całą linią produkcyjną w hucie, bez niego nie było produkcji. Był gwiazdą, jak dzisiejszy programista JAVA, który w wieku 25 lat dostaje oferty pracy na poziomie 20 – 30 tys. zł. Tatę zastąpili najpierw tańsi technicy, wymieniający od ręki całe płytki, a później masowa produkcja, która sprawiła, że niektórych sprzętów nie opłaca się naprawiać, łatwiej wymienić na nowe.

Czy presja i brak rychłej zmiany sytuacji na rynku IT sprawi, że biznes – przyciśnięty dramatycznym brakiem programistów – zacznie finansować dziedziny nauki, które doprowadzą do ich eliminacji? Czy w perspektywie najbliższych kilkudziesięciu lat możliwe jest zastąpienie programistów sztuczną inteligencją? Oczywiście, ktoś będzie musiał ją programować, ale być może zostanie nas garstka najlepszych, jak z inżynierami elektronikami lat osiemdziesiątych? Czy będziemy świadkami dramatycznej rewolucji, zmiany paradygmatu, całkowitego odwrócenia myślenia o wytwarzaniu oprogramowania i dziedzin od niego zależnych? Powyższe pytania nie mogą pozostać bez odpowiedzi.

Adam Czajkowski  

Autor jest CEO w JCD.pl i SYMU.CO.

 

  

Artykuł Powiedzmy to na głos: sytuacja na rynku pracy w IT jest fatalna pochodzi z serwisu CRN.

Historię tę opowiedział mi niedawno zaprzyjaźniony Agile Coach z pytaniem dość oczywistym: co z takim przypadkiem robić? Oczywiście coś doradziłem (między innymi zasugerowałem szersze pochwalenie się na świecie kolegą Scrum Masterem – programistą, który tworzy bezbłędny kod – ktoś taki to prawdziwy skarb), miło porozmawialiśmy i być może nawet coś pomogłem. Niemniej pozostało poczucie pewnego niedosytu – miałem wrażenie, że w tej rozmowie nie doszliśmy do sedna sprawy.

Analizując podejście, zgodnie z którym programista nie powinien zajmować się testami (względnie, że zajmowanie się nimi jest poniżej jego godności i statusu społecznego) dochodzę do wniosku, że opiera się ono przede wszystkim na dwóch fałszywych przesłankach.

Edukacyjny grzech pierworodny

Pierwsza z nich to przekonanie, że rolą programisty jest programowanie, a ściślej, że „rolą programisty jest tworzenie kodu”. Takie redukcjonistyczne podejście widzi osobę, która umie programować, tylko w jednym wymiarze – tej właśnie umiejętności. W ten sposób redukuje się tego kogoś do biologicznej maszyny, która ma z punktu widzenia organizacji spełniać jedną funkcję. Nie dziwota, że skoro maszyna „programista” umie tylko jedno – „tworzyć kod” – to trzeba ją odpowiednio nastawić, a więc poprzedzić ją maszyną „architekt”, która „zaprojektuje rozwiązanie” oraz dostarczyć jej półprodukt do przetwarzania, co jest zadaniem maszyny „analityk”, która go tworzy pod postacią „specyfikacji”. Po wyjściu oprogramowania z maszyny „programista” przekazujemy je do maszyny „tes-ter”, której zadaniem jest sprawdzić czy to, co zrobiła maszyna „programista” jest zgodne z tym, co wyprodukowała maszyna „analityk”. Wszystko na podobieństwo łańcucha wytwórczego w przemyśle.

Jak łatwo zauważyć, wszystko jest zoptymalizowane na takie traktowanie pracownika począwszy już od etapu kształcenia (wąska specjalizacja), poprzez rekrutację (stanowiska opisane zadaniem, jakie ma być wykonywane), a kończąc na metrykach (godziny pracy, czyli godziny wykorzystywania umiejętności). Dołóżmy do tego formowanie menedżerów w taki sposób, że każdy z nich niemal instynktownie czuje się zobowiązany do dbania o to, by każda maszyna (zasób) była maksymalnie zajęta – i mamy obraz dysfunkcyjnego mechanizmu, który umacnia to błędne przekonanie – a co za tym idzie, jego konsekwencje.

Nie dziwne zatem, że wykształcona w tym kierunku i rozliczana z godzin programowania maszyna „programista” oburza się, gdy miałaby zajmować się czynnościami innych maszyn lub odpowiadać za ich wyniki. Nie dziwne, że osoba obsadzona w roli maszyny „programista” nie czuje się w pełni zaangażowana w produkt, czy w całość określonej pracy.

Tymczasem tak naprawdę zadaniem programistów, testerów i w ogóle wszystkich innych jest rozwiązywanie problemów użytkowników poprzez oprogramowanie, a więc dostarczanie użytkownikom nowych możliwości, które są dla nich wartościowe. Wymaga to wielu umiejętności i czynności – samo tworzenie kodu (a więc umiejętność przypisywana programistom) jest tylko jedną z nich. Wśród tych umiejętności, poza umiejętnością programowania, mamy także umiejętności analityczne (rozumienie problemu), jak i związane z testowaniem oraz wiele innych. Wszystkie one są potrzebne i ważne, bo bez nich nie może powstać kompletny efekt pracy. Przy czym nie jest nim działające oprogramowanie, ale danie użytkownikowi wartościowych możliwości, których wcześniej nie miał.

Jeśli zbierzemy zespół, to z pewnością różni jego członkowie mieć będą owe umiejętności rozwinięte i wyćwiczone w różnym stopniu. Jest to dobre, pod warunkiem, że będą z sobą współpracować w taki sposób, by wykorzystać swoje silne strony i zminimalizować słabe, dzięki czemu możliwości zespołu będą sumą ich możliwości. To zaś możliwe jest jedynie przy wspólnocie pracy (wszyscy razem tworzymy rozwiązanie dla naszego użytkownika/klienta) i odpowiedzialności za produkt. Innymi słowy, „testera” równie interesuje poprawność rozwiązania co i „analityka”, a „programista” przejmuje się nie tylko kodem, ale i tym, czy ów kod działa oraz czy efekt jego działania spełnia oczekiwania klienta. Łatwiej jest stan taki osiągnąć, jeżeli patrzymy na zespół nie jako na zbiór odrębnych wyspecjalizowanych maszyn, ale jako na grupę ludzi o różnych umiejętnościach, którzy wspólnie coś tworzą. Jak sądzę, taki stan właśnie mieli na myśli twórcy Scruma, kiedy nalegali, by wszystkich członków zespołu nazywać „developer” niezależnie od tego, jaką specjalność reprezentują.

Dojrzałość i odpowiedzialność

Drugą fałszywą przesłanką twierdzenia, że „programista nie powinien zajmować się testami” jest przekonanie, że „w pracy powinienem (względnie powinnam) zajmować się rzeczami przyjemnymi”, połączone z brakiem odpowiedzialności za swoją pracę. Nastawienie takie nie jest szczególnie oryginalne i występuje nie tylko w naszej branży. Przeciwnie, jest ogólną bolączką społeczną naszych czasów z ich naciskiem na fun i endemicznym brakiem zrozumienia dla takich pojęć jak obowiązek.

Temat to – wraz z naszym specyficznym tłem kulturowym – na osobny długi artykuł. Dość powiedzieć, że konieczna jest pewna dojrzałość i odpowiedzialność, która powoduje, że wstydzimy się oddać pracę niekompletną. Oprogramowanie, które nie zostało przetestowane jest w sposób ewidentny niekompletne, zbudowane niezgodnie ze sztuką. Profesjonalny, odpowiedzialny programista powinien się tym przejmować, a nie uważać, że czynności te go nie obchodzą i nie interesują. Nie powinien być zdania, że to jest w porządku, że może oddać coś, bo „u mnie działa”, a sprawa ewentualnych testów to już zajęcie dla kogoś innego, gdyż on jest ponad to…

Warto zauważyć, że w grach zespołowych – a Scrum to ma być „zespołowa gra w rozwój oprogramowania” (stąd nazwa) – choć są specjalności, to jednak zawodnicy, jeśli to konieczne, wychodzą poza nie. Na przykład jeśli obrońca znajdzie się w sytuacji dogodnej do oddania strzału na bramkę przeciwnika to to zrobi, a nie będzie się wymawiał, że on nie jest od tego specjalistą. Podobnie napastnik nie będzie obserwował spokojnie z boku akcji drużyny przeciwnej, twierdząc, że tą sprawą powinni zająć się obrońcy, a jego to nie obchodzi, bo on się w obronie źle czuje i pasjonuje go atak.

Ta metafora dość dobrze pokazuje o co chodzi. Nie idzie o to, że istnienie w zespole osób o specjalizacji bardziej ku testom („testerów”) nie ma sensu – wprost przeciwnie. Niemniej granica nie powinna być tak ostro zarysowana jak to ma miejsce ewidentnie w umyśle osoby, która zainspirowała ten przydługi artykuł. Innymi słowy, nie powinno być podziału w zespole, powinna być współpraca, w ramach której każdy robi to, co umie najlepiej, ale w miarę potrzeby także i to, co robi tylko przeciętnie, najlepiej jak umie, wkładając swój wysiłek w pracę zespołu w danym momencie i na danym etapie. Oczywiście, jest to trudniejsze niż po prostu powiedzenie, że „ja nie będę tego robił”, będące właśnie przejawem braku dojrzałości. W połączeniu z równie fałszywym przekonaniem, że celem metod agile jest, aby pracownikom – a szczególnie programistom – było miło i przyjemnie, prowadzi do wypowiedzi i postaw jak wyżej.

Co zatem należy robić? Po pierwsze, usunąć mechanizmy organizacyjne, które mogą wzmacniać pierwsze przekonanie (przede wszystkim skończyć z naciskiem na to, by wszyscy byli zajęci i idiotycznym liczeniem godzin). Po drugie, zdecydowanie walczyć z niedojrzałością i nieodpowiedzialnością, najlepiej już na etapie rekrutacji.

Andy Brandt  

Jest założycielem i senior consultantem firmy doradczo-szkoleniowej Code Sprinters. Wcześniej był między innymi Country Managerem Swisscom CEE (w Polsce pod marką Air Bites), a także menedżerem i konsultantem w 4pi, Unisys i T-Mobile Polska, jak też pierwszym redaktorem naczelnym „Linux+”.

  

Artykuł Czemu programiści nie chcą testować? pochodzi z serwisu CRN.

Według firmy w zawodzie programisty najbardziej liczą się umiejętności, ale coraz częściej pojawia się wymóg kierunkowego wykształcenia, a prestiż uczelni dodatkowo zwiększa szanse kandydata. Duże podmioty z branży IT, tworzące złożone systemy informatyczne, zwracają szczególną uwagę na punkt CV pod tytułem „edukacja”. Z kolei jeśli chodzi o kodowanie stron internetowych czynnikiem ważniejszym od wykształcenia jest doświadczenie i portfolio dotychczasowych realizacji. – Wykształcenie kierunkowe dla programisty nie jest elementem kluczowym, ale zdecydowanie pomaga na rynku pracy. Konieczna jest natomiast znajomość języków programowania. Jeśli dyplom nie będzie poparty praktyczną wiedzą to tak, jak by go nie było – mówi Magdalena Kowalska, Szef Działu Personalnego Unizeto Technologies.

Firma przyznaje, że programiści należą do najbardziej poszukiwanych grup zawodowych. Realizacja projektów od podstaw często jest w tym fachu trampoliną do dalszej kariery w branży IT. 

Artykuł Unizeto: duże zarobki początkujących programistów to fałsz pochodzi z serwisu CRN.