Ostatnio na blogu Xiona ukazał się post na temat udzielania odpowiedzi na pytania początkujących programistów. Pytania te często wydają się doświadczonym koderom irytujące ze względu na to, że odpowiedź jest dla nich oczywista. Ciśnie się na usta powiedzenie: Zapomniał wół jak cielakiem był…
Nie mam jednak zamiaru zastanawiać się czy lepsza jest odpowiedź krótka i rozwiązująca problem ale nie wyjaśniająca młodemu programiście dlaczego, ani czy lepsza bedzie długa wyczerpująca odpowiedź, której nikt nie przeczyta – bo kto ma na to czas? 
Ja zamierzam podzielić się własnymi spostrzezeniami na temat Dobrej Odpowiedzi. W życiu każdego z nas zdarza się odpowiadać na pytania kolegów odnośnie jakiegoś materiału przerabianego w szkole, na studiach czy nawet wyjasnienia o co chodzi w tej cholernej instrukcji obsługi… Jak wiemy niektórzy mają do tłumaczenia wrodzony talent, a inni tłumaczą tak, że nikt nic z tego nie rozumie. Dlaczego?
Podstawą do udzielenia dobrej odpowiedzi na pytanie jest zrozumienie tematu – jest to dość oczywiste. Czasem oczywiście ludzie, którzy nie wiedzą o co chodzi też starają się udzielić odpowiedzi (patrz dział o programowaniu na forum o2.pl). Jednak zrozumienie tematu przez tłumaczącego jest często niedostateczne - czy raczej dobre na chwilę. Później i tak będzie trzeba stawić czola podobnym pytaniom zadawanym przez tę samą osobę ponieważ nie zrozumie ona skąd wzięła się tamta odpowiedź więc i następnym razem nie będzie w stanie sobie sama odpowiedzieć.
Aby udzielić dobrej odpowiedzi trzeba samemu się wysilić i zrozumieć skąd wzięło się to potencjalnie głupie pytanie. Zadający je przecież na pewno nie chciał aby takie było. Pytanie jest kreowane przez wizję podanego tematu, zatem jeśli ktoś źle nauczy się jakiejś części drabiny wiedzy z danej dziedziny to później mogą się w jego głowie rodzić zagwostki, których nie bedzie w stanie rozwiązać. Z drugiej strony – jeśli spojrzyna to pytanie bardziej doświadczony gość to pomysli, że jest ono durne.
Z poprzedniego akapitu wynika więc, że bardzo możliwe, że wystarczy naprostować tylko sposób myślenia danej osobie tłumacząc jej inne zagadnienie, które zostało błędnie zrozumiane a przez które osoba ta ma błędną wizję tego o co pyta. Stąd trzeba najpierw zadać kilka pytań pomocniczych aby dowiedzieć, się z czego wynika zadane pytanie.
Warto jednak pamietać, że nie zawsze warto tłumaczyć. Przykłądowo, mamy świeże mięcho – młody programista, zaczyna robić jakiś projekt wieloplikowy z kilkoma różnymi klasami w C++. Niech w pliku nagłówkowym umieści definicję jakiejś klasy (używając oczywiście #pragma once lub #ifndef/#endif) zapominając jedynie o średniku po klamrze zamykającej klasę. Po załączeniu takiego nagłówka w jakimś pliku okazuje się, że kompilator wywala błąd w pliku cpp, do którego jest załączony wspomniany nagłówek, a nie powie, że to brak średnika po definicji.
Doświadczony programista od razu wie o co chodzi, a nowicjusz zacznie się zastanawiać co jest źle w linijce wskazanej przez kompilator. No i w końcu zada pytanie na forum. Odpowiadający może – tak jak napisałem – zdiagnozować problem i udzielić wyjaśnienia bądź odpowiedzieć po prostu, że brakuje średnika. W tym wypadku lepiej jest powiedzieć o braku średnika bo bardzo wątpliwym jest aby młody programista pojął sposób działania kompilatora. (bo to właśnie trzebaby mu wytlumaczyć chcąc aby miał kompletną wizję i rozumiał skąd ten błąd)
Jak widać nadal chodzi o sztukę wyboru mniejszego zła, a przy odpowiadaniu na pytanie problematyczne jest aby zrozumieć skąd ono się wzięło, a nie znalezienie faktycznego rozwiązania.
W gruncie rzeczy nie trzeba mieć nawet wiele wspólnego z kodem…