Jak sie czuje w pracy

Jak się czuję w pracy?

Zdarzały się w mojej karierze sytuacje, w których patrząc na działania jakie podjąłem zastanawiałem się, jakim cudem mi się udało. Jaka super moc była mi potrzebna, żeby rozwiązać problem, którego inni rozwiązać nie mogli? W momentach tych nie chodziło tylko o uznanie innych, ale o zadziwianie samego siebie. I chociaż czułem wtedy, że stoję na szczycie świata, a wszyscy biją mi pokłony, to w ciągu dziesięciu lat mógłbym policzyć takie chwile na palcach jednej ręki.

Jak zatem wygląda przeciętny dzień mojej pracy? Przeważnie myślę, że jest zupełnie odwrotnie. Brak mi wiedzy i doświadczenia, mam fatalną organizację pracy oraz mój kod jest nieczytelny i pełen błędów. A zamiast programować, myślę o tym jak robią to inni, lepsi ode mnie programiści. Na koniec dnia stwierdzam jednak, że chyba nie jest tak źle, skoro nadal trzymają mnie w pracy i dobrze mi za nią płacą.

Awaria!

To w sytuacjach kryzysowych czuje się najlepiej i błyszczę. Oddech klienta za plecami niektórych paraliżuje, dla mnie sprawia, że czuje się skoncentrowany i zmotywowany, a przede wszystkim potrzebny. Nie ma nikogo z kim mógłbym się porównywać, nikt nie ocenia jakości mojej pracy. Oczekiwany rezultat jest zero-jedynkowy. Maszyna ma działać. I zazwyczaj działa. W tych kwestiach jestem naprawdę zawzięty. Powiedz mi, że ktoś już próbował rozwiązać problem, ale mu się nie udało, a masz gwarancje, że będę rył ja dzik, aż maszyna zacznie pracować, tak jak wcześniej, albo lepiej. Może to się wydawać nieco dziwne, ale czasem udaje mi się nawiązać z maszyna więź, która nie pozwala mi na pozostawienie jej w potrzebie. Jest to dla mnie coś na zasadzie relacji pielęgniarka-pacjent. Po prostu nie mogę patrzeć jak to mechaniczne coś cierpi. Bo jako cierpienie właśnie interpretuję brak działania dla maszyny. Sam też lubię działać i może to nas łączy.

Nowy początek

Kiedy zaczynam nowy projekt jestem podekscytowany. Układam sobie plan działania i wyobrażam jak piękny będzie efekt końcowy. Pierwsze kroki są bardzo proste i przypominają usuwanie awarii. Trzeba jedynie skomunikować ze sobą urządzenia i sprawić by części zaczęły się ruszać. Gdy już każdym napędem mogę poruszyć w trybie ręcznym, przychodzi czas na napisanie sekwencji. Tworze więc automat stanów i przepisuję go na kod. Ładuję program do maszyny i naciskam start. Działa! Albo i nie. Ale nawet jeśli nie działa, to szybko lokalizuję przyczynę i usuwam, aż zadziała. Znowu się ekscytuję tym jaki jestem genialny, ale tylko przez chwilę.

Schody

Przecież jeśli ten napęd będzie się poruszał w zaprogramowany przeze mnie sposób a operator zaingeruje nie tak jak powinien to system się zawiesi. No tak, nie przewidziałem tego na wstępie. Wiem, jak to naprawić, ale to zmieni całą sekwencję programu. Siadam więc z powrotem do grafu i poprawiam. Przepisuję kod, ładuję do maszyny i znowu zauważam, że coś pominąłem wcześniej. I tak kolejny raz, i kolejny, aż zaczynam wątpić czy kiedykolwiek uda mi się wyeliminować wszystkie błędy. Wtedy zaczynam się zastanawiać, czy ja się w ogóle nadaję do tej pracy? Czy powinienem poprosić kogoś o pomoc? A co, jeśli dowiedzą się, że nie wiem, jak zaprogramować tą maszynę idealnie? W końcu się przełamuję i pytam kolegi obok jak on by to zrobił. Nie dostaję konkretnej odpowiedzi, bo on prawdopodobnie walczy z podobnymi problemami. Może on też nie umie programować? A może udzielił mi odpowiedzi, a ja jej nie zrozumiałem? Nie wiem, czy powinienem przez to czuć się lepiej czy gorzej. Wstyd narasta, ale brnę dalej.

Zamykanie projektu

W końcu po kilkukrotnym przepisaniu kodu dochodzę do wniosku, że nie ma co dalej walczyć. Że zrobiłem co mogłem, wyciągnę wnioski na przyszłość i następnym razem zrobię wszystko lepiej. To mi wystarcza. Na chwilę. Jestem już atakowany przez poczucie winy, że przecież ta maszyna jedzie do klienta, który będzie zmuszony męczyć się z niedociągnięciami, które w niej pozostawiłem. Może jeszcze raz spróbuję przepisać sekwencję, a jak coś pójdzie nie tak i będę się musiał tłumaczyć kierownikowi projektu, że znowu zacząłem od nowa? Co, jeśli nowy program nie przyniesie oczekiwanego rezultatu? Dobrze byłoby też zmienić grafikę na panelu HMI, przecież obecna wygląda jak strony internetowe z poprzedniego wieku. Ale przecież to nie ma sensu, można by tak poprawiać bez końca i nigdy nie być zadowolonym. Czas więc powiedzieć sobie dość i ruszyć naprzód, do zamknięcia dokumentacji, której robić szczerze nienawidzę, i której nikt i tak nie przeczyta.

Ciche dni

Projekty w małych firmach zwykle wiążą się z długimi dniami pracy, po których przychodzą dni ciszy. To te dni, kiedy czekamy, aż pojawi się coś nowego i nie mam ochoty zajmować się bzdurami, jak przygotowywanie się do czegoś, co może nie nadejść. Zwykle zaczynam w tym czasie kursy, których nigdy nie ukończę. Była już Java, C++, a teraz przyszła kolej na Pythona. Bo przecież w IT jest lepiej. Tam wszystko jest zorganizowane i zestandaryzowane i zawsze można liczyć na pomoc kolegów z pracy, kiedy jest się w kropce. Czyżby?

Na standardowe pytanie koleżanki w kantynie “Masz dużo pracy?” odpowiadam “O, Tak!” by po dwóch sekundach zastanawiać się, po jaka cholerę ją okłamałem? Po co w ogóle udajemy, że jesteśmy zajęci, kiedy nie jesteśmy? I ruszyła lawina. Czy ja w ogóle nadaję się do tej pracy? Oby tylko nikt nie przejrzał mojego kodu, bo jeszcze znajdzie jakiś błąd, za który będę się wstydził do końca życia. Dlaczego nie dostaję nowego projektu? Pewnie myślą, że jestem słabym programistą. Ciekawe czy przedłuża mi kontrakt? Miałem zapytać o podwyżkę, ale przecież na nią nie zasługuje. Itd…

Czy ja lubię swoją pracę?

Kocham ją! I choć po przeczytaniu tekstu powyżej może wydawać się to dziwne, piszę to z całkowitą powagą. To, że przeważnie czuję się w pracy nieswojo i mam takie, a nie inne myśli, nie oznacza, że jestem słaby w tym co robię. Kiedyś myślałem, że jako automatyk musze wiedzieć wszystko o sprzęcie i oprogramowaniu, ale nie da się wiedzieć wszystkiego. Jedyne co trzeba, to się szybko uczyć. A mi nauka idzie świetnie. Pół roku temu wysłano mnie samego do Meksyku, żebym przepisał programy ze starych modeli robotów Epsona do nowych. Miałem to zrobić w trzy tygodnie, zrobiłem w dwa. Po przepisaniu programów i uruchomieniu maszyn, zdecydowałem, że napisze je od nowa, lepiej. Zredukowałem w ten sposób czas cyklu z pięciu sekund do czterech. Nigdy wcześniej nie programowałem robotów Epsona. Nigdy wcześniej nie napisałem programu dla żadnego robota. Jedyne co wystarczyło mi do tego zadania, to trzydniowy trening trzy miesiące wcześniej. Myśli, które generują się w mojej głowie nie są wywołane tym, że nie lubię swojej pracy. Ich źródło zakorzenione jest głęboko we mnie, a ich zrozumienie jest kluczem do tego bym stał się lepszy w pracy i życiu codziennym.

error

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *