Kilka lekcji z pracy
30 IX 2006, 23:231. Programowanie jest nudne. Strasznie. (Co było jedną z myśli przewodnich dłuższego marudzenia, które chciałem napisać... ale nie mam czasu.) Zwłaszcza w językach niskopoziomowych, gdzie 90% programowania to wynajdywanie koła od nowa. Programowanie robi się mniej nudne, gdy częścią tych nudnych kawałków zajmuje się współpracownik.
2. Ja mam cholerne problemy z zarządzaniem własnym czasem (to jest coś, na czym muszę się skupić w najbliższej przyszłości). Posiadanie współpracownika, który zależy ode mnie w kwestii przydzielania mu zadań jest natomiast problematyczne do kwadratu, gdyż dodatkowo muszę się martwić zapewnieniem jemu roboty w jego timeslotach. Przykład z życia wzięty: współpracownik wstaje kilka godzin przede mną i najwięcej czasu na pracę ma zawsze z rana. Ale dzisiaj mi coś wypadło i ani nie zrobiłem swojego zadania, ani nie powiedziałem mu co ma robić jutro. Skutek -- ja nie zrobiłem nic dzisiaj, a w konsekwencji on jutro, czyli w praktyce moje niedoplanowanie dnia dzisiejszego oznacza stratę dwóch roboczodni. Unaoczniło mi to, dlaczego ludzie na stanowiskach menedżerskich często siedzą do późna w nocy -- zapewne od tego, czy wykonają swoją robotę dziś zależy, czy X ludzi będzie mogło wykonać swoją jutro.
3. Że spore niewyspanie wpływa na moje zdolności do prowadzenia samochodu, to już wiem od dawna, bo różne drobne pomyłki podczas kierowania zauważam bez problemu. Ale znacznie, znacznie ciekawsze są tego typu wpadki przy programowaniu, gdy po raz n-ty sprawdzając daną linię kodu (bo nie działa) nagle się łapię za głowę, że błąd mam przecież przed nosem. Zapamiętać: jeśli zaczynam podejrzewać, że jest coś nie tak z glibcem, to na 99,9% gdzieś jest oczywisty błąd, którego nie widzę. Muszę sobie wymyślić jakiś sposób na tego typu sytuacje, tzn. gdy mam w mózgu blokadę, przez którą mózg nie może załapać, że to na co patrzy, wcale nie jest poprawnym kodem. Hmm. Może pisać sobie ten sam kod od nowa w okienku obok (nie zerkając), a po skończeniu porównać? Sounds good, będę musiał następnym razem spróbować.
4. Ponieważ klepię się z wątkową i mocno zżerającą procki aplikacją, w której jakiekolwiek mikrobłędy z lockowaniem, synchronizacją, czy czym tam jeszcze prawie od razu wychodzą, pozwolę sobie trochę powróżyć na przyszłość.
Programowanie współbieżne jest trudne. Po raz kolejny zwiększa się poziom skomplikowania systemów, podczas gdy mózg człowieka zostaje, jaki był. Nie był to może aż taki wielki problem, gdy tego typu systemy były bardzo ograniczone w występowaniu, bo dotyczyły różnej maści zastosowań serwerowych, a co za tym idzie można było sobie pozwolić na dopadnięcie co lepszych programistów, którzy sobie z tym wszystkim potrafią poradzić. Z prockami wielordzeniowymi tego typu oprogramowanie trafi natomiast pod strzechy, więc coraz więcej programistów będzie musiało się z tego typu technikami zaznajomić. Moje przewidywanie -- będzie jak z obecną generacją języków dynamicznych. Z punktu widzenia zużycia procesora są one wręcz niesamowicie nieoptymalne, ale pozwalają zaoszczędzić czas programisty. I analogicznie będzie z programowaniem współbieżnym. Za ileśtam lat, gdy prawie wszyscy będą mieli wielordzeniówki w komputerach, zaczną być popularne techniki programowania równoległego wręcz idiotycznie nieoptymalne z punktu widzenia wykorzystania pojedyńczego rdzenia, natomiast proste w użyciu i skalowalne wszerz, tzn. dodawanie kolejnych rdzeni będzie przyspieszało aplikację znacznie bardziej, niż zwiększanie ich prędkości. I w tym to momencie producenci procków pójdą po rozum do głowy i zaczną zmniejszać moce przerobowe poszczególnych rdzeni, byle tylko być w stanie wsadzić ich więcej na pojedynczą kość.