Zawód – programista. RAK kreatywności i satysfakcji.

13

Wielokrotnie zdarzało mi się, że budziłem się rano i na samą myśl o kolejnym dniu w pracy robiło mi się niedobrze. Czy też tak czasami macie? Pomimo całej świetności naszego zawodu, ogromnej gamy wyzwań i oczekujących na rozwiązanie pasjonujących problemów, bycie programistą może czasami dać się nieźle we znaki.

Post ten jest kierowany nie tyle do samych developerów, co do ludzi o “jeden stopień wyżej”. Menadżerów? Team leaderów? Architektów? Zwał jak zwał. Poniżej zebrałem kilka rzeczy, którymi możecie naprawdę uprzykrzyć życie swoim “podwładnym” i z potencjalnie bardzo wartościowych członków zespołu uczynić bezmyślne małpy czekające na godzinę 16.00, aby zmyć się jak najprędzej do domu.

Bierz kasę, o nic nie pytaj, nic nie rób, czekaj na zadanie.

Zdarzyło mi się kiedyś pracować w firmie, w której nie musiałem robić NIC. Autentycznie! Przychodziłem do pracy i przez 8 godzin czytałem książki, oglądałem filmy, układałem pasjansa. Wszystko to w oczekiwaniu na COKOLWIEK do roboty. Wydawać się może: praca – marzenie? Nic bardziej mylnego! Mogę z czystym sumieniem powiedzieć, że była to najbardziej męcząca praca w moim życiu – a robiłem wiele rzeczy, w tym np. malowanie balkonów w USA jako zwykły “robol ze wschodu”. Nie dość, że najbardziej męcząca, to jeszcze najbardziej irytująca. Chodziłem cały czas wściekły: czy po to studiowałem? czy po to uczyłem się na własną rękę? czy po to zdobywałem certyfikat, zarywałem noce, rezygnowałem z uciech studenckiego życia?

Oczywiście jakąś część tego czasu wykorzystałem niezwykle produktywnie: ile blogów się wtedy naczytałem, ile teorii wchłonąłem, ile rozwiązań mogłem “testowo” zaimplementować! Ale… co z tego? Z czasem przyszło zwykłe otępienie. Jaki jest tego cel? Kiedy mi się to przyda? Odpowiedź wydawała się banalnie prosta: NIGDY! Wysłany czasami bez sensu na spotkanie, o którego temacie nie miałem zielonego pojęcia, czy przydzielony do głupiego zadania które mógłby wykonać licealista z klasy humanistycznej, jedyne co mogłem zrobić to zżymać się w duchu i raz po raz narzekać: “CO JA TU ROBIĘ??”. Szedłem do pracy, inkasowałem pensję, układałem pasjansa, czekałem na koniec dnia, szedłem do pracy, układałem pasjansa…

Aż mi teraz wstyd, że tyle czasu zmarnowałem na tego durnego pasjansa. Ale na swoje usprawiedliwienie powiedzieć mogę, że mniej zmotywowany do CZEGOKOLWIEK nie byłem ani nigdy wcześniej, ani nigdy później. Skończyło się oczywiście na rzuceniu papierami i auto-zwolnieniu, ale tych zmarnotrawionych godzin już nikt mi nie zwróci.

Kierowniku: przed zatrudnieniem programisty zastanów się, czy naprawdę go potrzebujesz.

Tutaj masz opis tego CO trzeba zrobić. A tutaj: dokładny opis JAK to zrobić. Mózg: OFF i do roboty!

Czy zdarzało wam się dostać do wykonania jakieś zadanie wraz z dokładnymi instrukcjami dotyczącymi implementacji? Nie chodzi mi o wskazówki typu “nie zajmowałeś się tym wcześniej, więc zajrzyj na taką i taką stronę, przeczytaj ten i ten artykuł”, a o polecenie “zrób to dokładnie TAK!”. W przypadkach ekstremalnych: “masz tu kod, który kiedyś napisałem i dopasuj go do aktualnego projektu”. Za każdym razem, gdy miałem do czynienia z czymś podobnym, wyła we mnie z upokorzenia istota rozumna. Czy JA  nie potrafię tego zrobić? Czy TY uważasz, że programista to namiastka xero, który zmieni nazwy zmiennych tak aby wszystko się kompilowało i tyle? Potencjalnie interesujące wyzwania mogą zostać w ten sposób całkowicie zmarnowane. Bezrozumne postępowanie zgodnie z wytycznymi krok po kroku nie może skończyć się dobrze. Normalne chyba jest, że programista w takiej sytuacji “weźmie co dane”, wrzuci do projektu i basta. Zapędzony do roli pani piszącej na maszynie nie będzie wnikał czy każdy krok jest właściwy. “Consider it done!” i już. Nie chodzi o dokładną specyfikację, bo ta jest oczywiście jak najbardziej mile widziana – a o niskopoziomowe wytyczne dotyczące samego procesu tworzenia kodu.

A jeśli się okaże, że coś nie działa jak trzeba, że gdzieś kryje się błąd… czyja będzie wina i kto spędzi pół dnia w debuggerze…?

Oczywiście, czas może naglić. Nie można wynajdować koła od nowa po raz n-ty. Trzeba dzielić się wiedzą i doświadczeniem. Ale: z umiarem! Każdy ma prawo do chwili satysfakcji i zrobienia czegoś fajnego.

Wiem, że kiedyś sam popełniałem ten błąd i sam w taki sposób przydzielałem zadania. “Za wszystkie serdecznie żałuję”.

Kierowniku: nie traktuj programisty jak debila – daj mu się wykazać. Nie tylko ty masz prawo do czerpania przyjemności z kodowania.

Czy ktoś ma inną propozycję? OK. A teraz robimy po mojemu.

Czy możecie wymyślić coś bardziej uwłaczającego niż zostanie poproszonym o wyrażenie swojego zdania, które następnie jest całkowicie olane? Pewnie tak. Ale uczucie towarzyszące przytoczonemu zjawisku również jest nie do pozazdroszczenia. Z zapałem zabierasz się do wymyślenia ciekawego rozwiązania, potencjalnie LEPSZEGO niż to zaproponowane przez “górę”. Dumny z siebie prezentujesz efekt pracy (często wykonanej po godzinach, bo w firmie trzeba przecież KODOWAĆ) i czekasz na odrobinę uznania. Jeśli nie uznania, to dyskusji. Jeśli nie dyskusji, to wytknięcia błędów. Jeśli nie wytknięcia błędów, to choćby zauważenia włożonego wysiłku. A jedyne co słyszysz to: “ok, a teraz robimy po mojemu”.

Krew człowieka zalewa.

Kierowniku: bądź otwarty na alternatywy; twoi podwładni mogą mieć dobre pomysły, czasami nawet lepsze od twoich. A jeśli są gorsze to wytłumacz dokładnie dlaczego, dzięki temu ich praca nie pójdzie na marne.

Płacimy ci za kodowanie. Więc KODUJ!

Przychodzisz do biura, odpalasz ulubionego bloga – może pojawiło się coś nowego? Może na jednym z obserwowanych portali umieszczono artykuł, który przedstawi techniki pozwalające na wydajniejszą, lepszą pracę?

A tu nagle, niczym siarkowy podmuch z piekielnych otchłani, mroczny szept z tyłu: “czy nie masz przypadkiem kodu do napisania?”. O nie, znowu mnie przyłapali!

I cały misterny plan w p… Nieważne co robisz – ważne, abyś miał Visual Studio na monitorze.

Czy to jest naprawdę wyznacznik wydajności i efektywności: stosunek czasu w którym VS ma focus do czasu spędzonego w pracy? Czy programista robi tylko to: programuje? Nie mówię o całodziennym śmiganiu po internecie i olewaniu zadań, bo oczywistym jest, że nie po to zatrudnia się developera. Ale czy kilka minut dziennie poświęconych na edukację, zorientowanie się w trendach i newsach, poszerzenie horyzontów jest takim marnowaniem czasu, że trzeba je tępić? Ja na ten przykład byłbym wniebowzięty, gdyby mój zespół był zainteresowany czymś więcej niż tylko zalepieniem zgłoszonych bugów czy dodaniem do rozwijanego projektu nowych funkcjonalności. Gdyby ludzie z własnej woli chcieli rozwijać swoje umiejętności, z dnia na dzień uczyć się czegoś nowego, stawać się coraz lepszymi w swoim fachu.

Kierowniku: promuj otwarcie, zaangażowanie i aktywność. Zwalczaj bierność i marazm.

Nowe podejście do problemu? A kim ty jesteś, aby podważać aktualną strategię?

Czujesz, że praca nad projektem nie jest tak efektywna jak mogłaby być. Proponujesz: “może zastanowimy się nad zastąpieniem ręcznego klepania procedur jakimś ORMem?”. Albo: “nasz system przydzielania zadań bardzo spowalnia pracę, może warto zastanowić się nad alternatywą?”. Albo: “mam doświadczenie z innymi systemami kontroli wersji niż SourceSafe, może chcesz żebym pokazał ci o ile lepszy jest Subversion czy Git?”. Albo: “niektóre miejsca tego projektu naprawdę warto pokryć testami jednostkowymi”.

A słyszysz wymowne i bezpardonowe: “to nie twoja działka”.

Czy po kilku takich próbach nadal masz chęć udzielania się w jakikolwiek sposób, szukania lepszych rozwiązań, usprawniania pracy nad projektem? Wątpię.

Kierowniku: nie ukręcaj łba wszystkim propozycjom, które wychodzą “z dołu”. Korzystaj z doświadczenia swojego zespołu.


Pewnie dałoby się takich scenariuszy opisać o wiele więcej. Pewnie mieliście do czynienia i z wymienionymi, i z innymi (jakimi? czekam na feedback). Pewnie każdy z nas w ten czy inny sposób został kiedyś stłamszony, “doprowadzony do porządku”, każdemu z nas zostało pokazane jego miejsce… zgarbiony ludek nad klawiaturą.

Przedstawione sytuacje pochodzą z różnych źródeł: część z nich z własnego doświadczenia, część z opowieści. Jedną cechę mają wspólną: wszystkie są (o zgrozo!) autentyczne. Nie wiem jak idealnie powinno się prowadzić zespół programistów (póki co – nie muszę tego wiedzieć), ale… wiem, jak zdecydowanie NIE POWINNO się tego robić.

Rada na koniec: choćby spotkało cię to wszystko, nawet wszystko naraz jednego dnia: nie poddawaj się! Sam wielokrotnie zadawałem sobie pytanie: czy na tym właśnie polega zawód programisty? Czy nadzieje z nim związane pozostaną na zawsze tylko naiwnymi wyobrażeniami niemającymi nic wspólnego z rzeczywistością? A jednak… z czasem wszystko się układa – tyle że nie samo z siebie. Więc “szukajcie aż znajdziecie” i nie bójcie się zmian. Na marnowanie czasu w niewłaściwym miejscu po prostu szkoda życia programisty.


P.S. Ostatnio dostałem od ziomka ciekawy link: Grunt Programmer. Definicja:

victim of being treated as a Grunt Programmer is only allowed to write code; they’re not allowed to think about design or user requirements — that’s someone else’s job

Jeśli jesteś zaszufladkowany jako Grunt Programmer: zbierz się w sobie i zmień to. Za zakrętem naprawdę czeka coś o wiele lepszego!

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

13 Comments

  1. Poranna lektura mojego ulubionego bloga odhaczona :) Na szczęście siedzę na końcu pokoju i nikt przez plecy nie zagląda :)
    % gdzieś Ty pracował? :) Znałem te historyjki już wcześniej, ale i tak jak je czytałem to nie jestem w stanie sobie tego wyobrazić.

  2. @emdzej:
    łudzę się, że jedynie niewielka mniejszosc programistow ma stycznosc z takimi historiami. łudzę się…
    P.J.

  3. W moim środowisku bardzo dużo osób ma tego typu problemy. Zwykle nie wszystkie na raz, ale jednak. Osobiście nie rozumiem trwania w takim marazmie dłużej niż kilka miesięcy. Miałem podobne doświadczenia osobiście i, gdy się nie poprawiło, zacząłem szukać pracy. Ostatecznie argument zmiany pracy zadziałał i się poprawiło.

    Jest jeszcze jedna rzecz o której warto wspomnieć: nawet nie będąc kierownikiem możesz innym programistom odmienić życie. Sam nie mam w firmie żadnej władzy administracyjnej, mam biurko jak każdy inny programmer. Mam jednak dużo większą siłę przebicia jeśli chodzi o kanały nieoficjalne. Wielu z Was, czytających zapewne także. Możecie zauważyć jakiegoś tłamszonego młodszego programistę, który jest naprawdę dobry, ale nie pozwala mu się rozwinąć skrzydeł. W takiej sytuacji macie moralny obowiązek _jakoś_ zareagować. Jeśli nie dla dobra tego tłamszonego, to dla dobra firmy, w której pracujecie–kiedyś z tego nieszczęśnika może wyrosnąć jakiś ważny menedżer lub architekt albo jeszcze jakieś inne cudo.

  4. wydawalo mi sie ze tylko moje stanowisko jest tak wyjatkowe, ale po przeczytaniu pierwszego przypadku zrozumialem ze nie.

    Okres wakacji byl okropnie meczacy – pierwsza praca, a raczej staz, wtedy mialem naprawde duzo checi do pracy! niestety… kazda prosba o jakiekolwiek zadanie konczyla sie: "poczytaj sobie ksiazke o ty i o tamtym".
    Jednak po ukonczeniu stazu pozostalem w firmie z braku alternatyw, a kasa potrzebna. Pomimo to, musze tez dodac ze sytuacja sie nieco poprawila.

  5. Taki jeden moj osobisty komentarz zwlaszcza do punktu drugiego.
    Czasami sie zdarza dostajemy kod z innego projektu i ktos musi go zaadaptowac. Manadzer, kierownik czy ktokolwiek inny, mimo ze np sam to kiedys pisal po prostu nie usiadzie do tego z braku czasu. I niestety, chcial nie chcial, taki kod po prostu trzeba zaadaptowac na potrzeby nowego projektu i wg mnie nie ma co sie o to obrazac. Ponadto, przelozeni czesto wychodza z zalozenia – mamy cos napisane, przetestowane, dzialajace, to wstawimy do nowego projektu i bedzie git – jest to podejscie czysto ekonomiczne bo lepsze jest wrogiem dobrego! Pamietaj, ze nowy kod jest zrodlem potencjalnych nowych bugow, ktorego ten stary jest pozbawiony. Wiec, jesli sytuacja sie nagminnie nie powtarza to uwazam, ze nie nalezy sie strofowac i po prostu to robic bo to nie jest nic specjalnie zlego. Tym bardziej ze czytanie/przerabianie cudzego kodu (zwlaszcza jesli jest fajnie napisany) tez moze byc wzbogacajace o nowe doswiadczenia.

  6. A co sądzicie o takim scenariuszu, kiedy kierownik mówi: "nie wiem jak to zrobić, zrób jak Ci jest wygodniej, ważne by działało." Dla mnie jest to pozostawienie programisty samemu sobie, a przy skomplikowanych problemach po paru dniach samodzielnego myślenia nad rozwiązaniem mózg totalnie już odlatuje. Po drugie – po co się starać, tworzyć lepszy kod, jak on musi tylko działać. W zasadzie szybciej rozwiąże problem osoba, która napisze byle jak kod, np. skopiuje znaleziony jakiś fragment, wklei, zmodyfikuje i będzie działać. Tylko co wtedy z utrzymaniem jakości kodu. Wiadomo, że po paru zmianach "pokoleniowych" kod nie będzie się nadawał już do niczego, ale kierownictwo jakby nie wybiega aż tak daleko myślami. Gdyż zawsze jakoś to będzie. Co więc zrobić: walczyć i starać się "nawrócić" innych, czy zacząć tworzyć użyteczny (czytaj. w tym przypadku często niepoprawny, niedbały itd.) kod?

  7. @yaceq:
    Oczywiscie masz racje – ale tak jak napisalem nie nalezy przeginac ani w jedna, ani w druga strone… najlepiej znalezc rozwiazanie z ktorego wszyscy beda zadowoleni (ale odkrywcze:) ). Pisanie WSZYSTKIEGO od zera jest glupie. Ale tez – praca polegajaca na ciaglym dostosowywaniu cudzego kodu nie niesie ze soba zbyt wielkiej satysfakcji.

  8. @Year:
    Dla mnie taki scenariusz jest wlasnie ideałem: programista dostaje WYMAGANIA funkcjonalne i tworzy ich implementacje. On musi pomyslec jak to zakodowac, aby powrót do kodu po kilku dniach nie byl meczarnia.
    W kwestii uszczegolowienia wymagan zawsze powinien moc zwrocic sie do kogos, kto je definiuje. Przy problemach technicznych – powinien miec kogos, kto pomoze.
    Ale zawsze trzeba znalzc kompromis pomiedzy jakoscia kodu a jego funkcjonalnoscia: na koniec i tak liczy sie tylko czy produkt robi to co powinien, a JAK zostalo to osiagniete jest (dla kierownictwa, dla uzytkownikow) nieistotne. I slusznie.

  9. Doskonale Cię rozumiem. Sam teraz tkwię w czymś takim. Na szczęście mam jeszcze na tyle motywacji przygotowując się do ścieżki MCPD.
    Pozostaje jedna rzecz po drugiej stronie… na drugiej szali – trzeba utrzymać rodzinę i czasem łatwiej powiedzieć niz zrobić.
    Pozdrawiam Cie serdecznie i gratuluję bloga :)

  10. handlowiec on

    Nie jesteście sami.
    Jako osoba z działu sprzedaży też coś opowiem.
    Pewnego dnia utrafiłem na naprawdę dobrego klienta.
    Dobrego tzn. napalonego na drogi produkt. Bardzo drogi produkt.
    Powiedzmy, że ten produkt dawał marżę 100 tyś zł, gdy przeciętny
    produkt który sprzedawaliśmy dawał marżę 5 tyś zł.
    Ciśnienie miałem ogromne.
    Wołam kolegów co się nudzili do pomocy.
    Mówię: "słuchajcie – klient chce mieć to i to po niemiecku i po angielsku
    dodatkowo trzeba zrobić to i to" itp.
    Zrobiło się małe zamieszanie.
    Wiecie co mi powiedział dyrektor ?
    Ryknął na mnie: "twój deal nie jest kuź.a najważniejszą rzeczą na świecie. Ciszej trochę !".
    Powalił mnie na nogi. Ja robię sprzedaż na 100 tyś zł a ten mnie za to opieprza!
    Długo pod tym człowiekiem nie popracowałem.
    Zmieniłem barwy firmowe.
    Jak się później okazało nikt za kadencji tego dyrektora nie utrzymał się w tej firmie na długo.
    Nie wiem kto go w tej firmie trzyma na tym stanowisku.
    Zamiast motywować dołuje ludzi.