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

Druga sprawa, która jest w tej pierwszej części dla mnie interesująca, to jest prawo Hyruma, Hiram's Law, które mówi, że cokolwiek masz w systemie, to ktoś używa tego w swojej pracy. Jeżeli masz dosyć niedużo użytkowników, czyli na przykład jeżeli mamy przez rok jakiś tam bug, który sprawia, że coś tam się w systemie jakoś dzieje, to być może jacyś użytkownicy się nauczyli ten bug obchodzić albo nawet używać go tak, żeby im coś lepiej wychodziło. Po prostu stało się to częścią ich pracy. Konkluzja z tego powinna być trochę taka, żeby nie zmieniać drastycznie funkcjonalności tego, co robisz. Też trochę dalej w rozdziale o deprekacji mówią o tym, żeby deprekować rzeczy w oparciu o jakieś metryki, jeśli je mamy. Czyli deprekować tylko funkcjonalność, której faktycznie nikt nie używa. I wydaje mi się, że to jest ciekawa myśl, że nawet bugi mogą się wliczać w tą funkcjonalność, którą powinniśmy zachować.

I to się sprowadza chyba do tego cała ta zasada Hyruma. Nie wiem, czy książka odpowiada na pytanie, jak sobie z tym poradzić praktycznie, czyli jak robić tak, żeby tego prawa przestrzegać, bo nie pamiętam, żeby taka odpowiedź była dana. To jest chyba bardziej takie na zasadzie, dobra, pamiętaj o tym i staraj się nie robić jakichś tam ruchów. To jest dobre pytanie, bo pewnie nie ma jakiegoś jednego sposobu, żeby sobie z tym poradzić. Po prostu trzeba rozumieć, że takie coś się dzieje i jakoś reagować. Myślę, że w połączeniu z tymi metrykami, o których mówiłem, możemy coś tam spróbować zgadnąć, czy użytkownicy tego używają, czy nie, ale nie zawsze będziemy mierzyć takie rzeczy jak np. jakiś tam skrót klawiszowy, który nie działa i dzięki temu użytkownicy są w stanie zrobić XYZ. Ja myślę, że tutaj można by zbudować taką niewielką analogię do dokumentacji, nie?

No bo po prostu prawo Hyruma ludzie sobie używają tak, jak używają, nie? Okej. No dobra, no to mamy jasność, czym jest inżynieria oprogramowania. To co tam dalej się jeszcze kryje w kolejnych rozdziałach, co ci tam zapadło w pamięć? Podobał mi się rozdział o kulturze i on się zaczyna tak z grubej rury i mówi, że geniusz to mit. Nie powinniśmy sobie siedzieć ze swoim oprogramowaniem dwa tygodnie z jakimś tam kodem, wymyśleć najlepszy program na świecie i go wypuścić na świat, bo pewnie to tak nie zadziała, jak nam się wydaje. Pewnie popełnimy masę błędów, prowadzimy jakieś bugi i tak dalej. A oni tam sugerują w tej książce, żeby się dzielić od razu swoją pracą, prosić o feedback, pracować w małych inkrementach i pracować z zespołem. Tam piszą, że sukces pracy zależy głównie od umiejętności pracy zespołowej, a nie od jakichś tam indywidualnych umiejętności kodowania.

Więc ta książka akurat się nada idealnie do słuchania, bo tam nie trzeba jakoś specjalnie na próbki kodu patrzeć. To są bardziej takie zasady przemyślenia, doświadczenia i takie opisy, które można spokojnie konsumować w wersji audio, niekoniecznie trzeba na to patrzeć. Ciekawe, kiedy wyjdzie film. O, to by był dobry. A kto wygrał główną rolę? Nie ma głównej roli, bo to jest, wiesz... Ale główną rolę czego? Tego pelikana, co jest na okładce? Nie wiem, no bo... Czy Hyrum? Hyrum zagra Hyruma, a Beyoncé zagra Beyoncé. Może się uda i kierowcą autobusu będzie ten Adam Driver, bo Driver to kierowca, wiesz. Dobrze, Paweł. I myślę, że tym sucharem możemy zakończyć. Dziękujemy za uwagę i słyszymy się w następnym odcinku. Na razie. Na razie.