Najważniejsza rada do jakiej powinieneś się zastosować jako początkujący programista
Ten artykuł teoretycznie mógłbym być bardzo krótki, albowiem rada jaką chcę dać wydaje się być naprawdę banalna, jednak po 8 latach w zawodzie programisty przy każdym wdrożeniu nowej osoby do projektu widzę, że ten problem się powtarza.
Rada o którą mi chodzi brzmi: Pytaj!
Na czym polega profesjonalism
Osoby początkujące, zwłaszcza w świecie IT, mają tendencje do próbowania robienia wszystkie na własny rachunek. Gdy junior software developer zaczyna swoją pracę w nowym projekcie, przede wszystkim chce sie wykazać, udowodnić, że jest samodzielny i potrafi sam skończyć zadanie mu przydzielone. Problem jest w tym, że paradoksalnie nikt od niego tego nie oczekuje.
"Know How" projektu vs. Indeks Google
By zdać sobie sprawę w jakiej sytuacji są tak naprawdę początkujący programiści, musimy przypomnieć sobie z czego tak naprawdę składa się typowy projekt informatyczny. W większości przypadków taki projekt jest rozwijany już od kilku dobrych miesięcy jeżeli nie lat.
Ponadto, o ile projekt jest prowadzony z myślą o konkretnym kliencie, pełno jest w nim miejsc, w których dostosowuje się on do szczególnych wymogów klienta. Gdyby tak nie było, klientowi wcale nie opłacało by się płacić tyle pieniędzy za specjalną wersje oprogramowaina specjalnie dla niego.
To wszystko sprawia, że taki projekt jest pełen miejsc, w którym decyzje mające uzasadnienie biznesowe wpływały na to, jak dana rzecz ostatecznie została zaimplementowana w kodzie. Wynika z tego fakt, że każdy projekt jest unikalny.
Jest to szczególnie ważne, gdyż w przypadku gdy projekt jest close-source, oznacza to, że Google w niektórych przypadkach nam za wiele nie pomoże - bo po prostu nic o danym projekcie ani o błędach w nim występujących nie wie.
Osoby z większym doświadczeniem potrafią odróżnić błędy typowe (błędy języka programowania, frameworka, systemu operacyjnego) od błędów projektowych - to jednak przychodzi z czasem. Będąc na początku swojej drogi młody adept sztuki programowania często może mieć problem z zakwalifikowaniem błędu z którym walczy do danej kategorii - a przez wybór złej kategorii stracić godziny, a w najgorszych przypadkach i dni.
Wstyd vs. Gra zespołowa
Ludzie są wstydliwi z natury. Nie lubimy się przyznawać, że czegoś nie wiemy, bowiem wydaje się nam, że jest to oznaka naszej słabości. Być może takie zachowanie wynika nawet z naszych uwarunkowań prehistorycznych, gdzie sąsiad wiedząc, że nie potrafimy się bronić naszą maczugą z pewnością by to wykorzystał kradnąc nam cały dobytek, a nas tłukąc na kwaśne jabłko.
O ile nie pracujesz dla korporacji z czasów Flinstonów, możesz spróbować założyć, że Twoi koledzy wcale nie chcą Twojej krzywdy. W dziesiejszych czasach projekty rozwijane są przez zespoły programistów i wierz lub nie, odpowiedzialność za to co się dzieje w projekcie też ponosi cały zespół.
W najlepszym interesie Twoim i Twoich współpracowników jest to, by dane zadanie zostało zrobione dobrze i szybko. Wbrew pozorom wcale nie chodzi o to, by każdy zrobił swoje zadanie jak najlepiej potrafi. Doświadczony programista często jest w stanie odstawić swoje zadanie na bok, by pomóc swojemu młodszemu koledze. To nie tylko miłe zachowanie z jego strony... to po prostu często optymalne postępowanie, które opłaca się w dłuższej perspektywie.
Jak zadawać w pytania w praktyce, by nie wyjść na głupka
Obawa każdej osoby przed pytaniem często może wynikać też z faktu, że na swojej drodze taka osoba mogła spotkać jakiegoś idiotę, który zamiast pomóc... to opieprzył bądź wyśmiał. Nie przejmuj się takimi osobami.
Gdy będziesz dołączał do nowego zespołu, zapytaj się, kto będzie odpowiedzialny za Twoje wdrożenie. Ta osoba nie powinna być Twoim szefem. W naszym zespola taką wyznaczoną osobę nazywamy "buddy/kumpel". Osoba ta podczas pierwszych tygodni Twojej pracy powinna być dla Ciebie dostępna w razie jakichś problemów, a w przypadku gdyby przypadkiem miała zaraz udać się na urlop, powinna wyznaczyć kogoś na swoje zastępstwo.
Dzięki takiemu kumplowi, Twoje wdrożenie przebiega sprawniej, bowiem ta osoba na bieżąco śledzi i pamięta problemy jakie być może napotkałeś przy wdrożeniu. Dzięki temu łatwiej jej podpowiadać kolejne rzeczy, bez pytania "co ty tam właściwie robisz".
Taki buddy może być Ci niezbędny również z tego powodu, że w przypadku napotkania jakichś nieoczekiwanych problemów stricte projektowych, Ty jako nowa osoba nie masz pojęcia kogo pytać. Co innego stały członek zespołu, który mniej więcej pamięta kto ostatnio z czym walczył. Jest ta osoba, od której powinieneś się dowiedzieć do kogo powinieneś iść pytać bezpośrednio w przypadku modułu X a do kogo napisać email w przypadku modułu Y.
Złote 15 minut
Rady radami, ale pomimo tych rad, ludzie dalej pytaja za późno. Spędzają pół dnia tylko po to, by potem się przekonać, że ich kolega zna rozwiązanie na problem z którym walczą i ten problem jest możliwy do zaaplikowania w kilka sekund. Ok... jestem w stanie zrozumieć, że nie chcesz pytać o wszystko, o każdą pierdołę, której akurat zapomniałeś... ale jeżeli tak masz, to koniecznie wyznacz sobie jakiś limit!
Kiedyś usłyszałem o tych złotych 15 minutach od kolegi, i ilekroć napotkam problem z powodu którego utknę na co najwyżej 15 minut, koniecznie proszę o pomoc, choćby nie wiadomo z jak głupim i banalnym błędem bym walczył.
Ludzie maja lepsze i gorsze dni, lepsze i gorsze momenty w danym dniu. To naturalne, że czasami człowiek ma chwilowe zaćmienie. Mając to na uwadzę, można postarać się oczywiście uwzględnić to, żeby nie pytać osoby, która np. dała do zrozumienia, że teraz jest badzo zajęta, bo "jest fuckup na produkcji" ;) Jednak jeżeli utknąłeś i potrzebujesz pomocy, nie bój się o nie dopominać aż do skutku, nie zmniejszając swoich starań, by jednak samemu sprawę posuwać cały czas do przodu.
PS. Pytanie co 15 minut może wydawać się częste... ale w praktyce wygląda to tak, że im ludzie czują się bardziej swobodnie w projekcie, tym ten czas się zmniejsza.. dochodząc często do kilkudziesięciu sekund.
Podsumowanie
Pytanie jest trudne... ale musisz zdać sobie sprawę, że bez tego pewnych rzeczy się sam nie nauczysz, bo w projekcie krąży wiedza, która czasami nigdzie nie jest spisana. Trzeba ją wyłuskać od innych (a potem najlepiej spisać na jakimś projektowym wiki!). Jeżeli następnym razem będzie Ci wstyd, że pomimo walki z zadaniem już od kilku godzin, dalej nie wiesz co zrobić, to wyobraź sobie jak dużo bardziej będzie Ci wstyd, gdy się okaże (co prawdopodobne), że po 24 godzinach, dalej tego nie wiesz co zrobić dalej.
Wstydem nie jest nie wiedzieć, tylko nie wiedzieć i bać się zapytać.
To konto - @noisy2 - jest moim drugim kontem, które zostało stworzone by oddzielić artykuły, w które wkładam najwięcej pracy (które zwykle są też pisane po angielsku, od tych pozostałych).
Zachęcam do subskrybcji obu kont, ale do subskrybcji konta @noisy szczególnie :)
Polecam zwłaszcze 2 moje artykuły:
Jak reguła 15 minut sprawdza się w przypadku, gdy nie ma kogo zapytać, a internety nie pomagają?
to znaczy, że albo się uczysz... albo zwiariowałeś i rozwijasz jakiś projekt samemu ;)
Jeżeli się uczysz, to należy rozważyć kwestie otwarcia źródeł swojej aplikacji. Gdy już cała Twoja praca jest publicznie dostępna, nie masz obaw.. i możesz zacząć uprawiać livecoding (link do artykułu o nim, jest pod koniec artykułu). Wówczas masz kilka-kilkanaście osób, które możesz pytać na bieżąco :)
Innymi słowy... Internety zawsze pomagają :)