Kilka lekcji z pracy
1. 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ść.
01 X 2006 o 02:14:54
Ad 1 - Pisanie wszelkiej masci generatorow to cudna zabawa ;-)
Ad 2 - Moze jakis palmtopik ??
Ad 3 - True true
Ad 4 - Wskazniki itp sucks ;-)
01 X 2006 o 02:35:07
To ja powiem tak - pisanie jakiegokolwiek kodu ssie, jeśli się nie kocha wyniku. Czy to będzie aplikacja współbieżnie działająca na 20 stanowiskach, czy aplikacja webowa, czy może wyhodowane pieczołowicie dziecko w asemblerze. Jeśli wolisz projektować, to programowanie będzie cię cieszyć przez góra dwa tygodnie od rozpoczęcia nowego projektu.
Co warto zapamiętać: jeśli nie działa, to problem nie jest w sprzęcie, glibcu ani w MFC (MFC ssie). Setki tysięcy ludzi wyłapałoby to dawno temu. Problem jest twój.
Co zaś się tyczy samego programowania - problem z kontrolą kodu polega na tym, że tak naprawdę dopiero dział QA może ci powiedzieć, że wszystko działa OK i to tylko z pewnym przybliżeniem - pewności mieć nie mogą. Problem polega na tym samym, co pojęcie filozofii języków do zastosowań rozproszonych, typu ADA, dopóki nie zrozumiesz, jak będzie działał twój kod na poziomie sprzętu, dopóty korzystanie z języka wysokiego poziomu przyniesie zero korzyści. Nie da się nauczyć _dobrze_ programować od końca - z pominięciem, jak to działa.
01 X 2006 o 22:54:11
"Co warto zapamiętać: jeśli nie działa, to problem nie jest w sprzęcie, glibcu ani w MFC (MFC ssie). Setki tysięcy ludzi wyłapałoby to dawno temu. Problem jest twój. "
Gdyby tak było w istocie, to wszelkie bugzille nie wypełniałyby się nowymi zgłoszeniami, nikt by ich nie poprawiał, i mielibyśmy powtórkę z Windows 95. Kwestionowanie zastanego porządku świata jest imho dobre. Sam zresztą zgłosiłem 1-2 błędy na Gecko.
01 X 2006 o 22:55:29
psz:
Nie chodzi o dosłowność tego zdania. Praktyka uczy, że 99% błędów to błędy twoje (albo IE6).
01 X 2006 o 23:53:06
Zaczynasz zmiękczać swoją teorię. Przedtem wykluczyłeś możliwość, że może to nie być wina naszego teoretycznego programisty.
Oczywiście nie neguję faktu, że powinien zdecydowanie uważać na to, co robi i być wobec siebie krytyczny. Tego wymagam od siebie, tego wymagam od innych. Jeśli ktoś jest skłonny wypuszczać buble pomimo tego, że wie, iż w kodzie jest błąd (nawet, gdy nie wie gdzie), nie powinien zbliżać się do kompilatora.
01 X 2006 o 23:54:45
Moją teorię? :)
01 X 2006 o 23:57:05
A czyją? Przecież to nie mmazur sugerował, że błąd w narzędziu jest niemożliwy :)
01 X 2006 o 23:58:48
Ja pisałem o glibcu i MFC. To raz.
Dwa: prawdopodobieństwo wyłapania błędu w bibliotece rozwijanej od X lat w kontraście z błędem w programie, nad którego kodem właśnie pracujesz, jest łatwe do oszacowania z dokładnością choćby do rzędu wielkości ;)
02 X 2006 o 00:12:52
Jak dla mnie glibc i MFC to narzędzia, nie da się ich używać samych z siebie.
Zgadzam się, że prawdopodobieństwo znalezienia błędu w dojrzałej bibliotece wacha się w granicach błędu statystycznego, jednak Secunia ma wiele przykładów na błędy, które siedzą(siedziały) latami w dojrzałym oprogramowaniu. Nie sądzę, żeby wszystkim zależało na tym, aby te błędy tak długo tam siedziały. A jednak.
Ok, sądzę, że jesteśmy blisko osiągnięcia consensusu w tej sprawie, jednak flame'owanie na koniec odpoczynku weekendowego mi się nie widzi... od jutra kolejny wyścig szczurów ;)
02 X 2006 o 18:47:23
ad2 - nie pda, ale hipsterpda.com :) Te wszystkie GTD/lifehacki/sposoby na lenistwo działają, jeśli rzeczywiście tego chcesz. I zawsze masz pod ręką listę zadań do zrobienia => masz czym pomocnika obarczać ;)
04 V 2007 o 21:09:00
heh, powiem szczerze że bardzo spodobał mi się wpis o menadżerach :) kodować nie lubię ale zarządzać i owszem i powiem Ci że jeśli jest to dla Ciebie takie uciążliwe to po prostu olej zarządzanie swoim czasem i zajmij się czyimś i jak już to zrobisz to dopiero siadaj do swojego… jesli masz taką siłę aby ustalać komuś grafik to możesz dzięki temu jednocześnie wypróbowywać 2 sposoby na spędzenie dnia (swój i swojego podopiecznego) a następnie zanalizować je i wybrać ten najlepszy :)
jedna najcenniejsza rada jaką ja do tej pory poznałem w zarządzaniu własnym czasem to to że dzisiejsza ostatnia godzina jest Twoją pierwszą jutrzejszą... więc jak sobie dziś zakończysz dzień tak zaczniesz jutro… niby proste a jednak jak wiele zmienia…