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.

Wynika to z faktu, że oczekiwania pracodawców rosną nawet wobec osób zatrudnianych na niższych stanowiskach, jak na przykład junior developer. Technologie, które do niedawna były mile widziane na rozmowach o pracę, nawet wśród średnio doświadczonych programistów (tzw. regular developerów), takie jak np. React czy Node.js, dziś, jak wynika z badania Kodilla, pojawiają się jako wymagane w wielu ogłoszeniach na stanowiska juniorskie.

Od młodszych programistów front-endowych wymaga się obecnie obeznania z technologiami React lub Angular, a mile widziane są podstawy back-endu (środowisko Node.js, bazy danych). Co więcej, front-endowiec powinien znać pracę back-endowców na tyle, aby móc dokonać drobnych modyfikacji w kodzie. Dowodzą tego m.in. wyniki badania Indeed.com, zgodnie z którymi największym zapotrzebowaniem wśród języków programistycznych w 2018 roku cieszyć się będą Java oraz JavaScript.

Dane GUS pokazują, że od 2009 roku wynagrodzenie pracowników branży IT w naszym kraju rośnie z roku na rok. Według prognoz Kodilla.com trend ten utrzyma się do 2020 roku. Szczególnie w przypadku takich specjalności jak Web Developer i Java Developer. Większe szanse na zatrudnienie a co za tym idzie i atrakcyjniejsze wynagrodzenie będą mieli ci, którzy znają nie tylko podstawy programowania z front-endu ale też i back-end.

Artykuł Rosną wymagania wobec programistów pochodzi z serwisu CRN.

– Nowe trendy, które coraz bardziej się pojawiają w ogłoszeniach o pracę czy są wymagane przez pracodawców, to właśnie sztuczna inteligencja. Coraz więcej SI widzimy w aplikacjach z USA, które przodują w adaptacji tych technologii do projektów. To na pewno coś, co warto eksplorować. Może jeszcze nie jest tak, że znajdziemy to w co drugiej ofercie pracy, ale widzimy, że ten trend się zwiększa – mówi w wywiadzie dla agencji informacyjnej Newseria Innowacje Tomasz Bujok, założyciel firmy NoFluffJobs.

Drugim z coraz wyraźniej widocznych, globalnych trendów jest wzrost zainteresowania uczeniem maszynowym. Dotychczas było ono rzadko wykorzystywane w praktyce ale obecnie na rynku zauważalny jest mocny trend wzrostowy w tym obszarze. Będzie się to przekładać również na wzrost zapotrzebowania na specjalistów z tej dziedziny.  

 – Uczenie maszynowe jest znane od wielu lat, aczkolwiek wcześniej w projektach nie było tak często wykorzystywane, teraz widzimy coraz większy trend. Jeżeli ktoś chce być na czasie i za 5 lat być specjalistą w tych technologiach, warto zajrzeć w to teraz, bo to dużo bardziej skomplikowane rzeczy niż języki programowania – przekonuje Tomasz Bujok.

Na polskim rynku przybywa, natomiast, obecnie coraz więcej programistów front-endu. „Wynika to z tego, że jest dużo prościej nauczyć się samego front-endu, niż zostać programistą full stack czy programistą back-end w sześć czy dwanaście miesięcy” – mówi Tomasz Bujok. Najpopularniejszą technologią jest tu JavaScript. Natomiast w obszarze back-endu najpopularniejsza jest Java, w drugiej kolejności .Net.

Drugim wyraźnym trendem na polskim rynku jest, w opinii Tomasza Bujoka, napływ testerów. Rośnie liczba osób, które szkolą się w tej dziedzinie.

Źródło: Newseria.pl

Artykuł Potrzebni nowi specjaliści pochodzi z serwisu CRN.

Kobiety nie garną się jednak do pracy w branży teleinformatycznej. W latach 2005-2015 odsetek kobiet zatrudnionych w teleinformatyce w krajach Unii Europejskiej spadł o ponad 6 proc., do 16,1 proc. W Polsce w tym samym okresie odsetek kobiet zatrudnionych w teleinformatyce zmniejszył się z 32,8 proc. do 13,5 proc.  

–Ta branża jest postrzegana jako typowo męska, niestety tak jest. Obecnie około 90 proc. programistów stanowią mężczyźni. Warto podkreślić, że według badań przeprowadzonych na kodzie programistów, kod pisany przez programistki jest bardziej czytelny, bardziej zrozumiały, lepiej się z nim później pracuje – mówi agencji informacyjnej Newseria Innowacje Marcin Kosedowski ze startupu Kodilla.

Z badań PwC wynika, że tylko 3 proc. studentek zastanawia się nad karierą na rynku nowoczesnych technologii. Jak najczęstszy powód braku zainteresowania podawany jest brak informacji na temat samej branży jak i warunków pracy w niej. Kobiety uważają też często, że branża teleinformatyczna jest zbyt mało kreatywna.

Na całym świecie prowadzone są liczne programy i inicjatywy mające na celu zachęcenie kobiet do pracy w teleinformatyce.

 –Powstaje mnóstwo inicjatyw, które zachęcają kobiety do dołączenia do branży IT, aby zostały programistkami. Główne języki na które decydują się kobiety to języki związane z front-end’em, czyli z wizualną częścią aplikacji, to takie języki jak JavaScript oraz powiązane z nim HTML i CSS – mówi Marcin Kosedowski.

W 2016 roku na polskim rynku pracy brakowało niemal 50 tys. programistów. Według prognoz w 2020 roku na rynkach Unii Europejskiej i Stanów Zjednoczonych będzie brakowało prawie miliona programistów.

Źródło: Newseria

Artykuł Kobiety kodują lepiej pochodzi z serwisu CRN.

Najwięcej z nich mieszka w Warszawie, Krakowie i Wrocławiu. Pozycja stolicy nie jest jednak u nas tak dominująca jak w innych krajach. Skupia się w niej 29 proc. polskiej społeczności deweloperów, czyli 74 tys. osób. W Krakowie pracuje 32,5 tys. osób (czyli 13 proc.), we Wrocławiu 24,3 tys. (niecałe 10 proc.), w Katowicach 24,2 tys., a w Poznaniu 22,4 tys. Dla porównania w Rydze, stolicy Łotwy, pracuje 93 proc. wszystkich programistów z tego państwa.

Na drugim miejscu pod względem ilości aktywnych zawodowo programistów w regionie Europy Środkowo-Wschodniej znajduje się Ukraina – 166 tys. osób. Trzecie miejsce zajmuje Rumunia (118 tys.), czwarte należy do Czech (100 tys.).

W Polsce jest jednak zdecydowania mniej niż w innych państwach twórców oprogramowania w przeliczeniu na sto pracujących osób. Współczynnik ten wynosi u nas 1,4, przy średniej dla całego regionu 1,3. W znacznie mniejszej od naszego kraju Słowacji jest to 3,7. Szacunki mówią, że na polskim rynku pracy brakuje obecnie około 50 tys. programistów.

Artykuł Polska zagłębiem programistów? pochodzi z serwisu CRN.