|
W jednym z tych maili wysyłałem artykuł o uczeniu się publicznie: https://www.swyx.io/learn-in-public/ Nagrałem też YouTuba, o tym, dlaczego warto dokumentować swoją drogę rozwoju: https://www.youtube.com/watch?v=dXii9-Hrz7I I od tamtego czasu cały czas próbuję wymyślić jak połączyć to podejście z moim blogiem. Tak bardzo mnie to męczyło, że ostatni miesiąc+, dałem sobie siana z tworzeniem treści (co, mam nadzieję, mi wybaczysz) i poświęciłem ten czas na wymyślenie jak Learning in Public połączyć ze skutecznyprogramista.pl. SP od początku miał być miejscem, w którym dostajesz sprawdzone taktyki, które udało mi wdrożyć i które możesz wykorzystać u siebie, żeby szybciej wskoczyć na wyższy poziom. Chcę minimalizować ilość opinii i wolę skupiać się na opisywaniu faktów - tego co zadziałało u mnie i działa u tych, których mam okazję obserwować. Wtedy proces działania jest prosty - ja piszę to co wiem, nie muszę koloryzować, jeśli brzmi to sensownie, to wdrażasz, sprawdzasz, działa/nie działa, lecisz dalej. Skupiamy się wtedy na efektach, a nie na wyrażaniu opinii i niekończących się dyskusjach na temat tych opinii, które prowadzą do nikąd. Tworzenie takich treści zajmuje sporo czasu, bo muszą być one przemyślane i poukładane. Muszę przeanalizować, co zadziałało u mnie i u innych, dotrzeć do sedna (albo wystarczająco blisko sedna) i opisać wszystko w taki sposób, żeby miało sens nie tylko dla mnie. Mimo to uwielbiam taki tryb działania. Z drugiej strony, kłóci się to z ideą "Learning/Working in Public" (które na nasz chyba najlepiej przetłumaczyć jako "Nauka/Praca na głos"), która stawia na tworzenie mniej idealnych treści. W moim domyślnym trybie pracy zastanawianie się i układanie wiedzy w głowie odbywało się przed opublikowaniem artykułu. W pracy na głos, dzieje się w to momencie tworzenia i publikacji. Wystawiasz coś na światło dzienne i dzięki temu weryfikujesz, czy to, co piszesz/mówisz, ma sens. Mam setki wpisów, które mogą Ci pomóc i których nie widzisz, bo czekają na publikację, bo muszą być dostosowane do "odpowiedniego" poziomu. Poziomu, który nie będzie opinią i luźnym przemyśleniem. Gdybym pracował na głos, to nie musiałyby czekać. Dodatkowo ja sam mam bardzo dużo rzeczy do ogarnięcia w kwestii tworzenia softu. Tak jak Ty, mam niekończącą się listę rzeczy, które chciałbym poznać i w których chciałbym się rozwijać. Nie chcę udawać, że jest inaczej i że wszystko mam ogarnięte. W niektórych rzeczach jestem dobry, a w innych jestem stuprocentowym amatorem. Brakuje mi miejsca, które byłoby publicznym notatnikiem, do którego każdy może dorzucić swoje trzy grosze i przyspieszyć mój proces uczenia. Te wszystkie przemyślenia i wiele innych spowodowały, że będę zmieniał trochę definicję tego "o czym jest ten blog". Trafiłem jakiś czas temu na wpis Joela Hooksa, twórcy egghead.io, na temat "cyfrowych ogrodów" i kilka rzeczy kliknęło w głowie. Dlatego spodziewaj się zmian na lepsze i jeśli masz jakieś przemyślenia, sugestie, czy nawet oczekiwania, to daj mi znać 🙏. -- Dzisiaj chciałem podzielić się jeszcze jednym przemyśleniem. COVID znowu nas dojechał (bo przecież już go nie było ;)) i nie zapowiada się, żeby praca zdalna miała zniknąć w najbliższym czasie. To powoduje, że firmy, stopniowo stawiają większy nacisk na komunikację pisaną, na dokumentowanie. Piszę "stopniowo", bo jest to proces i nie w każdej firmie jest to robione świadomie. O poziomach pracy zdalnej możesz poczytać tutaj: https://about.gitlab.com/company/culture/all-remote/stages/ Przez wiele lat pracowałem po części zdalnie i czasem trafiały się pojedyncze projekty w pełni zdalne, a przez ostatnie miesiące pracuję w trybie full-remote. Te doświadczenia nauczyły mnie, że dobrze udokumentowane informacje i procesy mocno wspomagają pracę. W biurze olbrzymia część informacji krąży w postaci mówionej i nigdzie nie jest zapisana, bo przecież można spytać w każdej chwili, wystarczy się odezwać. Pracując zdalnie, często nie ma tej możliwości, bo nie siedzimy na Slacku cały czas, a ci, którzy znają negatywny wpływ powiadomień na naszą pracę, mają je wyłączone (💪). Dlatego, informacje są zapisywane tak, żeby każdy miał do nich dostęp w dowolnej chwili i nie musiał zawracać gitary innym. Dzięki temu praca nie stoi w miejscu. Gdy już się zorientowałem, że dokumentowanie jest przydatne, to chciałem się go porządnie nauczyć. Kiedyś ciężko było zdobyć sensowne informacje i wiele z nich, to były opracowania książki "Microsoft Manual of Style". Teraz jest znacznie lepiej. Moje trzy ulubione źródła na chwilę obecną: Style guide od Gitlaba, którzy są mocno remote: https://docs.gitlab.com/ee/development/documentation/styleguide.html Style guide od Microsoftu: https://docs.microsoft.com/en-us/style-guide/welcome/ I guidy od Googla, w formie krótkich kursów: https://developers.google.com/tech-writing/overview Wydaje mi się, że znajduje się tam wszystko, czego potrzeba, żeby ogarnąć temat. Zawsze będę powtarzał (nie swoje) słowa, że "clear writing === clear thinking", więc niezależnie od tego, na którym poziomie jest Twoja firma, wydaje mi się, że warto uzbroić się w umiejętność dokumentowania. Przydaje się później przy prowadzeniu bloga, w pisaniu dokumentacji, no i w komunikacji wewnątrz firmy, gdy przychodzi pandemia. Od siebie dodam na start kilka wskazówek, które u mnie działają:
Największym błędem, który widzę, jest wkładanie zbyt dużego wysiłku do spisywania informacji i nadmierne używanie strony biernej. Umowy i akty notarialne są pisane takim "profesjonalnym" językiem. Staram się tego unikać i bardzo proszę innych, żeby to robili. Bo ten język jest naprawdę ciężko zrozumieć. Tworzenie softu jest wystarczająco skomplikowane, nie musimy go jeszcze bardziej komplikować. Możemy opisywać rzeczy takimi, jakie są. Gdy za bardzo się wysilamy i w dodatku piszemy po angielsku, który nie jest naszym pierwszym językiem, to wychodzą z tego jakieś niestworzone konstrukcje zdań, które fajnie brzmią, ale nic nie mówią. Najbardziej praktyczne teksty, jakie czytałem, są proste (ale nie prostackie) i skupiają się na konkretach. Zero bullshitu. Tak jak opisali to w guidzie od Microsoftu: https://docs.microsoft.com/en-us/style-guide/top-10-tips-style-voice. Mam nadzieję, że Ci się to przyda i będę miał kiedyś okazje czytać więcej dobrze napisanych dokumentów.
Tyle na dzisiaj, jeśli masz jakieś pytania, to odpisz na tego maila, albo pisz na socialach 🖖. Krzysztof skutecznyprogramista.pl / @kjendrzyca
Krzysztof Jendrzyca | Kozielska, 45/15, Gliwice
|