Nie rozumiem zupełnie wypisywania litanii wszystkich znanych systemów operacyjnych komputerów PC, od DOS-a począwszy. Naprawdę nie wiem, czym kandydat "z Windows NT" różni się od tego "z Windows 2000", i czy lepszy jest ten znający nazwy sześciu systemów, czy ten znający nazwy siedmiu. Gdybym zaczął wypisywać takie rzeczy w swoim CV, to w zakresie systemów operacyjnych zaczynałoby się to mniej więcej tak: "Executor, George 3, IBM OS/360 MFT, IBM OS/360 MVT", a dalej wszelkie odmiany DOS-a, Windowsa, Linuxa. Niemniej, wziąwszy pod uwagę życiorysy innych ludzi, chyba zacznę wyszczególniać to wszystko i zrobi się z tego pamiętnik informatyka. Cóż, długi staż, to i bogaty życiorys.

Wymienianie systemów operacyjnych z nazwy i gatunku ma sens, jeżeli ktoś zajmował się administrowaniem heterogenicznymi sieciami, bo jest to pewien wskaźnik trudności. W innych okolicznościach nie powinno mieć to istotnego znaczenia. Włączamy komputer z Windowsem i pracujemy - i co za sztuka, i co za wiedza? Pracuję codziennie na kilku komputerach - na jednych jest wersja 2000, na innych XP, ale naprawdę nie zwracam na to uwagi. Co ciekawe, kandydaci często wyszczególniają wersję systemu Windows, ale praktycznie nigdy nie podają, z jaką wersją Linuxa dane im było pracować. Zaiste symptomatyczne to zjawisko. Linux w życiorysach zawodowych jest zawsze jeden, nie Mandrake, nie Debian lub SuSE, ale po prostu Linux.

Jeśli kandydat na programistę wyszczególnia kilka języków programowania jako swoje umiejętności, jednocześnie mając roczne doświadczenie w tworzeniu portalu internetowego w oparciu o konglomerat PHP/MySQL, to można mieć tylko pewność, iż jedyną jego umiejętnością jest właśnie język PHP oraz baza danych MySQL. Idąc dalej, można - logicznie, ale nie zawsze celnie - mniemać, że skoro PHP dojrzał obecnie do obiektowości, to kandydat będzie zręcznie poruszał się także w tematyce obiektowej w każdym środowisku programowania. Jest to w tym przypadku założenie zbyt wybujałe, gdyż PHP to nie Java i można się w nim bez obiektów i klas swobodnie obejść, stosując jedynie proceduralne metody konstrukcji kodu. Tak samo nie można mieć pewności, czy stworzone za pomocą tych narzędzi rozwiązania internetowe były bezpieczne. Podobnie sprawa ma się z próbami indukowania umiejętności w zakresie baz danych na inne niż MySQL serwery. Można stwierdzić, że nawet w zakresie podstawowej funkcjonalności nie jest to możliwe ze względu na bardzo poważne ograniczenia MySQL¹. Niektórzy kandydaci na programistów zdobywają się na odwagę i publikują fragmenty kodu własnej produkcji, uważane przez nich za bardziej znamienne dla ich twórczości. Niestety, bardzo często te przykłady obnażają całkowitą nieporadność programistyczną. Aby jednak stwierdzić ten fakt, kod musi zostać oceniony przez specjalistę dziedzinowego. Nie upora się z tym zadaniem nawet najlepszy fachowiec od zasobów ludzkich.

Wyszczególnionych w życiorysie umiejętności nie można traktować w sposób wyizolowany z kontekstu. Zawsze należy zestawić te dane z faktami, jakimi są staż pracy i udział w konkretnych projektach i usługach. Nie bez znaczenia jest także rozmiar owych projektów czy firm, dla których świadczyło się usługi. I wreszcie interpretacja słowa "umiejętność" przez świeżo upieczonego absolwenta uczelni i praktyka z 10-letnim stażem w danej dziedzinie nie może oznaczać tego samego poziomu merytorycznego.

Podobne w niepodobnym

Można przyjąć, że programista od lat pracujący w tym samym środowisku narzędziowym i ciągle rozwiązujący podobne problemy algorytmiczne z czasem nabierze takiej biegłości w temacie, że niemal nie będzie miał sobie równych w tej akurat dziedzinie. Jeśli jest to osoba bystra, to zmiana środowiska programistycznego, chociaż przyniesie konieczność intensywnej nauki nowych rzeczy, nie skończy się tragedią. Jednak wielu programistów, którzy lata strawili na produkcji systemów księgowych w Clipperze, jest niemodyfikowalnych i nie ma siły, aby bezboleśnie "przesiedli się" na obiektową Javę i nowoczesną relacyjną bazę danych. Przeciwieństwem zasiedzenia w temacie jest przeskakiwanie z kwiatka na kwiatek. Niektórzy, najczęściej są to studenci, lizną to i owo z kilku współczesnych języków obiektowych, po czym obwieszczają wszem i wobec, że są to ich umiejętności. Fakt, że języki obiektowe wykazują wzajemnie analogię, jednak nie do końca. Diabeł zawsze tkwi w szczegółach. Poza podobieństwami w zakresie wielu instrukcji odmienne są np. zasady dziedziczenia (np. Java nie oferuje wielodziedziczenia), dynamicznych i statycznych struktur danych, operacji na wskaźnikach. Ktoś, kto w życiu zawodowym praktykował tylko w Javie czy Visual Basicu zdziwi się, że w C lub Pascalu występują odwołania wskaźnikowe. Czytając opis języka C#, znajdziemy w nim konglomerat rozwiązań znanych zarówno z C, jak i z Javy. Z językami programowania zaczyna dziać się jak z modą: trudno wymyślić coś oryginalnego, więc pojawiają się różne mutacje znanych z historii fasonów. Programista znający N języków nie będzie miał trudności w koncepcyjnej adaptacji do języka N+1, co nie jest wszakże równoznaczne z biegłością w każdym nowym środowisku. Do wszystkiego potrzebna jest wprawa, a do jej nabycia niezbędny jest czas.

W każdym środowisku programistycznym występują odmienne komponenty, w związku z czym oferowane są inne metody i właściwości. Zmiana środowiska programistycznego to nie problem składni języka, ale przede wszystkim odmiennej metodyki postępowania. Aby daleko nie szukać, wystarczy porównać, jak podchodzi się do zdarzeń w Visual Basicu i Javie. W jednym i drugim środowisku można oprogramować zdarzenia, ale jakże inaczej to się implementuje. Wiele można pisać na temat kardynalnych podobieństw i różnic między poszczególnymi językami programowania. Oprócz samego zestawu instrukcji i metod (zasadnicze różnice pomiędzy językami proceduralnymi i obiektowymi), tworzeniu oprogramowania służy najczęściej zintegrowane środowisko programisty, zwane skrótowo IDE². Mało kto dziś koduje wszystko od podstaw, odżegnując się od wielu mechanizmów wspomagających, w tym narzędzi RAD³. Oprócz tego, aby oprogramowanie mogło cokolwiek pożytecznego robić, zazwyczaj niezbędna jest współpraca z bazą danych. Mało kiedy programiście sprzyja szczęście i może wykonywać pracę polegającą na kodowaniu bardzo sprytnych algorytmów bez całej żmudnej dłubaniny w otoczeniu baz danych i uciążliwych raportów. Niestety, te dwie rzeczy zazwyczaj towarzyszą wszystkim produktom tworzonym na rynek komercyjny.

Aby stworzyć najprostszą stronę w technologii ASP, trzeba znać po trosze HTML, VBScript, ADO, SQL. To jest tylko część powłoki programistycznej. Programista może mówić o szczęściu, jeśli do dyspozycji ma jakiegoś administratora, który wspomoże go w skonfigurowaniu serwera WWW oraz serwera baz danych. No i ktoś oczywiście musi wykonać projekt schematu bazy danych z właściwą temu zagadnieniu normalizacją. A wszystko po to, aby w firmowym intranecie można było sprawdzić numer telefonu pracownika, wyszukując go po nazwisku.

Wykonanie jakiegokolwiek, nawet najprostszego projektu wymaga od programisty wiedzy o wielokrotnie większej liczbie zagadnień, aniżeli tylko znajomości samego języka programowania.

Aby taką wiedzę posiąść, należy osobiście wykonać kilka drobnych lub chociażby jeden większy projekt. Wziąwszy pod uwagę, że podczas czynności programowania czas ucieka nieubłaganie - zarówno w subiektywnym odczuciu programistów, jak również w wymiernych wartościach obiektywnych - nie można dawać wiary, że autor oprogramowania jest w stanie w ciągu roku zdziałać zbyt wiele. Inną jeszcze miarą jest jakość tworzonego kodu - na ile jest on elastyczny, bezbłędny oraz jakie prezentuje sobą walory użytkowe. Podobny funkcjonalnie program, "niezaprzątający sobie głowy" walidacją danych, bywa tworzony wielokrotnie krócej, aniżeli jego odpowiednik wyposażony w "inteligentne wspomaganie". Oprogramowanie z drukowanymi raportami a takie samo oprogramowanie bez tych opcji to także dwa zupełnie różne produkty - nie tylko w sensie funkcjonalnym, ale przede wszystkim pod względem czasu poświęconego na ich tworzenie.

Raczej trzeba ostrożnie z deklarowaniem umiejętności - to z jednej strony, a z drugiej - należy lepiej przyglądać się owym deklaracjom. Niektórzy mylą programowanie obiektowe z obiektami graficznymi "uśmiechającymi się" z GUI. Fakt, że wchodzą one najczęściej w zestaw bibliotek komponentów i są obiektami przypisanymi do określonych klas, niemniej obiektowość nie jest warunkiem koniecznym pojawiania się okien, przycisków i list rozwijalnych. Jak twierdzą niektórzy, dzięki udanemu połączeniu obiektowych języków z graficznym interfejsem zaczęło się to dobrze sprzedawać - o czym w głównej mierze decydowała atrakcyjna szata graficzna. Bywają i teraz ludzie na eksponowanych stanowiskach w dużych firmach programistycznych, utożsamiający obiektowość jedynie z graficznym środowiskiem IDE i możliwością przesuwania obiektów myszą na ekranie. Nie zostałem jednak upoważniony do publikowania ich nazwisk, więc każdy z Czytelników powinien rozejrzeć się wokół siebie. Są to zapewne ci, którzy kandydowali na intratne stanowiska z bogatą listą umiejętności programistycznych, dokumentując to na papierze kilkoma chwytliwymi nazwami języków programowania i pakietów narzędziowych, o jakie otarli się na studiach. Oczywiście nie wszyscy studenci robią tylko dobre wrażenie. Jest wśród nich spora grupa, których umiejętności są dużo więcej warte niż umiejętności ich kolegów. Po prostu trzeba mieć talent i zdobyć odpowiednie doświadczenie. Tak właśnie wykuwa się dobry programista. A po czym można go poznać? O tym w drugiej części.

Drugą część tekstu Piotra Kowalskiego nt. pozyskiwania pracowników opublikujemy w Raporcie Computerworld "Zarzadzanie funkcjami IT w przedsiębiorstwie", który ukaże się w listopadzie br.

¹ MySQL np. nie oferował do niedawna wyzwalaczy (triggerów). Zostały one wprowadzone dopiero od wersji 5.0.2, ale na razie są i tak nieczułe na zdarzenia generowane przez akcje kaskadowe klucza obcego

² IDE - Integrated Development Environment

³ RAD (Rapid Application Development) - technika szybkiego tworzenia oprogramowania umożliwiona dzięki odpowiednim narzędziom programistycznym, tzw. narzędziom RAD, wspomagającym i automatyzującym tworzenie kodu