#35 Tech Writer chce kodować więcej

Witamy w podcaście Tech Writer Koduje, w którym mówimy o technicznej stronie tworzenia dokumentacji w IT. Cześć Paweł, co tam u ciebie? O, cześć Michał, nie zauważyłem cię. A u mnie w porządku, wiesz co, zastanawiałem się, czy Tech Writer, który koduje, zawsze kodował, czy jakoś zaczął? Wiesz co, był kiedyś taki film, nie pamiętam tytułu, ale pamiętam, że był taki tekst, coś w ten deseń taki, ten, który nie gra, nie, ten, który grał, a nie gra, to zawsze będzie grał, dobra, nieważne, nie będę cytował, chodziło o to, że z tym kodowaniem, dobra, to jeszcze raz. Eee, o czym ty mówiłeś, że co? Czy Tech Writer, który koduje, zawsze kodował, czy kiedyś zaczął?

Wiesz co, Tech Writer, który koduje, myślę, że nie zawsze kodował i kiedyś po prostu stwierdził, że będzie to robił. No i tak wyszło. Czyli co, już mamy omówiony temat, możemy wracać do domu, tak? Tak, dzięki, że wpadłeś. Do pozdrawienia dla wszystkich słuchaczy. Nie, nie, nie, na tym skończymy? Nie, chyba nie. Nie, wiesz co, pewnie się w ogóle zastanawiasz, po pierwsze, po co ja cię tu zaprosiłem. Tak, zastanawiam się, po co mnie wezwałeś? Wezwałem cię w bardzo poważnej sprawie. Chciałbym, żebyś się pobawił dzisiaj w doradcę zawodowego. Co ty na to? O, dobra, disclaimer dla słuchaczy, nie jestem doradcą zawodowym, proszę nie traktować tego, co mówię, jako rady zawodowe. Okej, czyli technikalia mamy za sobą, prawnicy się już nie przyczepią, możemy przejść do meritum. Więc moje pytanie, czy też moja sugestia tego, żebyś stał się doradcą zawodowym bierze się z tego, że dostaliśmy mail od słuchacza całkiem niedawno i w tym mailu ten słuchacz nas poprosił o jakąś poradę dotyczącą rozwoju zawodowego.

Więc żeby zarysować kontekst wygląda to tak. Nasz słuchacz od dwóch lat pracuje jako technika writer. No i zna trochę, powiedzmy, języki programowania. Mówił, że zna Pythona, Visual Basic for Applications, no i że ogólnie zajmuje się narzędziami u siebie w firmie. Pythona głównie używa do obróbki XMLa i HTMLa, które są powiązane z Matcap Flerem. VBA używa głównie do jakiegoś tam procesowania w Wordzie. Zarządza właśnie aplikacją Matcap Fler, czyli pomaga użytkownikom, konfiguruje i robi różne takie rzeczy. No i pytanie jego brzmiało, jak mógłby się dalej rozwijać bardziej w obszarze programistycznym, czyli zdecydowanie chciałby podążać ścieżką bardziej techniczną i to jest jego tam cel na przyszłość, jeśli chodzi o karierę. No i co ty na to?

Wiesz co, ja przeszedłem podobną drogę bardzo, to znaczy jako Tech Writer zacząłem robić trochę bardziej takie rzeczy techniczne, pomagałem innym użytkownikom aplikacji i wydaje mi się, że ścieżka rozwoju w kierunku programistycznym właśnie idzie tędy, żeby brać na siebie więcej takich odpowiedzialności i szukać więcej okazji. W moim wypadku było to tak, że używaliśmy sobie Arbor Text Editora do No i mieliśmy szereg zadań, które były powtarzalne i monotonne. I myślałem sobie, czy to można jakoś przyspieszyć, uprościć. I odkryłem, że tam można pisać makra. Jest taki język Arbor Text Command Language, który wygląda jak PHP. I w nim można pisać takie jakieś skrypty. No i zacząłem pisać te skrypty i tak się uczyłem coraz więcej. I wtedy mi zaczęły przychodzić kolejne pomysły do głowy, co jeszcze można usprawnić.

że produkujemy ten webhelp, a w nim czegoś tam brakuje, no to można zmodyfikować te pluginy do Dita, OT i tak dalej. I to wszystko tak sobie, tak zaczęło się jak taka kula śnieżna się rozwijać. Więc ten nasz słuchacz, który supportuje Flare'a, na pewno może znaleźć podobne jakieś takie obszary, gdzie coś by mogło może działać lepiej albo inaczej. Może właśnie ten Flare'owy output można by rozwinąć i to już jest szybka droga do frontendu. Bo to jest to, co ja na przykład teraz robię, czyli jestem Tech Writerem, który utrzymuje frontend. I szereg moich zadań polega na tym, że piszę jakieś komponenty reaktowe na jakąś stronę albo wręcz robię DevOps nowych stron i je gdzieś tam odpalam, konfiguruję, buduję jakieś paczki npmowe i tak dalej. Więc myślę, że to jest fajna sprawa właśnie to, że jeżeli jesteśmy w firmie, gdzie mamy troszeczkę czasu na to, żeby wyjść poza ustalony schemat i ten czas możemy użyć, żeby się uczyć nowych rzeczy.

Fajnie, że wspominasz o tym frontendzie i o tym, co robisz na co dzień, bo w momencie, kiedy dostaliśmy tego maila, ja sobie wymyśliłem jakby trzy możliwości. Wszystko to, co do tej pory powiedziałeś, jak najbardziej się z tym zgadzam. No i mój pierwszy wniosek z twojej wypowiedzi jest taki, że pewne rzeczy sobie trzeba po prostu wywalczyć albo też trzeba jakoś tak dążyć w pewnym kierunku i naturalnie pewne rzeczy zaczną się dziać. Taki efekt kuli śnieżnej, jak to pisałeś, nie? Ale chciałbym, żebyśmy trochę bardziej skonkretyzowali naszą odpowiedź, żebyśmy podali jakieś tam konkretne scenariusze i drogi, którymi można iść, żeby na przykład osiągnąć ten cel, czyli być bardziej technicznym technika writerem. No i nawiązując do twojej wypowiedzi, ja widzę pierwszą rzecz, która mi przyszła do głowy, to jest szukanie sobie stanowiska roli, która nadal oznacza bycie technika writerem, ale w projekcie, który jest bardziej techniczny.

Czyli właśnie to co ty robisz, bo rola technika writera jest bardzo zróżnicowana i pomiędzy projektami czy firmami może się całkowicie różnić i w tym momencie jedna osoba, która powiedzmy opisuje jakiś tam interfejs użytkownika nie będzie musiała mieć dużej wiedzy technicznej i będzie to czysta praca tam dokumentacyjna, ale na przykład tak jak w twoim wypadku w tak bardzo technicznym projekcie twoja praca bardziej przypomina front-end dewelopera. Przynajmniej w pewnych momentach twojej pracy możesz się tak poczuć. Oczywiście też jakąś tam dokumentację tworzysz, ale jest to całkowicie inny rodzaj tworzenia dokumentacji, czy inny sposób tworzenia dokumentacji. Więc to jest jakiś tam pierwszy scenariusz, który chciałem przedstawić, czyli szukanie bardziej technicznej roli technika writera. Drugi scenariusz, który wiąże się bardziej z tym, jaką drogę ja przeszedłem, czyli

rozwój w kierunku osoby, która się stricte specjalizuje w narzędziach i infrastrukturze dokumentacyjnej. Na przykład ja teraz jestem doktul z deweloperem, czyli oficjalnie zostałem przemianowany na osobę, która zajmuje się tylko tym, już nie zajmuje się dokumentacją dla użytkownika, ale utrzymuje właśnie narzędzia i infrastrukturę dla naszych writerów. Więc to jest jakiś tam drugi pomysł na zmianę w kierunku bardziej technicznym. No i trzeci scenariusz, który ja wymyśliłem to jest przejście na stanowisko junior dewelopera. I mamy tutaj takie trzy scenariusze. No i chciałbym może zacząć od pierwszego. Już napomknąłeś na ten temat trochę, ale może trochę byś rozwinął. Po pierwsze, jak mniej więcej twoja droga wyglądała, jeśli chodzi o rolę technika writera na przestrzeni dziejów? A później, żebyś powiedział nam trochę o tym, jak rzeczywiście pracujesz na co dzień, czyli co ty tak naprawdę tam robisz, ile jest tego pisania, ile jest kodowania, w jakich technologiach pracujesz, żeby można było pokazać, że właśnie technika Writer jest techniczny i musi czasami mieć szeroką wiedzę na tematy właśnie związane z programowaniem.

No dobra, możemy o tym pogadać. Jeszcze bym dodał jeden temat tutaj na początek. Po co, dlaczego? Po co jest komu Tech Writer, który koduje? Bo taka funkcja może istnieć w określonych jakiś tam konkretnych warunkach. To znaczy wtedy, kiedy jest praca dla takiego kogoś. Mamy takie setupy, są takie zespoły, w których nie ma potrzeby, żeby Tech Writer kodował, bo po prostu są narzędzia, procesy, które nie wymagają tego. Wszystko jest utrzymywane na przykład przez inny zespół i Technical Writer po prostu koduje. Natomiast jeżeli jest to miejsce w zespole, no to wtedy ten Technical Writer może rozwijać swoje umiejętności. Lub jeżeli ktoś jest takim człowiekiem orkiestrą, takim freelancerem, chodzącym zespołem dokumentacyjnym, to wtedy ten człowiek jest odpowiedzialny za nie tylko pisanie i kodowanie, ale pewnie też i za strategię i pozyskiwanie klientów i tak dalej.

2 kropek albo równa się i jest coś tam napisane po drugiej. W każdym razie ktoś mi powiedział, weź sobie to napisz w Perlu. Stworzyłem plik z rozszerzeniem PL i tu się zaczęła moja przygoda. Co to znaczy napisz w Perlu, jak się takie skrypty odpala? Co to jest w ogóle na przykład zmiana tablicowa? Ktoś mi powiedział, no najprościej ci będzie wrzucić to do tablicy, I poiterować po tej tablicy, a ja, że co wrzucić, do czego i co zrobić, po czym. Na początku te słowa są niezrozumiałe, jak się zaczyna zupełnie od zera. Ten nasz słuchacz, który napisał, nie zaczyna od zera, bo ma doświadczenie w pisaniu tych różnych skryptów VBA. Co przypomina właściwie moje doświadczenie z pisaniem makro do arbor tekstach. No bo to jest właściwie pewnie to samo, nie? Pisanie makro do jakiegoś edytora. Natomiast w takiej sytuacji dla Tech Writera pomocne są dwie rzeczy.

Nie ma takiej dużej presji czasowej. No i przy tym przejściu na DIT to było naprawdę dla mnie doświadczenie Do głębnego zaglądania do narzędzi Tech Writerskich, czyli od podstaw jak działa Data Open Toolkit, jak te narzędzia się wszystkie tam ze sobą łączą, jak można takie rzeczy odpalać w konkretnym środowisku, którego używamy w firmie do deployowania dokumentacji. I tak dalej, i tak dalej. To były lata tak naprawdę badania tych narzędzi plus badania jakichś tam CMS-ów i tak dalej, ale stopniowo nauczyłem się robić takie rzeczy. A moja droga do front-endu to była taka już dosyć prostsza, bo trafiłem do projektu front-endowego tutaj, gdzie pracuję teraz. I jako jedno z pierwszych zadań dostałem, chcielibyśmy mieć stronę z dokumentacją, taką wewnętrzną stronę.

Jak to zrobić? A ja wtedy patrzę się na jakieś tam repo, które gdzieś leżało w firmie, tam jest napisane Galp, JS, czytam o co chodzi, no i tak też krok po kroku się wdrożyłem. Mówię o tym wszystkim, żeby trochę tak jakby powiedzieć, no nie taki diabeł straszny, nie? Jako Tech Writer może nie jestem super programistą z wiedzą teoretyczną na temat ciągów matematycznych i tak dalej, ale jak widzę kawałek kodu, no to go rozumiem i stopniowo mogę go sobie tam bardziej zrozumieć, zacząć pisać swój i tak dalej, i tak dalej. Też pomagają koledzy z zespołu, którzy robią review PR-ów, zawsze jakieś dobre rady dadzą. Słuchaj, to ja mam do ciebie takie pytanie teraz, jak już tak zarysowałeś nam historię swojego życia, jak w ogóle doszedłeś do tego, wiesz, języka, który nie zawsze jest uznawany za język programowania.

Mam takie właśnie pytanie związane z tym, jakie są oczekiwania wobec ciebie w tym projekcie? Sam powiedziałeś, że trafiłeś do projektu frontendowego jako technika writer. Czyli można by sobie wyobrazić, że twoją główną odpowiedzialnością jest pisanie dokumentacji, ale z tego co ja wiem, to nie do końca tak wygląda, więc chciałbym, żebyś nam opowiedział tak bardziej dokładnie jak twoja praca wygląda na co dzień i czego się od ciebie oczekuje, ile rzeczywiście czasu poświęcasz na pisanie dokumentacji, a ile poświęcasz na inne rzeczy, a na przykład wsad jest od deweloperów tylko jakoś tam

Czyli na przykład na każdej stronie jest flaga, która mówi, czy ten komponent jest lab preview, taki early access, czy to jest może stabilny komponent, czy jest deprecated i się go pozbywamy. Pisanie takich komponentów to są proste sprawy, no ale to jest fajne zadanie dla Technical Writera, żeby to wszystko działało i żeby to się wpisywało w ten nasz proces tworzenia dokumentacji też. Pisze sobie dokumentację w Markdownie, ale druga część tego Tech Writera, który koduje, to jest co pisać w tej dokumentacji. No i jestem na takim etapie w mojej wiedzy frontendowej, że wystarczy mi proste wymagania, na przykład zaimplementowaliśmy testy za pomocą Testing Library, trzeba by przepisać dokumentację, która jest, tak żeby ujęła to wszystko. Ja jestem w stanie patrząc na testy, które są w repo głównym, patrząc na naszą dokumentację i dokumentację Testing Library, jestem w stanie przepisać te przykłady, które mamy w dokumentacji,

Na właśnie przykłady związane z Testing Library. Albo dostaję informację o tym, że jest jakiś tam nowy feature w komponencie Data Table. Możemy teraz sortować kolumny według jakichś tam kryteriów. Patrzę sobie jak to jest zaimplementowane i jestem w stanie kilka przykładów napisać dla użytkowników, żeby sobie mogli też tego zacząć używać. No i to jest z grubsza to. Daje mi to szansę naprawdę dużo kodować, każdego dnia dużo kodu pisać. A potem jeżeli się pojawia nowy projekt, który by chciał mieć Dokuzaurusa i chcieliby mieć jakieś takie komponenty, to zawsze jestem proszony o pomoc jako taki trochę Tech Writer od Dokuzaurusa i jestem w stanie też pomóc. Czyli przy odrobinie szczęścia czy też chęci możemy znaleźć taki projekt wewnątrz swojej firmy albo poza swoją firmą, jeśli chcemy zmienić pracę, żeby się rozwijać bardzo technicznie.

Czyli niekoniecznie musimy od razu podążać ścieżką programistyczną czy też w ogóle zmieniać rolę, tylko możemy pozostać technika writerami i możemy też mieć dużo okazji, żeby się nauczyć technicznych rzeczy i dużo kodować, co pokazuje doskonale twój przykład. Ja myślę, że to jest fajna opcja dla osób, które chcą się rozwijać w tym kierunku. To jest przynajmniej jedna z możliwości. No ale, no ale właśnie Michał. No ale co? No ale. Ale ty Michał zmieniłeś rolę. Ty zmieniłeś rolę. Może nam opowiesz o tym. Zgadza się, czyli ja przyjąłem scenariusz drugi, o którym mówiłem, czyli zmieniłem rolę, ale wciąż pracuję w zespole dokumentacji, więc tak naprawdę nie opuściłem szeregów dokumentacji i nie poszedłem na przykład w stronę czystego developmentu, czy tam innego zespołu, czy tam w ogóle innego działu, tylko pozostałem z moimi koleżankami i kolegami writerami, tylko po prostu zmieniłem rolę wewnątrz zespołu.

Może nie będę tutaj jakoś się bardzo rozwodził na temat tego, jak po kolei wyglądała moja ścieżka do tego. Chciałbym tylko wspomnieć o paru rzeczach. Pierwsza z nich to taka, że miałem kilka podejść do tego tematu. Czyli już w poprzednich firmach czułem, że to jest to, co chcę robić i już zaczynałem sobie pisać jakieś tam skrypciki, zaczynałem sobie tam tworzyć jakieś mikro narzędzia. Zaczynałem ogólnie wchodzić w tematy mocno techniczne, które wykraczały poza jakby moje obowiązki jako takiego zwykłego technika writera, ale nigdy nie udało mi się do końca jakby doprowadzić tej ścieżki w taki sposób, że zostało to oficjalnie stwierdzone, że to jest moje zadanie i to jest 100% mojego czasu, mam na to poświęcać i to jest to, co przynosi wartość dla zespołu. Zawsze to było na zasadzie jakby dodatkowych zajęć, dodatkowych zainteresowań,

A takich problemów zazwyczaj jest trochę i potrzeb jest też dużo, im większy zespół, tym większe potrzeby i więcej problemów. Więc to jest taki pierwszy wniosek, czy tam pierwsza opowieść, którą chciałem wysnuć. A druga, jak do tego w ogóle doprowadziłem, że jestem tu, gdzie jestem? No, kosztowało mnie to dużo wysiłku i czasu, często też prywatnego czasu, żeby się nauczyć tego, co potrzebowałem. Zacząłem, jak już pewnie wspominałem w poprzednich odcinkach, zaczynałem od nauki Pythona, no i to jest do tej pory mój ulubiony język. Ale zajęło mi to kilka lat, żeby sprawnie się nimi zacząć posługiwać. No i tak sobie drążyłem tą ścieżkę i drążyłem, drążyłem. Kiedy miałem wolne przebiegi tak zwane, to pisałem jakiś skrypt w ramach projektu, w którym wtedy pracowałem jako technika writer. Tworzyłem jakieś małe narzędzia, które mi pomagały usprawdzić moją pracę. Pokazywałem deweloperom, że możemy zrobić to sprawniej.

Tyle jakby dodatkowego wysiłku w pracę, za którą już i tak ci płacą. Znaczy już i tak ci płacą za to, żeby pisać dokumentację. No odpowiedź jest taka, jeśli chcesz mieć inną pracę, no to ją sobie tworzysz. Czyli to jest coś, co ty zrobiłeś Michał, czyli pokazałeś wartość takiej pracy z narzędziami dokumentacji. Pokazałeś, że jeżeli odciągniemy jedną osobę od pisania i pozwolimy jej skupić się na tych innych zadaniach, no to ta wartość dodatkowa będzie płynąć dla firmy. Czyli to jest z obopolną korzyścią zrobione dla ciebie i dla firmy. Wydaje mi się, że to jest jakby zasadniczy Zasadniczy element planowania takiego ruchu przejścia na doktor z dewelopera, czyli zidentyfikować jakąś potrzebę, która może istnieć w firmie, albo zidentyfikować potencjalne korzyści, które jakby przeważą to, że zespół w pewnym sensie traci jednego Tech Writera.

Myślę, że to nie jest najciekawsze, ale myślę, że to jest pierwszy wniosek, który ci się może nasunąć w momencie, kiedy myślisz, hmm, ja jestem Tech Writer i chcę kodować więcej, no to co, zostanę programistą, nie? Wiem, Paweł, że ty miałeś takie zapędy. Znam też osoby, które do tego doprowadziły i przeszły na bycie programistą. Ja też sam miałem takie, może nie próby praktyczne, ale tak jakby padałem teren, więc może ty zaczniesz. Jak to u ciebie wyglądało? Czy ty miałeś takie w ogóle kiedyś chęci zostania programistą i na czym to się skończyło? Wiesz co, nieraz te myśli mi się pojawiały, pewnie jeszcze mi się pojawią nieraz, ale dużo zależy od kontekstu. Wydaje mi się, że będąc programistą w dużej firmie, gdzie jest dużo programistów, jest duża szansa, że będę miał mniej ciekawą i mniej kreatywną pracę niż kiedy jestem Tech Writer, który koduje albo specjalistą od narzędzi do dokumentacji, bo jednak jako programista w dużym zespole jestem w strukturze, gdzie jest dużo ludzi, którzy planują co jest do zrobienia, wymyślają jak to zrobić,

Tworzą tą architekturę tego oprogramowania i tak dalej, i tak dalej. I moje zadania mogą się stać przez to takie dosyć ograniczone. Monotonne? Powtarzalne? To zależy, bo to wszystko zależy od kontekstu. Też zależy od człowieka. Być może jako programista potrafiłbym lepiej zrozumieć ten kontekst, gdybym przez jakiś czas popracował i znalazłbym sposoby, żeby wnosić dużo wartości i robić jakieś ciekawe projekty. Ale jako technical writer, który koduje, Mogę w taki łatwy sposób zrobić dużo, bo mam wolną rękę w bardzo wielu aspektach. Czyli jeżeli, to jest przykład tego, co zrobiliśmy w obecnej firmie, że byliśmy w stanie zastąpić całą stronę z dokumentacją firmy naszą stroną i jeszcze napisaliśmy swój static site generator itd.

To jest coś, czego pewnie jako programista w dużym projekcie nie dostałbym wolnej ręki np. żeby przerobić cały projekt z Reacta na Pythona czy coś tam. O, fajnie zreaktowałeś. Może na Svelta bardziej. Mniejsza, większa, ale wiem o czym mówisz. To trochę mnie zatrzymało przy technika writingu, że jednak te zadania wydają mi się bardziej kreatywne. Poza tym widzę, że jest jeszcze bardzo dużo przestrzeni, którą można eksplorować, której ja nie zbadałem. Bardzo dużo rzeczy jeszcze się można nauczyć w technika writingu. Zgadzam się, tutaj jest dużym plusem to, że będąc kodującym technika writerem czy doktors deweloperem mamy dużo tej swobody, jeśli chodzi o wybór technologii i narzędzi, bo właściwie nie mamy nad sobą żadnego lida technicznego ani nikogo takiego, kto by nam powiedział musicie użyć tej technologii czy tego frameworku, czy tak to się robi.

Wiadomo, że są ograniczenia wewnątrz firmowe, wewnątrz których musimy się poruszać, I do nich się dostosowujemy, aczkolwiek i tak nawet w ramach tych wewnątrz firmowych ograniczeń mamy dużą swobodę, więc prostym przykładem jest właśnie strona, o której mówiłeś, gdzie my ją zrobiliśmy totalnie w innym frameworku niż wszyscy inni robią mikroserwisy dla klienta. I nikt z tego powodu nie ma tutaj problemu, nikt nam nie mówi, że nie możemy czy coś takiego, ale żeby nie było tak słodko i różowo, To wydaje mi się, że trzeba wspomnieć o jednym minusie związanego właśnie z bycie kodującym Tech Writerem, czy też doktor z deweloperem. Dużym minusem jest to, że właśnie brakuje tego zespołu i niestety proces uczenia się jest trudniejszy i proces review jest trudniejszy, bo nie uczysz się w taki naturalny sposób, że masz innych profesjonalnych, czy tam deweloperów, czy tam osoby kodujące wokół ciebie i one ci zwracają uwagę, ej, to trzeba się zrobić lepiej, może byś to tak zrobił i wiesz, jest taka burza mózgów, jest z kim skonfrontować te pomysły,

I często z ludźmi, którzy wiedzą więcej od ciebie. I to jest duża wartość bycia takim zwykłym deweloperem niż kodującym Tech Writerem. Mi czasami tego brakuje, żeby właśnie mieć kogoś, kto przyjdzie i mi pokaże, zrób to lepiej tak, albo zrobić to takie review solidne. No i to jest taki największy minus, bo jesteś taką trochę samotną wyspą, nie? Czyli jesteś wewnątrz dokumentacji i to ty wiesz najlepiej jak kodować, bo się tego nauczyłeś. No i nie ma tej drugiej osoby, czy tam tego zespołu, który stoi na to i mówi, ej słuchaj, no można to zrobić lepiej, musimy to ogarnąć lepiej i tak dalej, nie? Wiadomo, że są inne osoby, ale to nie jest to samo. To nie jest ten sam kaliber, według mnie. No i też są jeszcze inne rzeczy związane z przejściem na programistę. Po pierwsze, może to nie być przejście liniowe. Czy wiesz, co mam na myśli? Nie wiem, co masz na myśli?

Chodzi mi o to, że jesteś senior technika writerem i masz taki stopień zaszarygowania i w ramach tego, co robisz jako technika writer jesteś ekspertem, ale zostajesz kodującym technika writerem, który chce przejść na programistę, to na przykład może się okazać, że musisz zostać junior developerem albo zostać tak zwanym regularem, bo w ramach dokumentacyjnego zespołu twoje umiejętności kodowania są dość wysokie i są cenione, Ale porównując to do jakby poziomu zwykłych tam programistów w innych projektach, ty jesteś na poziomie junior albo regular. Więc może się okazać, że ktoś ci powie dobra, możesz zmienić stanowiska, ale będziesz zarabiał mniej, bo niestety no nie masz takiej umiejętności jako typowy programista. No i będziesz musiał zmienić stanowisko, jeśli chodzi o tytuł na przykład.