Programowanie jest pięknym zawodem. Jest stymulujące intelektualnie, pozwala na kreatywność, pomaga ludziom ułatwiając im życie i służy biznesowi redukując koszty. Czasami jednak ma smak goryczy.
W programowaniu jest duch wydajności. Od chwili, gdy na pierwszym komputerze udało się policzyć coś setki razy szybciej niż ręcznie, jesteśmy oczarowani możliwością uzyskania niespotykanej wcześniej efektywności. Pewnie dlatego programiści prześcigają się w tworzeniu narzędzi usprawniających pracę. Ergonomiczne edytory kodu, automatyczne testy pozwalające zwiększyć niezawodność oprogramowania, metodyki tworzenia programów sprawniej, szybciej, wydajniej.
Każdy programista, który kiedykolwiek pisał coś co dało się zoptymalizować zna to słodkie uczucie, gdy coś zadziała sprawniej. Swego czasu, gdy jeszcze studiowałem, pewien profesor zlecił nam napisanie programu kompresującego. Algorytm z tego co pamiętam był entropijny, czyli przypisywał słowom używanym w tekście najczęściej najkrótsze symbole, a tym mniej powszechnym dłuższe. Na początku program po prostu działał, jak zwykle w optymalizacji bywa – wolno. Potem trzeba było sprawić by działał szybko. Pamiętam, że chodziłem dzień lub dwa z problemem w głowie, aż w końcu zrozumiałem, że drzewo BST będzie odpowiednim narzędziem w tym przypadku (dekompresji tak konkretnie). Po zmianie program działał błyskawicznie. Satysfakcja była przeogromna.
Tak samo jest z programowaniem poza akademią. Kiedy widzimy sens w projekcie, w produkcie, gdy wiemy, że użytkownicy będą zadowoleni, że ułatwi to ludziom życie – jest pięknie. Praca nad czymś takim to czysta przyjemność.
Bywa jednak gorzko. Pracujemy, nieraz w dużej grupie, miesiącami, nad pewnym produktem, wkładamy w niego serce, pracę i czas, powołujemy go do życia, a potem z powodu jakiejś decyzji na szczeblach władzy dużej firmy projekt zostaje anulowany. Znam osobiście człowieka, który po takiej decyzji opuścił firmę. Ze swojego doświadczenia natomiast wiem, jak boli, gdy dopada nas tego rodzaju wydarzenie.
I o ile zdarza się to raz na kilka lat nie ma w tym większego problemu. Jednak jeśli powtarza się regularnie, jeżeli staje się normalnością, zaczyna rodzić cynizm. Jak przekonać programistę do zwiększania efektywności albo wzmożonej pracowitości, jeśli przez ostatnie kilka lat co drugi projekt w jakim uczestniczył został anulowany, a jego kod nigdy nie wszedł na produkcję? Nie wiem. Po prostu nie wiem. Sądzę, że taki pechowy programista zostaje na jakiś czas, być może na zawsze, zepsuty.
Jest taka mądra opowieść o testach i błędach. Jeśli bug jest wykryty chwilę po powstaniu, jego naprawienie kosztuje niewiele, jeśli tydzień, już więcej, a jeśli lata później, bardzo dużo. Podobnie jest z decyzjami projektowymi – błędne decyzje co do startu projektu albo jego kształtu kosztują ogromne pieniądze. Im mniej tych błędów tym również mniej frustracji wśród programistów w naszym przedsiębiorstwie, a więcej motywacji, efektywności i zysku. Dlatego warto prototypować i badać rynek. Przynajmniej jednak dobrze byłoby programistom wyjaśnić czemu ich praca poszła na śmietnik. Możliwe, że odrobinę zmniejszy to ich gorycz…