3 - Klienci (jak wspomniał Piotr - niezdecydowani, upierdliwi, przede wszystkim nieuświadomieni w kwestii ilości pracy, zwłaszcza przy "małych przeróbkach" gotowego projektu)

2 - Użytkownicy (nigdy nie zrobisz takiego interfejsu, który by dogodził każdemu)

Miejsce pierwsze:

1 - Przerabianie/poprawianie cudzego kodu. Koszmar, makabra i groteska. Już wolałbym analizować medyczne aspekty scen z "Koszmaru z Ulicy Wiązów", niż przedzierać się przez cudzy kod. Niestety, często muszę. Nie życzę nikomu.

Grand Prix zdobywa:

Znajomi/rodzina z zepsutymi komputerami i Windowsami do przeinstalowania.

Na końcu szybka lista mniej, ale również przerażających rzeczy:
- debuggery (każdy inny)
- przerabianie/poprawianie cudzego kodu
- deadline'y :)
- użytkownicy
- perl :)
- brak dostępu do sieci
- klienci
- manuale pisane przez ludzi, którym się nie chciało
- manuale pisane przez ludzi, którym się za bardzo chciało
- konieczność przeniesienia desktopa z jednego miejsca na drugie

To tylko tytułem wstępu.

Mnie strasznie przeraża nuda. Nie mieć nic (ciekawego) do roboty to chyba najgorsza katorga jaką wymyślono :).

1. Trwała utrata wzroku.
2. Poziom przerażenia wzrastający wykładniczo do ilości utraconych palców u rąk.
3. Brak czasu.
4. Brak kawy.
5. Monopolizacja rynku. Wygląda na to że złote czasy MS szczęśliwie mijają, ale z niepokojem patrzę na ekspansję Googla.

Z tego co wcześniej padło.

1. Brak prądu ;).
2. Upierdliwa klienteria.
3. Brak sieci.
4. Coś czego pierwszy raz doświadczyłem na studiach ze strony prowadzących: Straszliwe zarozumialstwo.

Spośród 4 prowadzących przedmioty związane z programowaniem, 3 była nadętymi wszystko-lepiej-wiedzącymi mendami.

Zrobiłeś tak, to stwierdzi że miało być inaczej, następnym razem zrobisz dokładnie tak jak wcześniej "zalecił prowadzący", to ci znowu powie, że miało być inaczej (często tak jak było wcześniej "źle").

Spośród tych 3 mend, tylko jedna faktycznie reprezentowała poziom, pozostała dwójka nie reprezentowała żadnej pozytywnej cechy.

Jeden prowadzący był zarazem inteligentny jak i sensownie podchodził do pracy studentów, akceptując dobre rozwiązania i dyskryminując (zapomniałem słowa) złe rozwiązania za pomocą sensownej argumentacji.

1) Upierdliwy klient, który sam nie wie czego chce, co chwila wszystko zmienia (nawet to co już wcześniej kilka razy zaakceptował) ciagle dokładając kolejne funkcjonalności mimo iż czas ucieka, a na koniec i jest pierwszy do narzekania dlaczego projekt się przeciąga.

2) PM który pozwala na takie rzeczy klientowi.

regexpy i wzorce projektowe.

ale najbardziej - inni programiści. Każdy alfa i omega, każdy pozjadał wszystkie rozumy i każdy uważa tego drugiego za gorszego (coś jak magowie w Świecie Dysku Terrego Pratchett'a ;)) Tak więc umiejętności miękkie panowie - praca zespołowa! :)

że nigdy nie znajdę czasu, by w końcu zrealizować projekt z tą swoją super-power-killer aplikacją, która zapewni mi sławę, pieniądze i chwałę.

Albo co gorsza.. że ktoś zrobi to przede mną!!!

Rodzina i znajomi z problemami typu "komputer mi się zepsuł", "mam nowy telewizor może byś mi go podłączył i kanały poustawiał", "mam nowy telefon ale nie umiem go obsługiwać może byś mi pokazał jak" "mam mikrofale ale nie wiem jak ustawić timer" "mam praleke ..." i cała masa innych zadań z gatunku obsługi sprzętu agd/rtv. A tylko spróbuj im powiedzieć że nie studiujesz obsługi rtv/agd i nie masz pojęcia to jeszcze ci powiedzą że przecież się znasz lepiej. I potem człowiek siedzi i czyta instrukcje bo te * nie potrafią zrozumieć że jak pisze wczyśnij klawisz oznaczony gwiazdką to trzeba go wcisnąć wrrrrrr

brak prądu..................

Odpowiedzi ze StackOverflow przetłumaczone na język polski: http://tomwys.info/2010/07/jaki-jest-koszmar-kazdego-programisty/

Ciągłe siedzenie przy komputerze.

uirapuru - ja tam lubię innych programistów.

Czasami mamy różne podejście do problemu, trochę na siebie nawrzucamy, jakieś k***wy polecą, ale generalnie nic nie zastąpi kilku punktów widzenia danego problemu i dyskusji "niech zdecyduje kod". Czasami się pokłucimym, czasami się posprzeczami, aczkolwiek większość nieporozumień bierze się z "nie do końca umiem wypowiedzieć to co myślę <-> nie do końca jestem w stanie sobie wyobrazić o co mu chodzi", dlatego kod w języku pl-PL to zwykle tylko wstęp do dyskusji, a jej kwintesencją jest kod kompilowany (i ewewntualna dyskucja nt. tego kodu).

P.S. Podczas prac z zew. komponentem napisanym w Jave przez włoską, w któej osoba odpowiedzialna za "support" specjalizowała się w PHP (i o J2EE ani o .NET nie miała zbyt dużego pojęcia) odkryłem pewną mega hiper super zależność. To, że w różnych techologiach na te same rzeczy mówimy inaczej to norma. To że w różnych krajach na te same rzeczy mówimy inaczej to też norma (@ dla Polaków to "małpa", dla Rosjan "szczór", w innych krajach inne zwierzątka itp.). W takich rozmowach nie można stosować słów "potocznych". To co jest najskuteczniejesze podczas rozmowy z innymi programistami to KOD (+ ewentualnie mega krótki komenrarz).

P.S.2 Dzisiaj miałem rozmowę z kumplem. We 2 próbowaliśmy rozwiązać 1 problem. On kodował (swoją drogą naprawdę bardzo dobrze), ale mi się nie podobała składnia jednej funkcji (moim zdaniem zbyt długa, przez co niepotrzebnie zwiększała szerokość oraz ilość linijek kodu, a tym samym zmniejszała jego czytelność). Najpierw rozmawialiśmy o tym w "pl-PL". Jemy wydawało się, że czepiam się jakości i funkcjonalności kodu. Poszły więc jakieś epitety typu "mój kod jest super, a to co mówisz nie zadziała i wywali błędy i w ogóle jesteś xyz...". Dopiero jak napisałem jego funkcję "po swojemu" on zadał pytanie - "po co Ci 2 takie same funkcję??", a ja "Twoja funkcja jest super, ale chodziło mi o zbyt długą składnię. To samo można napisać troszkę inaczej...", "aha, okej, człowiek uczy się przez całe życie...".

P.S.3 Ost. do mojej wersji czepił się kompilator (coś mu się nie podobało, pewnie brak jakiegoś nawiasa w składni funkcji). Po weekendzie tam zajrzę i jeszcze coś w tym uspawnię, bo dzisiaj musieliśmy to olać, bo MEGA WAŻNY jest dla nas czas oddania projektu (czyt. - do końca tego mieś.) i wszystko inne (w tym długość i jakość kodu) ma mniejszy priorytet (bo klient tego nie widzi).

Praca z kodem spaghetti (pomieszanie z poplątaniem - kawałki widoków pomieszane z logiką biznesową i czasem (o zgrozo) modelami). Zdarzają się szaleńcy którzy potrafią w widokach umieszczać duży kawałek logiki która powinna siedzieć w modelach.

Przeraża mnie poprawianie takiego kodu (który siłą rzeczy nie jest obłożony testami więc refaktorka i poprawa jest bolesna).

Przerażają mnie też klienci którzy "chcą coś super" ;)

Wplątanie się w tego typu historie ;) : We Use BobX

Wyciek (poufnych) danych

To iż technologia której ucze się teraz w momencie zakończenia nauki i rozpoczęcia wdrażania będzie już przestażała i niepotrzebna w związku z coraz szybszym rozwojem informatyki.