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 
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.