W oparach absurdu czyli przestańmy wmawiać testerom, że programowanie jest proste!

4 kwietnia 2018 | Goście na blogu

Wpis gościnny

Autor: Marcin Sikorski

Twórca bloga test-engineer.pl. Wieloletni test lead oraz entuzjasta obszaru Internet of Things oraz systemów Embedded.

Podczas gdy Magda pochwaliła się ostatnio jakoby wiosenna aura zainspirowała ją do nauki Javy Ja, żyjąc wciąż zimowym marazmem i marudzeniem, postanowiłem napisać dlaczego uważam, że twierdzenie, iż programowanie jest proste jest kompletnie nietrafione.

Świat IT opanowała jakaś przedziwna choroba bo gdzie nie spojrzę tam ciągle widzę slogany mamiące szybką i prostą nauką podstaw programowania. Co chwila powstają szkoły, kursy, portale, a co drugi artykuł na blogach prześciga się w wychwalaniu jakie to zalety niesie ze sobą nauczenie się Pythona, Javy czy C++.

„Wystarczą 4 tygodnie by zostać programistą!”

„Zapłać 99$, a efektywnie nauczymy się kodzić!”

„5 prostych kroków by zostać mistrzem Javy!”

Co jeden slogan to bardziej absurdalny, a im bliżej przyjrzeć się snutej wizji to zaraz okaże się, że umiejętność programowania jest tak niezbędnym element kariery IT (bez której nie da się żyć), że jeśli nie zapłacisz za naukę już w tym momencie to niebawem niechybnie przegrasz na rynku pracy.

Zacznijmy od tego, że programowanie to nie czytanie i miło by było gdyby branża się ogarnęła i nie plotła takich głupot. Tak, umiejętność ta ułatwia życie (o czym za moment) ale żeby zaraz kłaść ją na szali „potencjał kariery albo nic”? To chyba przesada.

Bez chęci i zaparcia wmawianie komuś, że nauczy się szybko kodzić to jak wmawianie, że nauczymy Cię zasad ekonomii, napraw auta i efektywnego gotowania w tydzień abyś stał się świetnym biznesmenem, złotą rączką i kucharzem w jednym.

Gdzie tu logika i sens?

Kodzenie jest trudne, żmudne, wyczerpujące i wyciskające ostatnie soki. Wymaga przekopania się przez setki dokumentacji – pisanej często nieczytelnie i wręcz grafomańsko – oraz obejrzenia tyleż samo godzin tutoriali nie mówiąc już o czasie spędzonym na samym kodzeniu.

Do tego dostępnych języków są dziesiątki, co chwila pojawiają się nowe wersje, które są często nie w pełni kompatybilne (Python 2, a 3 anyone?), a i czasem sam kompilator zechce nam spłatać figla twierdząc, że coś nie działa mimo, że powinno.

I nie zaczynajmy nawet dyskusji o zestawieniu środowiska.

Mój boże – nikt mi nie wmówi, że programowanie jest proste biorąc pod uwagę ile trzeba się natrudzić, żeby zestawić prawidłowo miejsce swojej pracy. Środowisko, coś co powinno być by default proste, już samo w sobie może napsuć krwi. A jak tu przebrnąć do tego mistycznego programowania i automatyzowania?

No właśnie – jak?

A to pakiet nie działa, a to złą wersję ściągniesz, a to masz coś co działa tylko pod specyficznymi warunkami – historii można by mnożyć.

O, spójrz! Stworzyłeś konflikt! Ekstra! Pytasz jak to cofnąć? To proste! Zapomnij, że go w ogóle naprawisz! Trzeba teraz tylko wywalić wszystko co przez ostatnie godziny ściągałeś i instalowałeś i reinstalować od nowa licząc, że tym razem się nie pomylisz.

I czy mógłby mi ktoś wyjaśnić, tak na zdrowy rozsądek, skąd w ludziach wzięło się przekonanie, że nauczą się programować w ciągu miesiąca i ktoś im za to zapłaci. Może to tylko moja pokrętna logika ale pomiędzy osobą chcącą się nauczyć i dukającą programy, a osobą, która zawaliła kilka lat życia (by umieć kodzić sprawnie, efektywnie i czytelnie) jest gigantyczna przepaść. Dlaczego zatem wmawia się, że ten pierwszy może szybko stać się tym drugim?

Może inaczej – słyszałeś kiedyś o miesięcznym kursie na lekarza? „Naucz się z nami leczyć wyrostek!”, „Wylecz swój pierwszy przypadek medyczny w niecały tydzień!”, „Za 49$ staniesz się w ciągu 2 tygodni doskonałym dentystą!”

Nie? A wiesz czemu? Bo mają się one nijak do rzeczywistości.

Potrzeba setek godzin, lat ćwiczeń, poświęcenia, samozaparcia, stopniowo coraz trudniejszych projektów, aby móc powiedzieć, że osiągnęło się biegłość i wprawę. Dlaczego zatem powtarza się wytartą formułkę o łatwości programowania?

Kodzenie nie jest dla każdego. Kodzenie nie każdemu będzie służyć. Nie każdy tester w branży IT musi kodzić.

Tak, dogadanie się z developerami jest wówczas łatwiejsze.

Tak, zautomatyzowanie paru tasków uwalnia proces i zasoby ludzkie.

Tak, zrozumienie testowanego produktu może być szybsze.

Ale czy to znaczy, że musimy każdemu wciskać te brednie? Przykro mi, że brzmię oschle ale mam dość tego gadania, że programowania powinniśmy uczyć już przedszkolaków bo to takie proste, fajne i super, a jak nie będą skore do nauki to rynek je zeżre, strawi i wypluje.

Może zamiast tego IT zaczęło by bardziej skupiać się na procesie tworzenia, co? Może lepiej uczyć ludzi umiejętności miękkich? Jakieś skille interpersonalne typu negocjowanie, nawiązywania kontaktów, rozwiązywanie problemów, estymowanie, delegowanie uprawnień, adaptacja itd. Może dokształcajmy ludzi w branży Internetu Rzeczy, dzielmy się raportami i omawiajmy kierunki rozwoju IT zamiast męczyć tych Bogu ducha winnych ludków fałszywymi sloganami.

I na litość boską – zdefiniujmy w końcu role w branży IT! Zwłaszcza w tym obszarze!

Mam już dość HRowych ofert pracy, dla których developer z umiejętnościami testerskimi, automatyk, tester automatyczny, tester manualny z umiejętnościami tworzenia skryptów oraz Python tester widziane są jako jedno i to samo stanowisko. Serio? A brzmią one jak jedno stanowisko? Czy może weszliśmy w nową erę nadawania sobie przydomków i przyjmiemy, że każda z tych ról robi w sumie to samo?

Kończę, bo mnie Magda zaraz pobije za to, że zbytnio marudzę. Ale prawda jest taka, że programowanie nie jest, nie było i nigdy nie będzie proste, łatwe i trywialne. Wyzbądźmy się tego absurdalnego myślenia, zdecydujmy czego branży potrzeba, zacznijmy może przygotowywać materiały dla konkretnych grup i zainwestujmy więcej czasu w umiejętności miękkie (z którymi niektórzy testerzy mają SPORE trudności) aniżeli jedynie twarde.

PS. Taka anegdotka – ktoś mi powiedział, że programowanie jest prostsze niż nauka chińskiego. Nie wiem czy to miała być pociecha czy nie ale donoszę, że szybciej uzyskałem tytuł HSK2 (w pięciostopniowej skali znajomości chińskiego) i ofertę pracy dla firmy tworzącej software w Hangzhou niż sprawnie opanowałem automatyzowanie 😉

Najnowsze wpisy

CzytanQA: Steve Jobs

„Steve Job” autorstwa Waltera Isaacsona to dla mnie książka wyjątkowo z dwóch powodów. Po pierwsze, dostałam ją od bliskiej mi osoby. A po drugie dlatego, że to od niej zaczęło się moje zamiłowanie do biografii, reportaży i innych książek non-fiction.

CzytanQA: Labirynty Scruma

Scrumie książek napisano sporo. Dzisiejsza książka – Labirytnty Scruma – jest nieco inna, autor podchodzi do tematu od strony bardziej… problematycznej.

#3 Antywzorce w testowaniu oprogramowania: Korzystanie z niewłaściwego rodzaju testów

Wszyscy wiemy, jak z grubsza wygląda piramida testów: na dole jednostkowe, potem integracyjne, a szczytu akceptacyjne. Oznacza to po prostu tyle, że im wyżej w piramidzie, tym testów powinno być mniej… Ale mniej, to znaczy ile?

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!