Saturday, June 2, 2007

Re: Praca, rutyna i walka z zawodową codziennością

Post jest odpowiedzią na publikację Splatcha na temat rutyny w pracy.

Podjąłeś, Łukaszu, bardzo ciekawy temat, problemu z którym boryka się każdy programista robiący troche dłuższe projekty. Każdy wie, że nowości (projekt, zadanie, nowy język albo FrameWork) są ekscytujące i powodują wydzielanie jakichś naturalnych euforyków. Jednocześnie warto się zastanowić jak stworzyć wewnętrzny stymulator, gdy w pracy zajmujemy się projektem przewidzianym nawet na lata.

W mojej obecnej firmie, nasz projekt właśnie obchodzi pierwsze urodziny. Termin porodu bety mamy za 2 miesiące, ale rutyna dopadała mnie już wiele razy.

W dużych projektach nie możemy zmieniać ani technologii, ani języka. Fajnie jeśli są różne etapy. Przez pół roku tworzyliśmy serwer w PHP, a potem grubego klienta w Javie i każda zmiana była emocjonująca. Ale w końcu przychodzi moment stabilizacji, gdzie ma się już napisany Framework, a kolejne tickety w Tracu każą nam dodawać tylko nowe formularze i kontrolki. I tu sie pojawia ostra rutyna. Podobne GUI, podobna logika biznesowa. Kopiowanie kodu, aby uzyskać kolejną wyszukiwarkę i listę takich albo innych danych, itd.

Jeżeli samo kodowanie nie powoduje w nas entuzjazmu, to należy go szukać gdzie indziej.
Po pierwsze można próbować poza pracą. Znaleźć sobie sens działania poza programowaniem i tam "ładować się". Przychodzi mi tu na myśl reklama durexa, gdzie gościu podczas porannego śniadania nadal szczerzy się do wszystkich :D Wiadomo, że to przenośnia. Ale chodzi "aby to uczucie trwało dłużej", czyli żeby entuzjazm zdobyty w godzinach 16 - 8 starczał nam jeszcze na 8 - 16.
Z drugiej strony patrząc, często wymaga to posiadania jakiejś pasji, bliskich czy przyjaciół. Natomiast obserwując ludzi z "branży" IT i pokrewnych, zdarzają się tacy, którzy potrafią poświęcić się tylko pracy, a życie osobiste mają dużo skromniejsze. Tu można zrealizować mój drugi pomysł, zresztą wcale nie kolidujący z pierwszym. Należy w pracy zbudować dobry zespół. Tu wkraczamy na temat rzekę, który jest poruszany w większości dobrych książek o zarządzaniu projektami i w dodatku stanowi on większą część tych publikacji, niż same "techniki" zarządzania.
Dobry, zgrany zespół to podstawa. To grupa ludzi, którzy są w stanie przerwać rutynę. To miła rozmowa podczas przerwy obiadowej, albo pomoc przy "zakleszczeniu" umysłowym przy rozkminianiu danego zadania. W dobrym zespole ciekawa anegdotka opowiedziana z nienacka potrafi bardzo porawić humor. Czasem nawet ktoś wywinie orła przy wygłupach co świetnie rozluźnia sytuacje. Ale z drugiej strony, członek dobrego zespołu to ktoś kto każe się nam wziąć w garść, kiedy za bardzo marudzimy.

Takie miałem nieskrempowane pomysły. A jak jest umnie? Myślę, że jeśli mamy sensownych ludzi w zespole, drugi wariant da się zawsze osiągnąć, conajwyżej potrzeba trochę czasu i pomysłów na przełamanie barier. Z pierwszym nie zawsze jest łatwo. Mam żonę i cudnego synka. Ale dużo trudniej jest mi znaleźć w sobie chęć na wyjścia na jakies piwo ze znajomymi, albo pójść na imprezę urodzinową kumpla ze studiów.
W pracy mam bardzo fajny zespół, choć niestety uboższy o jednego, bardzo zdolnego programistę i świetnego kolegę, który był dla mnie często wsparciem.
Udało nam się "dotrzeć", choć początki nie były łatwe. Teraz panuje luźna atmosfera na przemian z dużym skupieniem. To bardzo pomaga, choć przyznaję, że czasem mnie wkurza kiedy za długo sobie żartują :) Bardzo dużo razem zainwestowaliśmy w komunikację i teraz łatwiej jest się dogadać, szczególnie przy tworzeniu nowego kawałka systemu. To wszystko powoduje, że ewentualną rutynę łatwiej jest znosić, a często ponownie wraca entuzjazm i radocha z programowania.