Jak zadać programiście pytanie bez odpowiedzi „Dlaczego”

Wszyscy mieliśmy to doświadczenie. Idziesz do kogoś, kogo znasz, ma odpowiedź na pytanie, zadajesz tej osobie pytanie, a ona odpowiada typową odpowiedzią: „dlaczego?”. Wyjaśniasz, dlaczego musisz wiedzieć, a oni próbują rozwiązać Twój problem.

Potrzeba czasu, skręcenia rąk i cierpliwości, aby skierować rozmowę z powrotem na pierwotne pytanie i po prostu uzyskać tę cholerną odpowiedź.

Dlaczego programiści ciągle to robią i dlaczego zachowanie pogarsza się, im starszy jest programista?

Jak zadać programiście pytanie w sposób najbardziej efektywny w wydobyciu odpowiedzi na pierwotne pytanie?

Dlaczego programiści pytają „dlaczego”, gdy ktoś pyta, jak wdrożyć rozwiązanie?

Ponieważ wymaga to większej wiedzy do oceny, czy rozwiązanie jest odpowiednie, niż do faktycznego wdrożenia rozwiązania.

Bardzo trudno jest uwierzyć komuś, kto mówi: „Nie wiem, jak to zrobić, ale wiem na pewno, że to właśnie muszę zrobić”. Programiści stale nalegają na głębsze sondowanie, ponieważ ludzie stale nalegają na zadawanie niewłaściwych pytań. Tak, czasem w końcu wraca do twojego pierwotnego pytania, ale nie zawsze.

Jako analogię, wyobraź sobie, że ktoś podszedł do mechanika i zapytał go, jak wymienić akumulator samochodowy. Zwykle jeśli masz kwalifikacje do diagnozowania wadliwego akumulatora, możesz go wymienić, więc mechanik zapyta, skąd wiesz, że należy go wymienić.

Wie, że jeśli tego nie zrobi, i okazuje się, że nie potrzebujesz akumulatora, będziesz wracał, zadając coraz więcej pytań, aż w końcu zorientujesz się, że musisz zgasić światła, gdy silnik nie działa. Pytając cię z góry, wydaje się, że marnuje twój czas, ale tak naprawdę z doświadczenia wie, że potencjalnie oszczędza wam więcej czasu.

Tak więc, jeśli chcesz uniknąć pytania, musisz przekonać go z góry, że wiesz, o czym mówisz.

„Pytanie dotyczy w szczególności tego, w jaki sposób jeden współpracuje z innym programistą, aby zadać pytanie, na które drugi ma odpowiedź i pominąć debatę na temat tego, dlaczego pytanie jest zadawane”.

Nie możesz, przynajmniej nie deterministycznie. Drugi programista to osoba, a nie komputer, a nie twój sługa. Jeśli zadasz im pytanie, będą mogli wybrać najlepszą odpowiedź. Jeśli myślą, że potrzebują więcej kontekstu, mogą o to poprosić.

Możesz spróbować poprzedzić swoje pytanie stwierdzeniem, że szukasz tylko krótkiej, dolnej linii odpowiedzi, ale nadal mogą odpowiedzieć według własnego uznania.

Pytanie dotyczy w szczególności tego, w jaki sposób jeden współpracuje z innym programistą, aby zadać pytanie, gdzie drugi ma odpowiedź i pominąć debatę na temat tego, dlaczego pytanie jest zadawane.

Nie możesz Programiści, szczególnie ci dobrzy, są przygotowani do rozwiązywania problemów i są wydajni . Gdy klient lub inny programista przychodzi w poszukiwaniu odpowiedzi - zanim przedstawi rozwiązanie, upewni się, że zna problem, który rozwiązuje. W ten sposób są wydajni (nie marnują czasu i czasu, udzielając odpowiedzi, która nie rozwiąże twojego problemu) i rozwiązują prawdziwe problemy (podając rozwiązania / odpowiedzi na pytania, które powinieneś zadać).

Przykład - kiedy klient przychodzi do Ciebie i mówi, że chce zaimplementować funkcję X. Czasami klient naprawdę potrzebuje funkcji X, a czasem naprawdę musisz się zalogować i przesłuchać klienta, aby dowiedzieć się, że nie chce X, ale coś zupełnie innego. Im starsi i doświadczeni są programiści, tym bardziej prawdopodobne jest, że zostali spaleni w przeszłości, nie docierając do sedna problemu przed przedstawieniem rozwiązania.

Podsumowując - jeśli chcesz dokładnie odpowiedzieć na swoje pytania, musisz mieć pewność, że:

• zadawanie właściwych pytań (dlatego musisz wcześniej zbadać problem)
• zapewniając kontekst dla problemu
• dzieląc się swoimi badaniami, aby szybciej skierować ich na problem

Większość ludzi, których znam, to tylko ludzie, a nie komputery. Jeśli chcesz uzyskać odpowiedzi, spróbuj googlować.

Dlaczego programiści ciągle to robią i dlaczego zachowanie pogarsza się, im starszy jest programista?

Niestety jest tak daleka od ogólnej prawdy, jak to tylko możliwe.

Takie zachowanie ogranicza się do mniejszości naprawdę dobrych. I lepiej też się tego naucz.

Samo odpowiedzenie na to cholerne pytanie przeskakujące nad tym, co jest dobrym sposobem, jest szybkie i pewne wjechanie w otchłań.

Jeśli naprawdę chcesz pominąć część wykształconą, możesz poprzedzić swoje pytanie kilkoma zdaniami o ograniczeniach i chęcią pominięcia pytań - możesz otrzymać odpowiedź lub po prostu odesłać. Przedstawienie podsumowania własnych badań jest lepszym pomysłem.

Każda odpowiedź tutaj jest dobrą odpowiedzią na pytanie „dlaczego”, ale nikt tak naprawdę nie odpowiedział na pytanie PO.

Jak zadać programiście pytanie w sposób najbardziej efektywny w wydobyciu odpowiedzi na pierwotne pytanie?

Odpowiedź jest zaskakująco prosta: powiedz im, dlaczego należy to zrobić, zanim zapytasz, jak to zrobić.

Najlepszą rzeczą jest włączenie programistów w spotkania na wyższym poziomie wokół produktu - daj im szerszy obraz, aby mogli zobaczyć, dlaczego ta konkretna rzecz musi być zrobiona. Mogą cię nawet zaskoczyć wymyśleniem tego, jak pierwszy.

Dobrzy programiści nie chcą po prostu wdrożyć żadnego rozwiązania; chcą wdrożyć najlepsze rozwiązanie dla konkretnego problemu. Wymaga to informacji. Pytania są sposobem na zbieranie informacji. Bez wszystkich informacji programista wie, że jest zagrożony wdrożeniem rozwiązania, które nie będzie spełniało wszystkich wymagań i utknie, robiąc to ponownie. Nie ukrywaj informacji przed programistami. Ukrywanie informacji marnuje czas, niszczy morale i prowadzi do gorszych rozwiązań.

Programiści są „podłączeni” do rozwiązywania problemów.

Dobrzy programiści będą próbowali rozwiązać „właściwe” problemy.

Dostarczenie tego, o co ktoś prosi, jest [często] złym problemem do rozwiązania.

W czasach, gdy automatyzacja MS Office była w modzie, pojawiał się szereg pytań, zwykle w ciągu kilku tygodni, z pytaniem, jak zrobić „to” w jednym produkcie Office, a następnie „tamto” w innym produkcie , a następnie coś jeszcze w innym. Każde z nich jest szybko rozwiązywane, ale „problem” - jeszcze nie w pełni określony - nie został rozwiązany. Wracają po kolejne „ogniwo” w swoim łańcuchu.

Jeśli ich zatrzymasz i zapytasz: „Dlaczego?” następnie muszą cofnąć się i wyjaśnić szerzej, co chcą osiągnąć, a nie tylko opisać problem bezpośrednio przed nimi. (BTW, programiści cierpią z tego powodu tak samo jak (jeśli nie bardziej niż ktokolwiek inny), na których fora takie jak te noszą testament).
Łańcuch użytkownika „Pobieranie danych z dużej bazy danych do programu Access, a następnie do programu Excel, aby je trochę wymasować, a następnie w programie Word, aby mogli scalać wyniki pocztą e-mail i wysyłać je co tydzień do ludzi”, jest szybko zastępowany przez zadanie wsadowe, które wykonuje to wszystko , z wynikami umieszczonymi w skrzynkach odbiorczych ludzi w poniedziałek rano, bez ręcznego zaangażowania użytkownika w ogóle.

Użytkownicy lubią to.

Musimy wiedzieć, gdzie chcesz się dostać, zanim zaoferujemy ci najlepszy sposób na dotarcie.

Alternatywnie (parafrazując Monty Python): „Czy chcesz 5-minutowej odpowiedzi czy pełnych pół godziny”?

Nie ma sensu, aby Programista grzechotał wszystkie najdrobniejsze szczegóły danej funkcji, gdy chcesz tylko wiedzieć, czy da sobie radę, jeśli podasz jej liczbę z trzema trzema miejscami po przecinku.

Znajomość swojej perspektywy często może radykalnie zmienić kształt otrzymanej odpowiedzi.

Ostatnie pytanie brzmi: „Jak zadać programiście pytanie w sposób najbardziej efektywny w wydobywaniu odpowiedzi na pierwotne pytanie?”

Najpierw mylicie „efektywny” i „skuteczny”. Aby być najbardziej wydajnym , po prostu napisz „Jaka jest odpowiedź?” na kartce papieru i pokaż to programiście. To bardzo skuteczny sposób zadawania pytań. Uzyskiwanie odpowiedzi jest również bardzo nieskuteczne.

Po drugie, zakładasz, że twórcy oprogramowania odpowiadają na pytania. Oni nie są. Są rozwiązywaniem problemów. Twoje podejście wyraźnie pokazuje, że nie rozumiesz rozwiązywania problemów. Najbardziej skutecznym sposobem rozwiązania problemu jest zrozumienie problemu do tego stopnia, że ​​można go opisać rozwiązującemu problem, a następnie przedstawić go rozwiązującemu. Inną metodą jest częściowe zrozumienie problemu w miarę możliwości, a następnie przedstawienie niepełnego zrozumienia rozwiązującemu problem, który najpierw zadaje pytania, których się boisz, aby przekształcić je w w pełni zrozumiały problem, a następnie go rozwiązać.

Bardzo nieefektywnym sposobem jest metoda, którą próbujesz: uzyskać niepełne zrozumienie problemu, zgadnąć, w jaki sposób ten problem można rozwiązać, i zapytać problem, w jaki sposób można osiągnąć to rozwiązanie. Rozwiązujący problemy widział już takie zachowanie. 10 razy, jeśli nie ma doświadczenia, tysiąc razy, jeśli ma doświadczenie. Rozwiązujący problemy wie , że zmierzasz w zupełnie złym kierunku. I rozwiązujący problemy robi to, co musi zrobić, aby podążać we właściwym kierunku, czyli zadawać pytania, aby zrozumieć rzeczywisty problem. Pierwsze pytania, aby zrozumieć niepełne zrozumienie problemu, i drugie pytania, aby zrozumieć prawdziwy problem.

Rozpocznij pytanie od wyjaśnienia, co chcesz osiągnąć i w jakim kontekście pracujesz. Jeśli podasz wystarczającą ilość kontekstu , nie otrzymasz odpowiedzi „dlaczego?”. , otrzymasz „czy to naprawdę konieczne?”

Bo statystycznie , większość proponowanych cechy ssać i nie są warte wysiłku, aby wdrożyć.

Typowym obaleniem byłoby „ale to jego praca”. Jego zadaniem jest pisanie dobrego kodu , a dodawanie funkcji zwykle jest sprzeczne z tym, ponieważ większość funkcji wymaga przeprojektowania działającej bazy kodu i tej „przeprojektowania”:

1. trwa wiecznie
2. dodaje nowe błędy
3. psuje rzeczy, które kiedyś działały
4. czyni konserwację nieprzepuszczalną

To nie jest dobry kod, dobry kod jest minimalny.