W tym odcinku omawiam różne podejścia związane z tym, co właściwie znaczy bycie najlepszym programistą/specjalistą IT.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek dwudziesty pierwszy, „Jak pokonać inżynierów Elona, czyli gdzie są najlepsi programiści na świecie”.

Początkowo chciałem odcinek dwudziesty, taki okrągły, poświęcić jakiemuś nieco bardziej swobodnemu tematowi, takiemu mniej formalnemu, ale tak się rozgadałem w tym poprzednim temacie, że rozciągnął się na dwa całe odcinki. Mamy więc sytuację podobną do tego, jak w kultowym filmie „Miś” mamy „okrągły, dwudziesty pierwszy odcinek”. A inspiracją do dzisiejszego odcinka była niedawna, można powiedzieć, taka akcja, happening, niektórych polskich software house’ów, gdzie w związku z ostatnimi problemami Elona Muska, oczywiście znanego multimiliardera, jego z kadrą w Twitterze, gdzie pozwalniał ludzi, a potem próbował ich zatrudnić z powrotem. Pojawił się taki pomysł ze strony właśnie software house’ów, aby wzbudzić zainteresowanie Elona możliwością zatrudnienia programistów z polskich software house’ów.

Nie będę się tu rozwodził nad samą akcją, staram się też takich, powiedzmy, dyskusji wewnętrznych nie wywlekać, choć są osoby, które to robią, natomiast ja jednak nie puszczam pary, chociaż akurat ta akcja, z uwagi na swój publiczny charakter, w zasadzie, można powiedzieć, tajemnicą żadną nie jest. Natomiast w ramach tej akcji padł pomysł, aby wyzwać programistów z firm Elona Muska, tutaj bardziej z tych już istniejących firm, które należały do niego od dłuższego czasu, czyli najbardziej to chyba z Tesli - aby wziąć programistów z jego firm, wyzwać na pojedynek i w przypadku wygranej miałoby to zdecydować o zatrudnieniu ludzi z Polski. Oczywiście cały ten pomysł był nastawiony na taką showmańską postawę Elona Muska, natomiast natchnął mnie on właśnie do nakręcenia tego odcinka, ponieważ zacząłem się zastanawiać, co właściwie w tych naszych obecnych czasach, co jest ważne, że mówimy o bieżącej perspektywie, znaczy bycie świetnym specjalistą IT — nie ukrywam, najczęściej  skupiam się na programistach i programistkach.

Kiedyś sytuacja była prosta i od razu dodam, że przez „kiedyś” mam na myśli mniej więcej takie dwadzieścia lat temu, kiedy sam dopiero stawiałem pierwsze kroki w świecie IT, obserwowałem właśnie to, jak starsi koledzy, koleżanki, jakieś dzieci znajomych starszych, moich rodziców, starały się rozwijać właśnie w fachu informatycznym czy wprost programistycznym. Kiedyś to było tak, że o przyjęciu na studia, o dobrych ocenach - czy to w szkole czy to właśnie na studiach - o sukcesach w konkursach, od olimpiady informatycznej przez konkursy takie, jak chociażby znany konkurs TopCoder, liczyły się zdolności matematyczno-algorytmiczne. Osoby, które osiągały sukcesy w takich konkursach i studiowały na najbardziej prestiżowych kierunkach, jak chociażby informatyka na słynnym warszawskim MIM-ie, na Uniwersytecie Warszawskim, miały szansę na najlepsze posady w Polsce, ale też zwłaszcza za granicą, wówczas w firmach takich modnych, jak Microsoft. Wtedy jeszcze hegemon rynku software’owego, czy również może w tamtych czasach, dwadzieścia lat temu, to już nie był do końca startup, ale wciąż bardzo młody Google, raptem istniejący kilka lat. Jak to się kiedyś mawiało, brzmi to trochę staro, ale cóż – w informatyce to jest cała epoka.

Kiedyś uważało się, że świetny programista wcale nie powinien mieć szóstki z informatyki, tylko szóstkę z matematyki. Z informatyki można było mieć nawet i dwójkę, trójkę, natomiast to właśnie umiejętności matematyczne decydowały o sukcesie późniejszego programisty, programistki. Gdybyśmy posługiwali się tym kryterium, to sprawa byłaby prosta. W takich dwóch zespołach, jeden nasz, polski, drugi Muskowy, ktoś zewnętrzny opracowuje zadania, dajemy tym zespołom zadania algorytmiczne do rozwiązania. Kto zrobi lepsze, szybciej działające rozwiązania, ewentualnie też kto zrobi po prostu szybciej te rozwiązania, wygrywa. I pod kątem, że tak to ujmę, sportowym, jest to rozwiązanie na pewno właściwe, ale zastanówmy się, no właśnie – czy jeżeli mamy takich świetnych algorytmików, to czy możemy powiedzieć, że w obecnych czasach są to stricte najlepsi specjaliści?

Nie da się tak naprawdę odpowiedzieć na to tytułowe pytanie, gdzie znajdziemy tych programistów, bez stwierdzenia, co to znaczy być najlepszym programistą, programistką, szerzej - specjalistą IT. I mówiąc szczerze, o tym właśnie jest ten odcinek. Kontynuując tę metaforę sportową, obecnie programowanie, tworzenie oprogramowania, to nie jest sport indywidualny. Bardzo rzadko, przynajmniej rozpatrując jakiś projekt, jakieś przedsięwzięcie w dłuższym terminie, liczy się taka samodzielna zdolność, umiejętność zrobienia projektu od A do Z, w pojedynkę. To jest trochę tak, jak z piłkarzami, ten odcinek będzie publikowany jeszcze w czasie trwania mistrzostw, nagrywam go, już jak mistrzostwa trwają. I odnosząc się właśnie do piłki nożnej, celem piłkarza nie jest zostanie królem strzelców. To znaczy może to być jakiś cel poboczny, natomiast myślę, że większość, jak nie wszyscy piłkarze zgodziliby się, że gdyby mieli wybrać między koroną króla strzelców a zostaniem mistrzem świata w drużynie, chyba to drugie trofeum jest zdecydowanie lepsze. Natomiast taki napastnik powinien skupiać się na tym, aby w każdym meczu jego drużyna strzeliła o tę jedną bramkę więcej, nawet, jeżeli to nie będzie jego bramka.

Tak samo działa to w IT. Nawet najlepsze umiejętności techniczne, takie indywidualne, mogą okazać się mniej istotne, niż właściwe zrozumienie problemu, który chcemy rozwiązać, a także umiejętność dogadania się z zespołem w sprawie realizacji określonego celu. Duże znaczenie w tej jakości specjalistów ma fakt, że dzięki ciągle zwiększającej się liczbie programistów i programistek, dzięki coraz większemu postępowi w rozwoju technologii programistycznych, ale też, przede wszystkim, dzięki rozwojowi Internetu, obecnie znalezienie różnych rozwiązań związanych z występującymi w trakcie tworzenia oprogramowania problemami technicznymi, jest dużo prostsze niż dwadzieścia lat temu. Dawniej wiele rzeczy trzeba było po prostu umieć zrobić samemu, bo nie można było w Internecie znaleźć rozwiązań, nie było aż tak dużo osób do pomocy czy to na miejscu czy przede wszystkim w Internecie, było też mniej narzędzi technologicznych i mniej narzędzi dostępnych po prostu od ręki. Nawet za mojej pamięci, choć ja, nie przesadzajmy, aż tak stary nie jestem. Kwestia sieci neuronowych, kiedy ja na studiach uczyłem się sieci neuronowych w okolicach roku 2009, 2010, to bardzo niewielkie było wsparcie dla rozwoju sieci w Internecie, znaczy - były takie rozwiązania, z których można było skorzystać, ale był to zupełnie inny poziom niż ten, z którym mamy do czynienia teraz. Dotyczy to nie tylko samych dostępnych narzędzi, ale również wszelkich materiałów, dokumentacji, tego, co ułatwia proces uczenia się, poznawania takich metod, takich narzędzi. Taka konstatacja jest może smutna dla takich starych wyjadaczy, którzy pamiętają te czasy, natomiast obecnie, w takiej zwykłej, codziennej pracy, nie ma z reguły potrzeby takich hardcore’owych, chciałoby się rzec, działań, wynajdowania pewnych rzeczy czy budowania od zera. Mówię to też jako jednak programista, któremu też zdarzało się w przeszłości pracować nad różnymi trudnymi problemami. Choć Google istniał, to nierzadko otrzymywałem po prostu zero wyników na napotkany problem i też trzeba było sobie jakoś radzić. Obecnie coraz większe znaczenie mają umiejętności interpersonalne. I nawet, jeżeli dana osoba, dany programista nie będzie w stanie wymyślić jakiegoś genialnego rozwiązania, nie zaimplementuje nam w jakiś niesamowicie wydajny sposób ważnego algorytmu, ale będzie taka osoba lepiej komunikować się w zespole, będzie lepiej rozumieć założenia biznesowe, kontekst, w którym dane zadania, dany projekt jest realizowany, to może się okazać, że taka osoba wniesie więcej do osiągnięcia celu w danym projekcie, czyli celem z reguły jest stworzenie oprogramowania, które spełnia jakieś założenia klienta. I właśnie – bardzo ważne, ponownie, zwłaszcza w tych naszych obecnych czasach, latach dwudziestych, jest zrozumienie biznesu klienta, czy też zrozumienie biznesu firmy, w której pracujemy.

Tak mówię o biznesach klientów troszkę z perspektywy software house’u, w którym działam na co dzień, natomiast to samo dotyczy sytuacji, w której na przykład pracujemy na rzecz jednego pracodawcy, bo to też jest jakiś biznes, jakaś organizacja, na rzecz której pracujemy. Natomiast zmiana, bo tutaj ponownie, moim zdaniem, nie było to aż takie istotne, te, powiedzmy, dwadzieścia lat temu, a zmiana bierze się stąd, że obecnie znacznie więcej programistów czy programistek pracuje w software house’ach, czyli w firmach, które, tak naprawdę, te dwadzieścia lat temu nie za bardzo istniały. Znaczy były oczywiście takie firmy, które zajmowały się tworzeniem oprogramowania na rzecz podmiotów trzecich, ale było ich po prostu mniej. Też wydaje mi się mniej popularną formą była praca na zasadzie freelance, bycia wolnymi strzelcami, powiązań z jakimiś kontraktowniami. Obecnie też często nawet firmy, które nie są firmami stricte IT, tworzą zespoły deweloperskie, głównie dlatego, że taki zespół tworzy, realizuje usługi na rzecz innych działów w firmie. Kiedyś te dwadzieścia lat temu, był znacznie większy nacisk na firmy, które rozwijały własne produkty. A z uwagi na to, że po prostu było mniejsze zapotrzebowanie na cyfrowe usługi, ten stopień cyfryzacji społeczeństwa był po prostu mniejszy, mniej było potrzebnych aplikacji, na rynku było potrzebne mniej oprogramowania, a jednocześnie już jak coś, jakiś produkt powstawał, to z reguły były to produkty tak duże, że programiści, którzy trafiali do zespołów projektowych, realizujących takie aplikacje, mogli tam pracować całymi latami a nawet i dłużej. Praca stricte na zamówienie też istniała, czyli bardziej taki software house’owy sposób działalności, ale raczej dotyczyła przetargów publicznych czy innych bardzo dużych organizacji, gdzie również, jak znaleźliśmy pracę w takim molochu, powiedzmy, to raczej projekty nie zmieniały się zbyt często. Natomiast wszystkie te założenia sprawiały, że programiści nie musieli co chwilę, taką powiedzmy, co parę miesięcy, co rok, uczyć się, poznawać nowych branż, nowych rynków, nowych technologii i po przystosowaniu się do danego produktu mogli go całymi latami spokojnie rozwijać.

Z jednej strony jest to może dla niektórych dość komfortowe, natomiast niewątpliwie zmniejszało to wagę kwestii komunikacyjnych, zrozumienia celów biznesowych, bo choć oczywiście realizacja takich projektów naturalnie wymagała komunikowania się na bieżąco, to jednak zespoły były z reguły zdefiniowane w sposób stały, było to środowisko pracy bardzo dobrze znane. Kierunek rozwoju też raczej w takich dużych projektach się mocno nie zmieniał, więc po prostu dynamika tych wszystkich procesów była dużo, dużo mniejsza. Poza tym, nie da się ukryć, że nawet z punktu widzenia inżynierii oprogramowania, techniki zwinne, czyli agile, o którym wspominałem w odcinku siedemnastym, techniki te były znacznie mniej popularne – dopiero zaczynały zdobywać szersze uznanie. A dominujący wcześniej model kaskadowy, czyli waterfall, zakładał pracę etapami, gdzie znowu, ta bieżąca komunikacja z klientem, zwłaszcza z perspektywy zespołu deweloperskiego po prostu nie była taka istotna.

Jak widać, to, jak możemy postrzegać programistów, programistki, zmieniło się mocno w czasie. Nie możemy wykluczyć, że jeszcze się nie zmieni, to wszystko jest kwestia niezwykle płynna, natomiast możemy się przymierzyć do odpowiedzi na tytułowe pytanie, czyli gdzie znajdziemy tych najlepszych programistów. W Polsce, oczywiście. Byłoby dziwnym, gdybym odpowiedział inaczej, ale mówiąc już poważnie – jednoznaczna odpowiedź na to pytanie jest oczywiście trudna, czy też nawet niemożliwa, bo to bardzo dużo zależy od kontekstu. Natomiast nie da się ukryć, że programiści w  Polsce z jednej strony mają oczywiście te uzdolnienia, które tak naprawdę wspierają ich w rozumieniu problemów, w implementacji wydajnych rozwiązań, są bardzo mocni polscy programiści od tej strony matematyczno-algorytmicznej. Natomiast ważne jest to, że te kwestie komunikacyjne, te umiejętności miękkie, nie powiem, że są idealne, ale uważa się, że Polacy, nawet może bardziej, niż kwestie miękkie, mają taki dryg do rozwiązywania problemów i patrzenia szerzej. Można powiedzieć, że jest to chyba konsekwencja, biznesowa konsekwencja takiej naszej cechy narodowej, czyli umiejętności radzenia sobie w każdej sytuacji. To jest taki nasz swoisty spryt, i to jest absolutnie nasza zaleta. I w porównaniu do innych krajów, nie chcę za bardzo powielać stereotypów, ale są to zasłyszane opinie z innych krajów oczywiście, bo trudno, żebym pytał o to innych znajomych z Polski, natomiast mówi się, że przedstawiciele niektórych krajów, konkurujących z nami, są nierzadko równie dobrzy, czy podobnie dobrzy w realizacji zadań, natomiast brakuje im trochę takiego szerszego spojrzenia. Właśnie brakuje im sprytu, brakuje im takiej dbałości, takiego dodatkowego aspektu. Za bardzo skupiają się na technicznej realizacji zadań. Jest to oczywiście pewien stereotyp, bo to nie dotyczy, siłą rzeczy, wszystkich, ale cóż, działa on na naszą korzyść – naszą, czyli deweloperów z Polski, więc myślę, że warto tylko dbać, aby nie był to pusty stereotyp i abyśmy wszyscy jak najlepiej pracowali na rzecz wszystkich zainteresowanych usługami polskich deweloperów.

Na tym kończymy dzisiejszy odcinek, jest to ostatni odcinek przed świętami. Mówię oczywiście o dacie publikacji, Mundial jeszcze trwa, no, gdy będziecie słuchać te słowa, mam nadzieję, że Polacy będą jeszcze grali, chociaż, no, jest to tylko nadzieja, ale może się uda. Natomiast niezależnie od tego, życzę wszystkim zdrowych i spokojnych świąt. Może nawet przede wszystkim spokojnych, a że życzę sobie tego samego, to z podcastem wrócimy już po Nowym Roku, każdy zasługuje na trochę odpoczynku.

A teraz nie pozostaje mi nic innego jak podziękować za uwagę, za wysłuchanie tego odcinka. Kłaniam się nisko i do usłyszenia.