Przejdź do głównej zawartości

Tech Writer Koduje - odcinek 35 i 36

· 3 min aby przeczytać

Tech Writer chce kodować więcej i Tech Writer się boi, czyli Halloween Special 2021 to tytuły ostatnich odcinków podcastu Tech Writer Koduje. Poniżej zapraszamy na ich skrót.

Odcinek #35

Czy tech writer, który trochę koduje może kodować więcej? Jakie ma opcje rozwoju zawodowego jeśli interesują go głównie skrypty, narzędzia i inne techniczne aspekty tworzenia dokumentacji? Bazując na własnych doświadczeniach, Michał z Pawłem, rozważają trzy możliwe scenariusze rozwoju dla techno skryby z zapędami programistycznymi.

Według rozmówców najbardziej popularna droga to poszukiwanie możliwości rozwoju technicznego wśród projektów w swojej firmie i wykorzystanie czasu, w którym mamy mniej pracy na naukę nowych rzeczy. Paweł podaje mnóstwo przykładów technicznych, gdyż tak właśnie wyglądała jego droga rozwoju zawodowego.

Po co komu kodujący technical writer?

Funkcja ta występuje rzadko, jednak zdarzają się sytuacje, że pojawia się praca dla kogoś o takich umiejętnościach. I są to najbardziej optymalne warunki, by technical writer dalej rozwinął się w kodowaniu. Osoba taka, dzięki szerszemu spojrzeniu na problem, będzie potrafiła lepiej go zrozumieć i wykona część zadań samodzielnie - napisze dokumentację, ale też stworzy część wymaganego dla procesu kodu, zamiast zlecania tego deweloperowi. Może też znacznie usprawnić pracę zespołów zajmujących się dokumentacją dzieląc się swoimi narzędziami. Ma też większą swobodę w wyborze technologii i narzędzi potrzebnych do pracy, przez co środowisko pracy jest dla niego bardziej elastyczne i przyjazne.

Scenariusze rozwoju rozwoju dla techno skryby z zapędami programistycznymi wg Michała i Pawła:

  1. Szukanie stanowiska, na którym nadal jest się technical writerem, ale w bardziej technicznym projekcie.
  2. Rozwój w kierunku roli osoby, która specjalizuje się w narzędziach i infrastrukturze dokumentacyjnej.
  3. Przejście na stanowisko junior developera.

Co pomoże w nauce kodowania?

  • Ludzie - doświadczenie kolegów z branży i chęć dzielenia się wiedzą oraz pomocą, kiedy coś idzie nie tak.
  • Internet - liczne artykuły z tutorialami, filmiki na YouTube, szkolenia online. Dzięki temu można się powoli wdrażać w temat i poszerzać wiedzę.
  • Motywacja wewnętrzna, chęć do nauki technicznych rzeczy, gotowość na wysiłek, jaki trzeba włożyć w zdobywanie nowych umiejętności.
  • Komunikowanie przełożonym, że chce się nieco zmienić ścieżkę zawodową.

Jeśli interesuje Was jak wygląda dzień z pracy kodującego technical writera oraz z jakimi problemami może się spotkać, posłuchajcie tego odcinka. Poznacie też odrębne historie rozwoju kariery. Być może któraś z nich będzie tą, do której chcielibyście dążyć?

Odcinek #36

Co prawda Halloween już dawno za nami, jednak temat, który wybrali prowadzący podcast jest ciągle aktualny.

Wszyscy się czegoś boją. Zdarza się, że nawiedzają nas koszmary i zjawy z przeszłości. Tech Writerzy nie są pod tym względem wyjątkiem. Mają swoje, nierzadko osobliwe, lęki. W odcinku 36 Michał i Paweł rozmawiają o tym czego boi się techno skryba i co nie daje mu spać po nocach.

Odcinek ten powstał dzięki słuchaczom podcastu. Chłopaki poprosili w mediach społecznościowych o historie z życia wzięte, w których technical writerzy dzielą się swoimi lękami i obawami oraz niekoniecznie dobrymi doświadczeniami z pracy.

W cytowanych historiach pojawiają się tematy:

  • nierealne wymagania wobec pracownika będącego na okresie próbnym,
  • pisanie dokumentacji w programie Word,
  • problemy z mergem w SVN czy Gicie,
  • narzędzia, które sprawiają więcej problemów niż są pomocą,
  • kłopot z utrzymaniem screenshotów,
  • micromanagement,
  • management, który przekonuje, że nie opłaca się inwestować w dokumentację.

Każda z historii zostaje w ciekawy sposób omówiona, a rozmówcy wyciągają przeróżne wnioski. Zauważają też, że niektórzy nie mają żadnych koszmarów i zastanawiają się, z czego może to wynikać.

A czego boją się sami rozmówcy? Tego dowiecie się słuchając tego odcinka 😉. Warto, by zrozumieć, z czym czasem muszą borykać się technical writerzy.