Pewnych nawyków ciężko się pozbyć. Mówi się często o tym, jak ważne są pierwsze odruchy, jakich nabieramy podczas nauki gry na instrumencie. Samoucy natrafiają często na trudności na późniejszym etapie, gdy zmuszeni są oduczyć się błędnych zachowań. Dlatego wynajmujemy dzieciom nauczycieli lub posyłamy je do szkół muzycznych…
Programowanie jest niezwykle dynamiczną dziedziną, z którą jako kraj przez wiele lat nie mieliśmy styczności. Choć na poziomie akademickim pewne techniki i rozwiązania mają już swoje lata i niektórzy twierdzą, że nihil novi sub sole, to jednak wciąż rodzą się nowe strategie radzenia sobie z problemami, nowe pomysły, technologie i języki.
Większość programistów w Polsce nauczyła się programować na studiach. I choć brzmi to niebywale – w większości z nas wciąż tkwią nawyki z tamtego okresu. Nie są to nawyki chlubne. Krajowe uczelnie jak można się dowiedzieć z dowolnego rankingu nie są najlepszymi uniwersytetami świata, a realia wydziałów informatycznych są chyba jeszcze gorsze, niż polskich akademii ogólnie.
Oczywiście mówi się wiele o sukcesach naszych studentów, o wysokich pozycjach polskich programistów w rankingach i tak dalej, ale niestety odpowiedź na pytanie – jakie więc świetne produkty stworzyliśmy? – ogranicza się do gier CD Project oraz platform UXPin, Brand24, czy CodeWise. Oczywiście pod cudzymi markami piszemy o wiele więcej, ale wbrew tłumowi pozwolę sobie być sceptyczny, co do naszych umiejętności – nie u nas urodził się Torvalds, ani Stroustrup, Dijkstra, czy Knuth. Trzeba nam pokory i praktyki.
Uczelnie zatem wpoiły nam złe nawyki. Jakie konkretnie?
1. Przedwczesna optymalizacja
Jak rzekł wspomniany tu już Donald Knuth – przedwczesna optymalizacja jest źródłem wszelkiego zła. Tymczasem na nauce klasycznych algorytmów oraz progresji ku wydajności skupia się program nauczania informatyki na uczelniach. Uczy się studentów sortowania bąbelkowego, by potem pokazać im lepsze, wydajniejsze. Wiele przedmiotów dotyczy głównie na optymalizacji – uczymy się o drzewach BST, o algorytmach grafowych, niektórzy również o kompresji. Wpaja to w studentów przeświadczenie, że wydajność jest okrutnie ważna, najważniejsza. Tymczasem w projektach biznesowych rzadko tak jest.
2. Brak edukacji w zakresie planowania dużych projektów
Ze studiów pamiętam dziesiątki projektów małych, ani jednego wielkiego. Nie organizuje się grupy kilkunastu osób, by wykonały coś dużego, ale zleca pojedynczym studentom malutkie programiki do napisania w pojedynkę. Nie daje to szans na nabycie umiejętności zarządzania wielkim projektem, radzenia sobie z problemami większymi od pojedynczego programisty – a tylko takie projekty spotykamy później w firmach. Dzielenie projektów na etapy, estymacja zadań, ustalanie priorytetów – te kwestie są w edukacji akademickiej nieobecne.
3. Samotnictwo a.k.a. brak umiejętności pracy w grupie
Jak w poprzednim punkcie wspomniałem – projekty na polskich uczelniach są małe, przeznaczone dla jednego studenta na tydzień lub miesiąc, czy dwa. Pociąga to za sobą spore konsewkwencje nie tylko na płaszczyźnie zarządzania projektem. Programiści samotnicy nie mają szans nauczyć się pisać czystego kodu. Pisząc krótko i w pojedynkę nie mogą pojąć wykładu o czystym kodzie, jeśli taki się pojawi. Te problemy dopadną ich dopiero w pracy. Tak samo zresztą jak umiejętność kooperacji z kolegami. Na studiach widziałem wielu, nieraz świetnych, studentów, którzy kompletnie nie potrafili pracować we dwójkę, nie mówiąc o większej grupie. Narcystyczni, outsiderscy, z przerośniętym ego – tacy ludzie dopiero w pracy napotykają na olbrzymie trudności, przez studia przechodząc nieraz z wielkimi sukcesami.
4. Piśmienni, ale nie „czytelni”
Wiele, jeśli nie większość, projektów biznesowych posiada rozbudowane repozytoria istniejącego kodu. Rzadko zdarzają się greenfields, w których można sobie pozwolić na kreatywność i tworzenie z pominięciem lektury cudzego kodu. Czytania jednak studia nie uczą. Poza zrozumieniem algorytmów, gdzie raczej o zrozumienie konceptualne idzie, a nie o czytanie konkretnego zapisu w wybranym języku programowania, nie ma na akademiach przedmiotów związanych z czytaniem kodu źródłowego ze zrozumieniem. Jest to tymczasem kluczowa umiejętność w codziennej pracy każdego profesjonalnego programisty.
5. Dokumentacja? Komu to potrzebne?
Nie licząc pracy magisterskiej i kilku raportów – nigdy na uczelni nie musiałem dokumentować stworzonego oprogramowania. Oczywiście nie każdy aspekt projektu opisywać słownie należy, ale podejście, z jakim się spotkałem na uniwersytecie polegało na oczekiwaniu, by kod działał, niekoniecznie jednak na opisaniu go. Liczył się rezultat, wynik, wyjście, przy zadanym wejściu. Nigdy nie stawiano nacisku na to, co jest w oprogramowaniu niezwykle istotne i stanowi żywotny interes przedsiębiorstw – na utrzymywalność, dokumentację, na transfer wiedzy.
Co zatem robi świeżo upieczony junior magister, o ile jedyne czego się nauczył to program studiów? Nie dokumentuje, pisze bałaganiarski kod, nie wie jak estymować, nie ma pojęcia o ustalaniu priorytetów, nie wie jak się dogadać z kolegami, boi się deadline’ów i nie umie rozmawiać z biznesem, pisać kod potrafi, ale czyta z trudem.
Obyśmy dożyli czasów, gdy akademie zreflektują się, jak ułomne są efekty ich pracy i podejmą próby uzdrowienia sposobu w jaki uczą…