Cześć, dziś kontynuacja tematu z poprzednich wpisów, które można przeczytać tutaj:
Nowa praca i towarzyszące jej emocje. Wstęp
Pierwsza praca i towarzyszące jej emocje. Część 1. (De)Motywacja
Kilka rzeczy jest dość uniwersalnych, więc zachęcam Cię też do przeczytania poprzednich wpisów, gdyż tutaj będę starać się nie powtarzać. Tak jak we wcześniejszych wpisach z tego cyklu, tak i w tym, zawartość dla bardziej doświadczonych programistów pewnie będzie oczywista.
Teraz chcę opisać kolejny stan/emocje:
A więc o jakich dwóch stanach piszę? Mniej więcej, wyglądają one tak (w negatywnej wersji, szczęśliwie, w większości przypadków nie jest tak źle z nami 😉 )
– „Umiem za mało i boję się zadawać pytania, bo to zobaczą i mnie wyrzucą.”
Już na początku chcę Ci wyjaśnić – nie bój się zadawać pytań. To normalne, że nie wiesz i nie rozumiesz pewnych rzeczy. Rozważymy teraz kilka scenariuszy, ich kolejność nie jest przypadkowa. W każdym kolejnym obowiązują te same uzasadnienia co w poprzednim. A więc zaczynamy!
Scenariusz 1
Jesteś bardzo dobry w tym co robisz, masz doświadczenie (jeśli tak jest, to już to rozumiesz to co napiszę) przychodzisz do nowego projektu/pracy. To normalne, że nie znasz domeny, w której będziesz pracować i/lub jej szczegółów. Możesz nawet znać domenę ogólnie, na przykład ubezpieczenia, ale nie znasz konkretnego klienta i jego potrzeb. To też normalne, że pewnie nie znasz struktury projektu. (Oczywiście im masz większe doświadczenie tym szybciej i łatwiej „załapiesz” te rzeczy – być może robiłeś/robiłaś dokładnie coś takiego wcześniej). Zadawanie pytań o domenę i strukturę projektu jak i wcześniejsze wprowadzenie w projekt to są normalne rzeczy. O ile strukturę załapiesz szybko, to o rzeczy związane z domeną jeśli jest skomplikowana, możesz pytać długo. Nikt nie oczekuje takiej wiedzy od Ciebie.
Scenariusz 2
Masz mało doświadczenia w danej technologii (bo to np. Twoja pierwsza praca, albo zmieniasz technologie) i pytasz o to co wyżej… masz tym bardziej do tego prawo. Wiesz i umiesz mniej, do tego normalne mogą być pytania o inne rzeczy, związane z technologią, jak coś w niej działa, a także jakiś corner case. Może używasz nowego narzędzia, np TeamCity, Reasharpera czy nowego IDE, którego nie używałeś wcześniej, czy to w poprzedniej pracy czy nigdy, bo to Twoja pierwsza. To normalne, że od razu, o ile nie masz doświadczenia z podobnymi tematami, będziesz miał więcej pytań niż odpowiedzi. I powinieneś wtedy też, moim zdaniem, uczyć się tego gdzie masz braki w domu, np z książek, kursów, ale czego byś nie robił – pytać też będziesz musiał. Nie mówię o pytaniach o wszystko, bo wielu rzeczy dowiesz się w minutę w google, ale szkoda Twojego i Twojego pracodawcy czasu na szukanie w google przez 4 godziny tego, co kolega Ci powie w minutę, albo nawet kwadrans. Wiadomo, że w drugą stronę to tez przegięcie… Ale zapewne pracodawca zatrudniając Cię wiedział że tak będzie. To poniekąd jest wpisane w zatrudnianie nas na takim etapie kariery. Nikt Cię za to nie zwolni :-). Lepiej coś zrobić dobrze, pytając się o to, niż marnować czas na poprawki później (np po code review, choć to tez forma nauki i sprawdzenia kodu, która jest ważna i potrzebna przez całą karierę).
Scenariusz 3
To Twoja pierwsza praca, może nawet staż albo praktyki i naprawdę wiesz nie wiele. Twój pracodawca liczy się z tym i zapewne tak to zorganizował, żebyś się czegoś mógł nauczyć. Czy to mogąc pytać cały czas „kogokolwiek”, czy mając wyznaczonego opiekuna, czy może robiąc jakiś projekt, tylko żeby się douczyć. To już może wyglądać różnie, zwłaszcza jeśli to staż a nie praca. Możesz mieć określone godziny z opiekunem na konsultacje, żeby nie przeszkadzać mu gdy pracuje – wtedy szukasz sam, nawet parę godzin, a potem się pytasz, a możesz go mieć „zawsze” pod ręką – nie koniecznie na wyłączność dla siebie ;-). Tak czy siak, dostosowując się do tego jak to jest zorganizowane, powinieneś pytać. To normalne i każdy się tego po Tobie spodziewa. Gdy się nie pytasz… marnujesz swój i pracodawcy czas. Na prawdę lepiej nauczyć się od innych i na ich błędach niż na swoich. Lepiej zapytać kogoś jak coś zrobić dobrze, niż zepsuć. Powtórzę ponownie – pracodawca wiedział na co się pisze. (Jeśli nie, to raczej jego wina niż Twoja i jeśli zatrudnił studenta zamiast specjalisty z 10 letnim doświadczeniem, którego potrzebuje… to i tak powinieneś uciekać, a nawet jeśli nie… to i tak będziesz lepszym pracownikiem pytając, niż robiąc coś źle).
Codzienne życie i praca
Wszyscy czasem potrzebujemy pomocy. Dlatego pracujemy zespołowo, dzięki temu uzupełniamy się nawzajem. Jeśli zadajesz pytania, pokazujesz że jesteś profesjonalistą, który nie boi się przyznać, że czegoś nie wie. Boją się tego tylko ludzie słabi i niepewni. Nie ma nic złego w byciu niepewnym na początku kariery, ale nie możesz pozwolić żeby Cię to powstrzymało. Dzięki temu nauczysz się jak i kiedy zadawać pytania. Jak coś komuś prosto wyjaśnić. To też bardzo ważna umiejętność.
Pytanie „Czemu mi ten kod nie działa?” nic nie powie. Jaki kod? Gdzie? W jakich warunkach? Może lepiej „Czy możesz przyjść i zobaczyć czemu mi nie działa X, próbowałem A B C, jak debuguje to H i G, ale i tak nie rozumiem”?
„Jak zrobić X?” Ale po co? Czemu chcesz to zrobić, co chcesz osiągnąć? Jaki jest kontekst? Może lepiej „Mam zadanie polegające na A, zrobiłem już X i Y, ale nie wiem jak zrobić Z”. Najwyżej ktoś Ci przerwie, jak zna kontekst, nauczysz się w praktyce – przyjdzie z doświadczeniem, też pracy z daną osobą, ile komu powinieneś powiedzieć, żeby by w stanie Ci pomóc. Ja sam uważam, że powinienem nad tym dalej pracować i mogę to robić lepiej. Czy to zadając pytania czy wyjaśniając coś komuś. Dlatego, jeśli ten wpis jest nie jasny – napisz mi o tym, nie obiecuję że poprawię go od razu, ale następny będzie lepszy.
Metoda żółtej kaczuszki
Czasem zadanie dobrego pytania już pomaga. To tzw. „metoda żółtej kaczuszki” tylko z człowiekiem :). Polega na tym, że wyłącznie myśląc o problemie nasz mózg pracuje inaczej, niż gdy próbujemy coś komuś wyjaśnić. Wtedy musimy ubrać to w słowa. Aktywują się inne obszary mózgu. Czasem słysząc a czasem zadając pytanie wpadamy na właściwy trop żeby uzyskać rozwiązanie. Czasem tego co nam brakuje, to odpowiedniego sformułowania pytania. W naszych myślach to nie wyjdzie. Na tym polega metoda żółtej kaczuszki, że gdy brak człowieka z którym moglibyśmy porozmawiać, staramy się wyjaśnić problem, albo nasz kod, linijka po linijce, gumowej albo plastikowej żółtej kaczuszce. Żeby zmusić nas do sformułowania naszych myśli w zupełnie nowy sposób – dzięki czemu uzyskujemy inne, nowe spojrzenie na problem lub kod.
Ale jednak czasem…
Niestety, życie nie zawsze jest tak idealne. Są jeszcze dwie nieciekawe scenariusze o jakich nie napisałem wcześniej:
Przypadek nieco beznadziejny – Ty na prawdę nie umiesz nic. Pytasz o wszystko. „Co to jest obiekt? Co to znaczy pisać obiektowo?” To znaczy, że albo pracodawca wiedział co robi przyjmując Cię na staż (bo nie wierzę że do pracy 🙂 ), i wtedy wszystko co wyżej obowiązuje, bo za pewne przygotował dla Ciebie możliwość nauki i nie przeszkadzania innym jednocześnie, albo lepiej dla Ciebie i dla niego, żeby Cię nie zatrudnił po stażu teraz i zatrudnił za N miesięcy gdy się czegoś nauczysz.
…bywa tragicznie
I przypadek gorszy. Czasem można przeczytać o takich przypadkach na forum czy na blogu. Piszę o tym, ku przestrodze.
Jak wygląda? Masz prawo się pytać, z tego czy innego powodu, a „kolega” w zespole odpowiada w stylu:
„- To Ty tego nie wiesz? To kiepski programista z Ciebie.”
I nie słyszysz tego raz na parę miesięcy jako żart, tylko za każdym razem. Czasem, podobne teksty dostaniesz od przełożonego, nawet jak nie pytasz o nic, to kwestia „sposobu zarządzania”, jakiegoś „Janusza biznesu”. W obu wypadkach ich cel będzie jeden – obniżyć Twoje poczucie wartości. Czemu? W pierwszym wypadku, dlatego, że ten „kolega” to nie pewny siebie dupek, który chce podbudować swoje ego Twoim kosztem. Normalni (a szczególnie pewni siebie, czy mający dobre umiejętności) ludzie tak nie robią. W drugim przypadku ma Cię to zatrzymać w firmie żebyś mimo tego że zasługujesz na więcej nie odszedł i nie rozwijał się, nie zarabiał więcej. To smutne, ale niektóre firmy się do tego zniżają.
Taka sytuacja jest toksyczna, tak jak Ci ludzie. Zmień pracę. Poważnie. To nie z Tobą jest problem tylko z nimi.
Na koniec dalej optymistycznie
Podsumowując i wyrywając się z tego negatywnego dołka na koniec – warto rozmawiać… i zadawać pytania. Nie ma się czego bać. 🙂 W ten czy inny sposób tylko na tym zyskasz!
Nic dodać, nic ująć – brawo dla autora.
Słuszne uwagi, zgadzam się z nimi całkowicie. Od siebie dorzucę kilka swoich przemyśleń, które częściowo pokryją się z tym co Arek napisał.
Z własnego doświadczenia powiem, że ludzie boją się pytać. Strach ten zazwyczaj spowodowany jest tym, by (jak wspomniał Arek) nie obniżyć własnej wartości w oczach kolegów z zespołu.
„No bo jak to… przecież odbiorą to tak, że nic nie umiem i mnie zwolnią/nie dadzą podwyżki, a przecież mam rodzinę/psa/samochód/kredyt na utrzymaniu i chciałbym godnie żyć.”
Taka obawa jest jak najbardziej uzasadniona, lecz nie powinna być dla nas blockerem. Należy pamiętać, że każde zadane pytanie ma swoją cenę. „Głupie” pytania są niezwykle kosztowne dla naszego wizerunku. Nie oszukujmy się, nawet najbardziej tolerancyjny zespół na świecie ma swój limit zaufania do danej osoby, którego przekroczenie boleśnie zaboli.
Oczywiście nie można popaść w paranoje. Ten „dług” wyrobiony zadawaniem pytań można szybko spłacać. Oczywiste jest, że osobom z większym doświadczeniem przyjdzie to łatwiej, gdyż mogą wykazać się swoimi umiejętnościami. To też wyjaśnia dlaczego osoby z większą wiedzą czują się pewniej – nawet kilka zadanych pytań nie wpłynie widocznie na nasz „budżet” gdyż szybko zrekompensujemy go swoją dobrą praca.
No ale co z osobami nie- lub mniej doświadczonymi, bo to o nich głównie mówi Twój tekst. Jak tu zadawać pytania, gdy nie jesteśmy wstanie ich spłacić gorszą wiedzą. Wbrew pozorom opcji jest multum, a niestety wielu programistów z dłuższym stażem o nich zapomina… (jednak jest to wątek na zupełnie inną dyskusję).
Pamiętajmy, że zadając mądre pytania możemy pokazać się z tej lepszej strony – druga osoba na pewno to doceni.
Ponadto słuchajmy odpowiedzi i róbmy z nich użytek. Nie powtarzajmy tych samych błędów i nie pytajmy w kółko o to samo. Bądźmy dzięki temu lepsi, pokażmy że nam zależy.
Na koniec wspomnę o tym, co niestety widziałem już nie raz – czyli wyeksploatowaniu materiału, czyli osoby pytanej. Jesteśmy tylko ludźmi, zwykłymi pracownikami o skończonych możliwościach i limitowanym czasie. Każdy z nas ma swoje obowiązki, które jest zobligowany zrealizować. Z tego też powodu szanujmy czas innych i zachowajmy balans między pytaniem, a własnoręcznym zgłębianiem się w temat. Zbyt często zadawane pytania lub co gorsza nieprzemyślane pytania mogą zacząć poważnie irytować i wyrobić bardzo widoczne skazy na opinii o naszej osobie, których zamazanie wymagałoby nie lada błysku z naszej strony.
„Śpieszmy się zadawać pytania, bo doświadczeni programiści tak szybko odchodzą… (do innej firmy)” – ja w tej chwili
Hej, dzięki za długi i fajny komentarz. Ciekawe i dobre rozwinięcie wpisu! Dzięki 🙂
But a smiling visitor here to share the love , btw outstanding layout. dacfbeddeddefgae
Swietny wpis! Jako uzupełnienie polecam też przeczytać http://www.javadeveloper.pl/zadawanie-pytan-junior-developer