Blog, Hype i Fake News

Dzisiejszy post nie dotyka bezpośrednio aspektów technicznych, a stanowi bardziej zapis moich przemyśleń na temat odpowiedzialności za informacje w Internecie, zarówno za te, które tam umieszczamy jak i za te, które pozyskujemy. Wydaje się, że tematyka jest oczywista i nie ma sensu w ogóle o tym pisać, jednak z moich obserwacji wynika, że wcale nie jest to takie jasne. Od dawna zamierzałem poruszyć ten temat, ale ostatecznie dopiero dzisiaj się za to zabieram. Dlaczego teraz? Ostatnio poczułem mocniejszą potrzebę aby coś o tym napisać ze względu na coraz popularniejszą zabawę w różnego typu „Fake News”, które pojawiają się w szeroko pojętym Internecie, głównie w obszarach społecznych…

Schemat „Fake Newsów” praktycznie zawsze jest ten sam: 1. Puścić w obieg informację na temat osoby lub grupy osób, która będzie bulwersować wszystkich. Najlepiej opakować to w formie mema, który będzie szybko rozprowadzany po social mediach. Informacja oczywiście nieprawdziwa, ale to nie ważne. 2. Informacja dociera do dużej ilości osób bo „plotki” są zawsze ciekawe. 3. Osoby w które uderza informacja wykazują, że to fikcja, być może próbują wejść na drogę sądową. 4. Po ujawnieniu prawdy bądź nawet przegraniu sprawy sądowej przez autora „Fake newsa” pojawia się gdzieś małe sprostowanie i przeprosiny (ale to raczej rzadkość), które i tak trafiają do niewielkiej grupy ludzi…

Pewnie w ostatnim czasie sporo osób zauważyło już podobną sytuację. Aleee jaki to ma związek z naszą programistyczną branżą? No na pierwszy rzut oka niewiele, bo przecież firmy nie walczą ze sobą w taki sposób, a programiści między sobą nie puszczają plotek. Więc o cooo chodzi? Nie sposób i cel przekazywanych informacji jest tutaj punktem wspólnym, a odbiorcy, którzy łykają jak młode pelikany wszystko co zobaczą w Internecie.

„Wadą cytatów internetowych jest to, że każdy od razu wierzy w ich prawdziwość” ~Albert Einstein

W naszej branży pojawia się coraz więcej blogów, vlogów czy podcastów, a dodatkowo coraz więcej speakerów na konferencjach i spotkaniach technicznych. Jest to rewelacyjna sprawa, jednak wszystko ma drugą stronę medalu. Doświadczenie osób, które poruszają dane tematy bywa różne – mogą to być seniorzy z długoletnim stażem, ale moga to też być początkujący programiści. Każdy z nich niezależnie od tego jak długo jest już w branży na pewno produkuje wartościowe rzeczy, które mogą być pomocne dla innych, ale nie oznacza to, że powinniśmy traktować ich słowa jako świętość w każdej sprawie :smiley:

Na pewno jeśli poruszanym tematem jest rozwiązanie jakiegoś problemu czy tutorial, który pomaga wdrożyć się do biblioteki/technologii nie ma większych obaw o to, że przedstawione tam informacje mogą mieć negatywny wpływ na naszą codzienną pracę.

Więcej skutków ubocznych mogą nieść za sobą posty, w których autorzy stawią tezy, a następnie je argumentują i opisują swój punkt widzenia. Często są to bardzo dobre artykuły, z których można wiele wyciągnąć, ale zdarzają się też podejścia, które świetnie pasują do danej sytuacji, w której znajduje się autor i może to nie pasować do innych okoliczności. Sam autor może nie mieć o tym pojęcia, bo być może jego doświadczenie nie jest na tyle duże aby móc sobie wyobrazić jak takie spojrzenie na sprawę może wyglądać w innym kontekście, przez co w swoim artykule opisuje to jako świętość do której zachęca wszystkich. Być może po czasie zrozumie, że jednak jego rozwiązania nie są tak idealne jak opisywał wcześciej, ale od tego czasu artykuł już zdążyło przeczytać sporo osób, być może też wśród nich byli mniej doświadczeni programiści, którzy próbowali wdrażać ten pomysł, ale zakończyło się to fiaskiem i jedynie co zyskali to sporo problemów :smirk:

Kto ponosi odpowiedzialność?

  • Autor artykuły, który niekoniecznie ma rację :question:
  • Gość, który przeczytał ten artykuł i pod jego wpływem chce przeprowadzić rewolucję w swoim projekcie :question:

W moim przekonaniu nie można winić autorów postów nawet jeśli mogą one wprowadzać w błąd inne osoby bo w odróżnieniu od tworzonych „Fake Newsów”, które opisywałem na początku nikt nie chce nikogo oszukać. W naszej branży zakorzeniona jest zasada aby dzielić się wiedzą i zdobytymi doświadczeniami co jest bardzo dobre (dla obu ze stron). Dobrze również, że tą wiedzą nie dzielą się tylko ekstra doświadczeni wymiatacze, ale robią to też osoby z mniejszym stażem.

Mimo wszystko wspominałem o programistach mniej doświadczonych jako bardziej podatnych na uleganie informacjom znalezionych w internecie, a przecież nie są mniej inteligentni…

Głównie tyczy się to tego, że ktoś kto był w kilku/kilkunastu projektach pracował z dużą ilością RÓŻNYCH osób i przeżył już w swojej karierze sporo sytuacji jest w stanie dużo szybciej wyobrazić sobie jakie konsekwencje może za sobą nieść wykorzystanie danego rozwiązania.

Ale spokojnie, nawet początkujący juniorzy mogą sobie z tym poradzić, jest jeden prosty sposób aby unikać stosowania się do błędnych zasad, sprawdź jaki :point_down:

Zawsze dobrze przemyśl wszystkie za i przeciw przed podjęciem decyzji ważnych dla projektu :boom:

Jeśli przeczytasz jakiś ciekawy post, w którym autor tłumaczy dlaczego nie stosuje unit testów w swoim projekcie i ile pozwoliło jego zespołowi zaoszczędzić czasu podczas developmentu to nie oznacza, że powinieneś teraz usunąć katalogu tests ze swojego projektu i ogłosić zespołowi, że rozwiązałeś ich odwieczne problemy jedną prostą operacją :smiley:

Może to przejaskrawiony przykład, ale w rzeczywistości ile razy w projektach zastosowano niepotrzebne wzorce projektowe, bo ktoś zainspirowany dopiero co przeczytaną książką Gangu Czworga, zauważył potrzebę ich stosowania w każdym miejscu. Ile razy zastosowano nie tę technologię co trzeba tylko dlatego, że była w ostatnim czasie popularna i wszyscy się nią zachwycali, a na githubie zdobywała coraz więcej gwiazdek? Ile projektów nie potrzebnie było prowadzonych na siłę w zasadach Scrum tylko po to żeby być ADŻAJL? Takich przykładów może być sporo i zawsze przed każdym wyborem dotyczącym projektu, trzeba pamiętać, że aplikacja, nad którą właśnie pracujemy być może będzie rozwijana jeszcze przez długie lata, podczas których przejdzie setki zmian. Dobrze by było aby produkt, który będzie miał na siebie zarabiać był łatwo rozwijalny i modyfikowalny, a technologia i błędy z przeszłości nie powodowały samych problemów bo te z biegiem czasu są coraz większe, aż w końcu nie pozwalają na dalszy rozwój systemu.

Research

Jeśli Ty lub Twój zespół dojdziecie do momentu, że trzeba dodać nową bibliotekę, narzędzie, zmodyfikować sposób pracy lub musi się zmienić cokolwiek co jest związane z projektem, a na rynku dostępnych jest kilka opcji to zawsze zacznijcie od sporządzenia listy kryteriów według których będzie łatwiej dokonać wyboru, a następnie trzeba zbadać dostępne informacje na temat każdego z tych narzędzi, zapisać je i przedyskutować w zespole.

Rozwój projektu nigdy nie powinien iść w nowym kierunku bo jeden z członków przeczytał właśnie ekstra artykuł, który miał kilka lajków.

Decision log

Świetną metodą, którą zastosowaliśmy też w naszym projekcie jest prowadzenie dziennika decyzji, którego głównym zadaniem jest pomoc w zrozumieniu nowym członkom zespołu dlaczego używane jest takie, a nie inne rozwiązanie. Ale oprócz tego dostrzegam w tej metodzie dodatkowy atut – osoba na której spoczywa sporządzenie odpowiedniego dokumentu musi się wysilić aby racjonalnie udowodnić czemu od tego momentu zespół będzie postępował w taki, a nie inny sposób, przez co może zauważyć potencjalne problemy w początkowym wyborze i szybciej na nie zareagować.

Aby zorganizować taki decision log nie trzeba żadnych skomplikowanych narzędzi, jeśli w Twoim projekcie istnieje jakaś dokumentacja techniczna to jest to idealne miejsce aby znaleźć tam trochę przestrzeni aby móc przechowywać historię podjętych decyzji. Jeśli nie ma żadnej dokumentacji to można nawet stworzyć katalog w projekcie i przechowywać w nim pliki markdown. Najważniejsze aby każdy z „przerabianych tematów” zawierał kontekst i argumenty podjętej decyzji. Jeśli do wyboru było kilka różnych rozwiązań warto zestawić ze sobą najważniejsze elementy aby uwidocznić co przyczyniło się do danego wyboru.

Podsumowując…

Przed Tobą teraz stoi decyzja czy potraktować ten tekst poważnie czy już zacząć stosować filtr na to co się czyta w Interncie :smiley: Jeśli jednak mogę, chciałbym Ci dać tylko jedną radę: nigdy nie działaj pochopnie i dobrze przemyśl swoje decyzje, a reszta spraw będzie się układać :muscle:

Programista skupiony głównie wokół technologii webowych, ale nie przywiązujący się do konkretnych języków i narzędzi. Skoncentrowany na ciągłym rozwoju, zwolennik ruchu Software Crafmanship. Na codzień pracując w DAZN ma okazję rozwijać interesujący projekt do streamingu wydarzeń sportowych. Prywatnie fan sportu, a szczególnie piłki nożnej. Po godzinach próbuje również swoich sił w piwowarstwie domowym.
PODZIEL SIĘ