Jedlinski.pl devblog

Czy zastanawialiście się kiedyś jakie są cechy najlepszych programistów? Co sprawia, że jedni osiągają sukces a inni pracują całe życie w małych, nic nie znaczących firemkach, bez perspektyw na rozwój (i podwyżkę)? Jak to się dzieje, że mamy z jednej strony świetne, intuicyjne oprogramowanie, a z drugiej kompletnie beznadziejne śmieci - co prawda z mnóstwem bajerów, ale w gruncie rzeczy bezużyteczne?

Zdawałoby się, że odpowiedź jest prosta - dobry programista to taki, który (niespodzianka!) dobrze programuje, czyli zna na wylot język, w którym to robi i potrafi sprawić, by dana funkcjonalność zadziałała. To jednak nie wystarcza - znam wielu programistów tworzących mnóstwo linii kodu na minutę i dobrych w rozwiązywaniu algorytmów, których bym nie zatrudnił. Opanowanie technologii nie wystarcza.

Poniżej postaram się opisać kilka kluczowych elementów stanowiących o tym, że niezły koder staje się świetnym programistą:

• Pasja - zawsze trudno mi zaufać komuś, kto mówi, że jest programistą a pierwszy program stworzył na studiach informatycznych. Najlepsi programiści piszą swoje pierwsze linie kodu w podstawówce, najpóźniej w gimnazjum. Znają co najmniej kilka języków programowania, nieważne, że wiele z nich słabo - świadczy to raczej o odkrywaniu i poszukiwaniu. Rozumieją i są zainteresowani nowinkami w branży - jeżeli w 2007 roku nie słyszeli o Ruby czy Pythonie, to prawdopodobnie jest coś z nimi nie tak.
• Komunikacja z otoczeniem - programowanie to wbrew pozorom także praca z ludźmi. Bardzo rzadko zdarza się sytuacja, w której otrzymujesz pełną, szczegółową specyfikację i bez szemrania zabierasz się do implementacji. Zwykle najpierw musisz poznać potrzeby osób, dla których tworzone jest oprogramowanie - ich nawyki, typowe problemy, wreszcie cele, które chcą osiągnąć. Programista musi umieć z nimi rozmawiać (czy to bezpośrednio, czy za pośrednictwem project managera), dopytywać o szczegóły, wyjaśniać wątpliwości.
• Samodzielność - pytanie o szczegóły jest ważne, aby poznać potrzeby klienta. Jednak programista, który pyta czy komunikaty o błędach zrobić czerwoną czcionką na białym tle czy odrotnie, to zły znak. Po pierwsze, wystarczy spojrzeć jak to było zrobione w innych projektach czy w innych częściach tego samego projektu. Po drugie, jest to sprawa zupełnie nieistotna - jeżeli uznamy, że trzeba zrobić to na czerwonym tle a zostało zrobione czerwoną czcionką - zmiana tego to kilka sekund. Jeszcze gorzej jeżeli programista dostał w specyfikacji tylko notkę, że w tym a tym miejscu mają się pojawiać błędy i w ogóle nie zastanawia się jak wyróżnić informację o nich - więc po prostu je wyświetla, bez żadnego specjalnego formatowania, bo przecież w specyfikacji nic nie było. Nie myśli, nie proponuje rozwiązań, nie wnika.
• Krytyczne spojrzenie - bardzo często zdarza się, że specyfikacja projektu jest sucha, czy wręcz błędna. Klient pisze w niej co mu ślina na język przyniesie, bez specjalnego zastanowienia. W końcu jest klientem, niekoniecznie ma umysł analityczny i niekoniecznie zastanawia się nad każdą możliwością. Czasami ma dodatkowo własne przyzwyczajenia, które narzucają mu pewne rozwiązania (np. tak to działało w programie, który używał wcześniej). Czasami po prostu nie wie, że jest możliwość zrobienia czegoś lepiej, ponieważ nie zna ograniczeń technologii czy nie zastanawia się nad nimi. Dobry programista powinien takie rzeczy wyłapać - zaznaczyć, że to i to nie będzie działało sensownie (np. będzie wymagało od użytkownika zbyt dużo zachodu, więc zrezygnuje), a tamto można zrobić fajniej, bardziej zautomatyzować proces czy uczynić go bardziej spójnym z pozostałymi. Specyfikacja nie jest święta a klient nie jest wyrocznią… jednak z drugiej strony, wszelkie zmiany i usprawnienia trzeba przedyskutować - wprowadzanie ich bez konsultacji może okazać się zupełną pomyłką.
• Wczucie się w rolę użytkownika - jedną z najbardziej typowych wpadek nawet niezłych programistów jest brak podejścia od strony użytkownika. Mamy dany problem i rozwiązujemy go tak, jak sugeruje struktura bazy danych czy stworzony już kod. Na przykład w naszej strukturze są obiekty typu “zamówienie” i każde z nich przypisane jest do jakiegoś obiektu typu “klient”. Nie da się więc stworzyć “zamówienia” bez “klienta”, ergo nie da się zamawiać bez rejestracji / logowania. Jeżeli więc w specyfikacji nie ma szczegółowych kroków składania zamówienia, nasz programista po prostu zrobi to, co mu narzuca struktura - znienawidzony przez użytkowników formularz rejestracji.

Ktoś może stwierdzić, że większość powyższych cech nie dotyczy programisty - tylko project managera. W końcu to on komunikuje się z klientem, on tworzy wraz z nim specyfikację, wreszcie on mówi grafikowi gdzie co ma się znaleźć. Ale tak naprawdę każdy dobry project manager był kiedyś programistą, tylko przeszedł na wyższy level :)