No i masz babo placek, bo jak ten cały złożony świat, który liczy się w megabajtach treści napisanego oprogramowania i w terabajtach pochłoniętej wiedzy, streścić w kilkudziesięciu słowach lub choćby w tym artykule, który ma raptem 0,01MB? Ale, ale, przecież to wyzwanie, czyli coś co jest i powinno być z tym zawodem zrośnięte bezapelacyjnie, w dodatku w parze z chęcią podjęcia tego wyzwania - takie nasze branżowe yin i yang. Zatem dlaczego nie - spróbuję.
Na początek należałoby odpowiedzieć na pytanie czy ta "szklanka" (tj. bycie programistą) jest w połowie pełna czy w połowie pusta. Otóż odpowiedź brzmi ... tak. Zdziwieni? Oto pierwsza, jeśli nie główna, cecha tego zawodu - logika . Zauważcie, że jeżeli coś jest w połowie pełne, to jest i w połowie puste, więc niezależnie od przyjętego sposobu sprawdzania ("czy półpełne" w opozycji do "czy półpuste") zawsze uzyska się twierdzącą odpowiedź. Jeśli rozmawialiście kiedykolwiek z programistami, to z pewnością coś się wam z racji tego wywodu przypomina - ciężko się z tymi ludźmi dogadać, prawda? Pocieszę was - nie wszyscy posiadają tę wkurzającą cechę, a wartość i jakość programisty bezpośrednio przekłada się na poziom jego komunikatywności. Im bardziej komunikatywny, tym... wiadomo (i nie dajcie się zwieść, gdy niektórzy z nich będą tę regułę negować).
Nienasycony programista / fot. pexels.com Nienasycony programista / fot. pexels.com
Nienasycony programista / fot. pexels.com
Skoro tak a nie inaczej zdefiniowałem związek komunikatywności z jakością programisty, nierozsądnym byłoby wystawiać sobie samemu złą ocenę - wyjaśnię zatem jak z tą przysłowiową szklanką jest. Otóż ona raz jest bardziej pełna, raz bardziej pusta i zazwyczaj my programiści dążymy do tego, by przeważał pierwszy stan. Jeśli bowiem bilans pozytywów jest znacząco niższy, to zazwyczaj zmieniamy... nie, nie zawód - pracodawcę. Tak, wiem, mamy to szczęście, że rynek jest, jeśli chodzi o nas, chronicznie nienasycony (ot choćby Agora, w której serwisie publikuję ten tekst, poszukuje obecnie programistów ). A skoro tak jest, to dlaczego nie korzystać, szczególnie że...
Zmiana pracy to możliwość rozwoju, co bardzo nas kręci. Trochę przypominamy w tym zachowaniu gracza, który zdobywa kolejne poziomy w grze, nowe umiejętności, coraz wyższe stopnie mistrzowskie. Oczywiście i w tym wypadku zdarzają się wśród nas malkontenci, ale oni przez to malkontenctwo tracą wartość na rynku pracy i choć teoretycznie mogę znaleźć zatrudnienie (jak pisałem - rynek jest nienasycony), to równie szybko mogę się z taką nową pracą - niebotycznie zdziwieni - pożegnać. Jeśli bowiem trafią na wymagający zespół programistów, może okazać się, że zbytnio odstają od jego oczekiwań. I proszę zwrócić uwagę, że nie mówię tutaj o pracodawcy, ale o ludziach, których on zatrudnia. Częstokroć to oni bowiem - swoimi umiejętnościami - ustalają kryteria, które wchodzący do zespołu programista musi spełnić. Jeśli nie daje rady, to nie ma sensu, aby utrudniał lub wstrzymywał ich pracę. Może się to wydawać bolesne, ale jest logiczne. Oczywiście taki mniej wartościowy programista, gdzie indziej może okazać sie wystarczająco dobrym, a nawet bardzo dobrym - to zależy od specyfiki usług świadczonych przez zatrudniającą go firmę.
Czy zatem, w świetle tego, co napisałem nie zdarza się, że ktoś z powodu lenistwa przestaje być programistą? Pewnie tak, ale osobiście się z tym nie spotkałem. Znam natomiast przypadki, kiedy ludzie rezygnowali z zawodu programisty na rzecz... innej twórczej pracy. Bo programista to człowiek kreatywny , twórca (choć będę powtarzał do znudzenia - od wszystkich podanych tu w tekście generalizacji istnieją wyjątki). Bywa więc, że jego kreatywność idzie w innym kierunku. Często programiści zostają analitykami (którzy - w uproszczeniu - zajmują się zebraniem potrzeb zamawiającego oprogramowanie i przełożeniem ich na elementy definiujące tegoż oprogramowania oczekiwany kształt) lub architektami albo projektantami (znowu w uproszczeniu: ci przygotowują na podstawie pracy analityka pewien schemat, szablon tego, jak wyglądać ma oprogramowanie "od środka"). Bywa też i tak, że odchodzą od programowania na dobre, ale nadal zajmują się twórczą pracą - zostają szkoleniowcami, publicystami, fotografami, grafikami lub "idą w menedżery", aby już nie tyle grać w orkiestrze, co grać orkiestrą - jak dyrygent.
I artysta! / fot. pexels.com I artysta! / fot. pexels.com
I artysta! / fot. pexels.com
Zdarza się, że to odchodzenie od programowania w zupełnie inne dziedziny wynika z konkretnych powodów - jego ciemnych stron. Jedną z nich jest np. bardzo frustrująca konieczność szacowania czasu, jaki będzie potrzebny na przygotowanie oprogramowania. Dlaczego frustrująca? Otóż można by to porównać do próby określenia, ile czasu zajmie zrobienie swetra na drutach, jeśli nigdy się tego nie robiło. To zaś generuje konkretny stres , bo właściwie jesteśmy zmuszeni zgadywać. Zapytacie - jak to, przecież skoro to programiści, to przecież umieją programować (czyli robić na drutach)? Tak, ale gdyby trzymać się analogii swetra, to okaże się, że na jego zrobienie składa się także: przygotowanie drutów, hodowla owiec na wełnę, spęd tychże owiec, ich strzyżenie, wyrób wełny, wymyślenie sposobu na robienia na drutach jednego swetra przez kilka osób, sprawdzenie tego sposobu, ewentualna korekta, kolejne sprawdzenie, kolejna korekta, aż koniec końców zacznie to zadowalająco działać. Tak to mniej więcej wygląda, a po drodze może się jeszcze okazać, że owce padają lub pożerają je wilki, itd. Programowanie to bowiem bardzo złożony oraz niezwykle drobiazgowy proces i kompleksowe ogarnięcie wszystkich występujących w jego ramach czynników jest bardzo skomplikowane. Stąd zresztą powstały specjalne metodyki prowadzenia projektów informatycznych, które wreszcie w pewnym stopniu ułatwiają panowanie nad nimi (to przede wszystkim tzw. metodyki zwinne - określane wspólnym mianem Agile).
Dodatkowo w programowaniu nie ma takich prostych rozwiązań, jak w innych dziedzinach. Zakładając, że potrzebujemy 10 swetrów, a przygotowanie jednego zajmuje wprawnej szwaczce tydzień, to zrobi je ona w 10 tygodni. Wystarczy zatem zatrudnić 5 szwaczek, aby zajęło to tylko 2 tygodnie. Niestety, w przypadku tworzenia oprogramowania ta matematyczna reguła nie ma już zastosowania. Trudno przystępnie wyjaśnić dlaczego tak się dzieje, ale dobrze oddaje tę właściwość tworzenia oprogramowania ciesząca się w naszej branży dużą popularnością analogia: choć jedna kobieta potrafi urodzić dziecko w dziewięć miesięcy, to nie jest możliwe, aby dziewięć kobiet urodziło je w miesiąc.
O na przykład taki sweter / fot. h&m O na przykład taki sweter / fot. h&m
O na przykład taki sweter / fot. h&m
Z tego co dotychczas napisałem, jasno wynika, że bycie programistą, to nie tylko umiejętność samego programowania. To także umiejętność pracy w zespole , znajomość funkcjonowania procesu wytwarzania oprogramowania, tak aby móc w nim świadomie i sprawnie uczestniczyć. To również mnóstwo pracy niezwiązanej bezpośrednio z osiągnięciem celu, jakim jest otrzymanie oprogramowania w zakładanej postaci. A składają się na nią takie czynności, jak zapewnienie, że podczas jego wytwarzania nie powstaną błędy, a nieprzewidziane i nieznane wcześniej fakty (o rany, to mają być swetry dla czterorękich kosmitów?!) nie przekreślą dotychczasowych prac, lecz najwyżej opóźnią otrzymanie oprogramowania o skończony, dający się oszacować czas.
Istotną cechą zawodu programisty jest też nieustanna nauka . Ta dziedzina zmienia się bardzo dynamicznie. Jeśli nie trzyma się ręki na pulsie, może się okazać, że nie jedziemy już z peletonem, ale gdzieś 15 kilometrów za nim. Z samą nauką jest zresztą nawet tak, że ta uzyskana w ramach studiów to zaledwie podstawa i jeśli w ich trakcie nie robisz więcej, jeśli rzeczywiście nie studiujesz, to startując na rynku pracy, będziesz miał ledwie status czeladnika, choć powinieneś być co najmniej majstrem, a najlepiej mistrzem w tym fachu. Dobrze też, jeśli już w trakcie studiów zdobyłeś jakąś praktykę w komercyjnych projektach, bo te potrafią się naprawdę diametralnie różnić od akademickich.
Nie myślcie też, że bycie programistą to znajomość wyłącznie jednego języka programowania lub znajomość jednej technologii. Im więcej umie się w tematach kryjących się pod tymi wszystkimi kilkuliterowymi skrótami, tym lepiej. O jakich skrótach mowa? Ano o tych: C#, C++, Java, JS, Ruby, SQL/TSQL/PLSQL, VB, VBA, noSQL, LINQ, .NET, ASP.NET, MVC, MVVM, WPF, WCF, SOLR, SOAP, JSON, XML, XAML, CSS, HTML, JQuery, EF, Hibernate, UML, SOLID, IoC, DDD, TDD, GIT, TFS. O tak oczywistej sprawie jak znajomość języka angielskiego, przynajmniej w formie biernej (czytanie, słuchanie), nie wypada nawet wspominać.
Zapewne część z was czytając ten tekst myśli sobie "skoro to takie skomplikowane i wymagające tyle zachodu, to czemu ludzie chcą, a nawet lubią to robić?". Widzicie - my po prostu uwielbiamy łamigłówki, uwielbiamy rozwiązywać problemy, lubimy myśleć , bo myślenie sprawia nam przyjemność. Uwielbiamy też doprowadzać do tego, by to duch triumfował nad materią (nawet jeśli jest to tylko materia problemu). Nic nie sprawia takiej frajdy, jak świadomość, że dało się coś zrobić zgodnie z oczekiwaniami, a czasem nawet lepiej. Poza tym kręci nas ciągłe poznawanie nowych rzeczy, bo nauka (o dziwo) sprawia nam przyjemność. Nawet ta nauka, która nie jest związana stricte z programowaniem, ale ma miejsce przy okazji jego tworzenia. Stajemy się w ten sposób także specjalistami w innych dziedzinach, jak choćby w bankowości czy w gospodarce magazynowej. Kręci nas także świadomość, że jakby nie patrzeć, świat dzięki nam staje się lepszy, wygodniejszy, zabawniejszy, bezpieczniejszy. To także niesamowity powód do satysfakcji i zastrzyk motywacji. Stokroć większy niż ten, który miałby powodować cały ten niebotyczny hajs, który rzekomo zarabiamy .
Myślę, że mógłbym na temat bycia programistą jeszcze pisać i pisać, ale niestety zawsze są - tak jak w procesie wytwarzania oprogramowania - jakieś ograniczenia czy to zasobów, czy też czasu. Dlatego potraktujcie ten tekst jako wersję 1.0 poruszanego w nim tematu. Jeśli będzie zapotrzebowanie na więcej, powstaną kolejne wersje. Dokładnie w ten sam sposób, jak powstają kolejne wersje oprogramowania - bo ktoś ich potrzebuje. Albowiem wbrew obiegowemu i złośliwemu powiedzeniu naszej branży, że "programowanie byłoby wspaniałe gdyby nie było użytkowników", ja osobiście uważam, że tylko użytkownicy naprawdę nadają - tak programowaniu, jak i naszej pracy - wartość. Bo przecież chcą używać tego, co stworzyliśmy, są dopełnieniem naszej twórczości. A bycie spełnionym twórcą jest bezcenne. I to chyba najlepsze podsumowanie tego, jak to jest być tym programistą.
