Jak mówić, żeby mnie słuchano i rozumiano?

Początkowo tytuł tego posta brzmiał: "JAVA: EdmException rzuca ładny wyjątek z wiadomością, a IllegalArgument rzuca wyjątek z nieładną wiadomością" - swoją drogą w następnym poście będzie można się z nim zapoznać ;)

Ale jak zacząłem pisać moją pierwszą myśl o tym tytule, to potem jakoś się rozciągnęło w cały wykład na temat prostego przekazywania informacji, więc postanowiłem już to tu zostawić i napisać o powyższym wyjątku w następnym poście. A oto co napisałem w związku z moimi myślami na temat tego tytułu:

Ha ha, nieco prosto piszę, ale lubię proste stwierdzenia. Po co mi nieproste stwierdzenia, jak mogą być proste?  Podoba mi się w programowaniu, że mogę być prawdziwie sobą i nie muszę udawać nikogo, żeby stwarzać pozory, że coś wiem. Jak czegoś nie wiem, to mówię o tym otwarcie i nikt się nie oburza. bo każdy programista zdaje sobie doskonale sprawę, że:

  1. Każdy kiedyś czegoś nie wiedział, dopóki się tego nie dowiedział,
  2. odległość dzieląca programistę z miejsca niewiedzy, do miejsca wiedzy o czymś w 90% wynosi tyle, co obecny dostęp do wyszukiwarki internetowej. Jeśli wyszukiwarka jest dostępna w danym momencie, to po 5-10 minutach, programista z "nie będącego w tym temacie" staje się "kojarzącym temat". Po kilku ćwiczeniach, już jest umiejącym to robić. 
     To tak przy okazji prostego języka, który często tutaj używam, bo jestem zdecydowanym zwolennikiem maksymalnego upraszczania słownictwa. Programistycznie powiedziałbym, że w tłumaczeniu czegoś, trzeba zejść do maksymalnie niskiego poziomu abstrakcji. Czyli tłumaczyć wszystko, jakby miało się przed sobą 5 letnie dziecko (osobiście trzymam przy komputerze w pracy kaczkę ;)). I jeśli ono jest w stanie zrozumieć o czym mówię, to znaczy, że dobrze tłumaczę. Mam kilkunastoletnie doświadczenie w nauczaniu - zapewniam, że można mi wierzyć, że wiem co mówię.

     Oczywiście na tym blogu nie zawsze używam określeń ogólnie zrozumiałych z tego względu, że mam świadomość, że mówię/piszę do programistów, więc trochę skracam to tłumaczenie - ale tylko do używania słów, których zakładam, że programista zna.

     Przy tej okazji, chciałbym tu wspomnieć o moim koledze, który niedawno napisał instrukcję, jak wgrywać wara dla całkowicie zielonych osób i użył do tego prostego nazewnictwa, tak, żeby każdy nawet przypadkowy przechodzień potrafił to zrobić. Efekt? Niektórzy programiści uznali, to za nieco infantylne podejście, z lekkim odrzuceniem określili, że "teraz to możemy brać Gimnazjalistów do wgrywania warów". Ogólnie z ich mowy zrozumiałem, że tłumaczenie jest nazbyt proste, jakby pozbawione jakiegoś rodzaju powagi, albo godności. Jakby ktoś czuł się urażony, że tak prostą instrukcję ma za zadanie wykonywać.

     Co ja o tym sądzę? Uważam, że w tłumaczeniu czegoś nie da zejść na zbyt niski poziom abstrakcji, który by powodował jakieś negatywne konsekwencje. Wg. mnie im niżej, tym dokładniej, a im dokładniej, tym mniej stresu, niepewności i lęku przed nieznanym dla osoby czytającej, czyli? - Mniej nieporozumień. Skuteczniejsza komunikacja, lepsze zrozumienie, oszczędność czasu - no i - pieniędzy, bo przecież ktoś płaci za to myślenie.

     No dobra, trochę było teraz teoretyzowania, to może dam przykład. Ostatnio otrzymałem opis pewnych pożądanych funkcjonalności do rozszerzenia obecnie hulającej apki. Instrukcja była tak napisana, że 4 strony czytałem 4 godziny. Aplikacja jest dość rozbudowana, więc nie do końca się orientowałem, co już jest, a czego już nie ma. Sformułowania były ogólne, np. "Przejść do następnego etapu" zamiast "kliknąć przycisk z napisem 'Przekaż' skutkujący przejście dalej". Jeśli by opisano ten przycisk, jego kolor, kształt i miejsce znajdowania się, to nie obraziłbym się, a przynajmniej wiedziałbym, o który dokładnie przycisk autorowi chodzi. 

    A tak, najpierw sam próbowałem dojść co autor instrukcji miał na myśli, poruszyłem kilku moich znajomych programistów (zająłem ich, czyli oderwałem od pracy, zmęczyłem pytaniami), kilka osób znających się organizacyjnie na aplikacji i w efekcie tego stworzyłem zestaw pytań (początkowo i tak było 37 - ale część odpowiedzi rozeszły się w toku konsultowania z moimi znajomymi), w których prosiłem o doprecyzowanie kilku rzeczy. Teraz te pytania jeszcze leżą u osoby (kontaktującej się z autorem instrukcji), bo ta osoba musi sama je przejrzeć, żeby też wiedzieć o co pyta. Ale moje pytania są tak szczegółowo i jednoznacznie skonstruowane, że ciężko się do nich zabrać i przerobić. Tak przypuszczam, bo wiem, co ja czułem jak musiałem się rozeznać w tej sytuacji.

    I teraz, zanim ta osoba to sama przerobi, minie trochę czasu, potem zanim autor instrukcji się z nimi zapozna, skonsultuje i odpisze, to - zakładając, że już będzie w odpowiedzi zawarte wszystko czego potrzebuję - minie kilka dni, a może i tygodni. A wystarczyło, precyzyjnie - jak dla gimnazjalisty, albo osoby z podstawówki - napisać co ma być zrobione, i sprawa byłaby od razu załatwiona. 

    No, ale cóż, niektórzy chyba potrzebują czuć, że mówią jak poważni ludzie. Ja nie potrzebuję i jest mi z tym komfortowo, choć czasem spotykam się z tym, że ktoś mnie od razu oceni, przez pryzmat tego w jaki sposób mówię. To powoduje kłopoty nowych kontaktach, bo okazuje się, że robię normalnie zwyczajnie jak każdy, ale tak dziwnie prosto mówię, więc coś im we mnie nie pasuje. Usłyszałem kiedyś, że jestem przedszkolakiem, ha ha.

     Pół biedy, jak ktoś ma otwarty umysł i mimo, że kogoś w jakiś sposób oceni, to potem potrafi zmienić zdanie jak dojdzie więcej informacji. Cała bieda, jeśli ktoś po tak pochopnych wnioskach, naklei mi etykietę i nie chce już jej zdjąć, wtedy zazwyczaj dłużej trwa - czasem się nie chce skończyć - z takimi osobami proces zaprzyjaźniania się i porozumienia, ale cóż nie mam wpływu na innych ludzi. Ja wierzę, że mój sposób extremalnie prostego mówienia jest skuteczny i zamierzam się go trzymać. 

    To tyle na dziś, miłego dnia ;)

Komentarze

Popularne posty z tego bloga

IntelliJ: zmiana rozmiaru czcionki scrollem

ThunderBird: jak zrobić professional stopkę