Tytuł niniejszego wpisu zapożyczyłem z piosenki zespołu „Raz, Dwa, Trzy”. Uważam, że doskonale oddaje sens rozważań, którymi chciałbym się w tym wpisie zająć.

Dość dawno temu usłyszałem ciekawą radę, aby nie nazywać spraw problemami, ponieważ słowo to niesie negatywny wydźwięk i podświadomie sprawia, że normalna sprawa rzeczywiście urasta do rangi problemu. Dlatego sprawy, które są zadaniami do zrealizowania nie powinny być problemami do rozwiązania, zadania matematyczne – nie powinny być problemami matematycznymi. Jeżeli coś blokuje nam drogę, to nie jest problem tylko przeszkoda, jeśli nie zdążyliśmy na autobus, tramwaj, to nie jest to problem, ale nieoczekiwane spóźnienie. Dzięki temu (nazywając rzeczy po imieniu) nasz mózg nie ściera się z czymś nieznanym, nie zderza się z enigmatycznym problemem – dostrzega konkretne zadanie, które musi zrealizować: przeszkodę można ominąć albo usunąć, opóźnienie można zniwelować korzystając z innego środka transportu lub uwzględnić spóźnienie w harmonogramie, dostosowując go.

Dlaczego piszę o tym na blogu – jakby nie było – programistycznym? Ano dlatego, że programiści też dokładają sobie takich … problemów ;). I to w pełnym spektrum możliwości, jakie ta dziedzina daje. Pierwszy z brzegu przykład: kierownik/lider przychodzi do programisty i pyta „nad czym walczysz”. No tak, programowanie to nie jebajka to jebitwa ;). Słysząc takie pytanie dzień w dzień, człowiek siłą rzeczy zaczyna traktować swoją pracę w kategoriach walki, zadania stają się jego przeciwnikami, kod to istne pole minowe, a sam kierownik zdążający do stanowiska, aby zadać swoje standardowe pytanie, jawi się niczym bombowiec, który właśnie rozpoczął nalot. Dlatego należy się okopać, nie wychylać i najlepiej szukać wspólnego frontu przeciwko wszystkiemu i wszystkim.

Na marginesie – odmianą owego kierownika są przedstawiciele innych działów (np. handlowego), którzy lubią zagajać rozmowę w stylu „co znowu zepsułeś?”. Wywołuje to łopot serca, bo przecież całkiem możliwe, że coś zepsułeś, ale jeszcze o tym nie wiesz – a ON może to już wiedzieć, możliwe, że właśnie wraca od klienta, któremu sprzedał oprogramowanie, a tenże mu nawrzucał jaki to badziew był zmuszony zakupić. A to po prostu taka „humorystyczna zajawka”.

Nie szukajmy jednak tak daleko, a zajrzyjmy na własne podwórko. Sami sobie dokładamy do pieca. Jak? A chociażby nazywając użytkowników „użyszkodnikami”. W ten sposób deprecjonujemy ich, co w konsekwencji podważa zasadność naszej pracy, jaki jest bowiem sens pisania programowania, skoro jego odbiorcy są kretynami? To w krótkiej perspektywie prowadzi do jakże olśniewających wniosków, że „gdyby nie ci użytkownicy, to programy pisałoby się wyśmienicie” ;).

Innym „kwiatkiem” z naszego podwórka jest nazywanie błędów „bugami” (czy ktoś w ogóle lubi robale?). Nie lepiej jednak błędami? Albo usterkami? To nie wzbudza obrzydzenia a jednocześnie wskazuje drogę działania: błąd/usterkę należy po prostu usunąć. Robala nie ma ochoty się tykać, najlepiej rozgnieść. W tej materii młodsi wiekiem programiści, zaczynają (jak ostatnio zauważyłem) używać określenia „fuck up” i to w wersji spolonizowanej „wywaliło jakiś fakap” (to ci konstrukcja). Znowu słowo przeładowane emocjami. Adrenalina od razu wtłacza się w żyły, serce przyspiesza, a zazwyczaj to standardowy błąd (i nic się spektakularnie nie sp…ło), taki jakich wiele było, jest i będzie. Trzeba je tylko poprawić.

Czy radosna słowotwórczość płynie tylko po negatywnych falach? Nie, płynie także po falach absurdu. Spotkaliście się kiedyś z określeniem, że oprogramowanie ewoluuje? Naprawdę nie chciałbym być częścią zespołu, który zajmuje się ewolucją oprogramowania. Niezależnie od tego, które ze znaczeń tego słowa przyjąć. Bo w jednym przypadku oznacza to (nomen omen) przypadkowość rozwoju tegoż oprogramowania, a w innym jakieś tegoż oprogramowania akrobatyczne zachowania. Nie – ja zdecydowanie wolę pracować w zespole, który zajmuje się rozwojem oprogramowania. Wówczas mam większą pewność, że jest jakiś plan, wg którego ten rozwój będzie następował.

Zatem – zwracajmy uwagę przynajmniej na to, jak we własnym środowisku nazywamy rzeczy, pamiętając, że wielokrotnie powtarzane kłamstwo staje się koniec końców prawdą.