#56 Tech Writer robi inżynierię oprogramowania, czyli dobre praktyki prosto od Google

Witamy w podcaście Tech Writer Koduje, w którym mówimy o technicznej stronie tworzenia dokumentacji w IT. W dzisiejszym odcinku moim gościem jest Paweł Kowaluk. Paweł Kowaluk Dobry wieczór Państwu, dobry wieczór Panie Redaktorze. Paweł jest ekspertem od inżynierii oprogramowania, w szczególności od inżynierii oprogramowania w firmie Google, ponieważ przeczytał jedną książkę i chciał się z nami podzielić swoimi wnioskami, uwagami i obserwacjami po lekturze właśnie tejże książki. Chciałem, panie redaktorze, sprostować jedną rzecz, bo ja przeczytałem jedną książkę Google'a i przeczytałem tak naprawdę dwie książki, bo jeszcze przeczytałem naszą szkapę. Okej. Ja przeczytałem jeszcze o psie, który jeździł koleją i Janko Muzykanta. Nieźle. Ale tam nic nie było o inżynierii oprogramowania, z tego co pamiętam.

No i teraz porozmawiajmy sobie może konkretnie o tym, co z tej książki wyciągnąłeś jako kodujący Tech Writer, czy w ogóle jako osoba, która zajmuje się na co dzień programowaniem w większości. Pierwsza myśl, którą w ogóle kolega mnie zachęcił, żebym to przeczytał, to była myśl o tym, czym się różni programowanie od inżynierii oprogramowania. To był taki haczyk, który mnie, powiedzmy, zaintrygował trochę i byłem ciekaw, co tam się jeszcze można dowiedzieć w tej książce. Programowanie to jest po prostu tworzenie kodu, który działa, a inżynieria oprogramowania to jest myślenie długofalowo o tym. I tam w tej książce było tak ciekawie to porównane ze sobą. Użyte było słowo clever jako taka, że to jest fajne, jeżeli robimy programowanie i twój kod jest clever, czyli na przykład jesteś w stanie w jednej linijce napisać jakąś tam całą złożoną funkcję, jesteś taki clever, to fajnie, jeśli robisz taki jednorazowy programing do wyrzucenia.

Wydaje mi się, że jeszcze jeden blind spot na equity, który możemy mieć to jest rola, bo oczywiście płeć to jest ważny temat i my we dwóch jesteśmy tutaj sobie z jednej perspektywy patrzymy na świat. Natomiast jeszcze jest jedna sprawa. Programista vs nieprogramista. Albo Technical Writer vs nie Technical Writer. Jako Technical Writer to często mi się wydawało, że to jest wszystko super zrozumiałe, nie? To jest rozpisane w buletach i tak dalej. A może kogoś drażnią bulety? A może moja skomplikowana architektura informacji to nie jest coś, czego ludzie chcą się uczyć? A może nie jest dla ludzi naturalne używanie landing page'a z jakimiś kartami z milionem linków albo używanie jakichś filtrów wyszukiwania, w których ja jestem specjalistą?

Genius Myth. No i wracamy do tego, że trzeba książkę przeczytać. Dobra, to co, podsumowujemy? Są wakacje, zostały jeszcze miesiące. Słońce, palmy, szum morza. Drinki, palemki i tak dalej. Świetna okazja, żeby wziąć książkę i przeczytać, tudzież przesłuchać, jak kto woli. Więc ja ogólnie polecam, jeśli ktoś nie chce spędzać wielu godzin na całej książce, no bo ona jest dość duża chyba, nie? Z tego, co kojarzę, tam jest chyba 600 stron, a audiobook to jest chyba 20 godzin ponad nagrania. Więc można też wybiórczo poczytać i się nic nie stanie. Jeśli nie chcecie w całości, to popatrzcie sobie na spis treści, wybierzcie sobie interesujące zagadnienia, ale na pewno warto i wydaje mi się, że osoby nawet, które się nie zajmują kodowaniem na co dzień, chociażby technika writerzy, którzy nie kodują, a piszą dokumentację, też powinni to przeczytać, bo jednak funkcjonują w tym ekosystemie programistycznym i wiele z tych zasad jest takich uniwersalnych, więc wydaje mi się, że po pierwsze można zbudować analogię, a po drugie lepiej zrozumieć ten świat programistów.