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!