Czemu nie należy programować dla wielkich polskich korporacji? Kod który się dostaje jest marnej jakości, pisany przez fanatyka C, który wyznawał zasadę, że jeżeli nikt inny nie będzie w stanie tego kodu rozwijać, to nie będą mogli zwolnić jego twórcy (mimo wieku wskazującego na posiadanie wnuków nadal pracuje w firmie). Fragmenty napisane w C++ (pewnie już przez kogoś innego) są cholernie wolne. Nie, nie dlatego że są napisane w C++, tylko dlatego że zatrudnia się do tej pracy oszołomów którzy w C++ pisać nie potrafią. Przykład? Split na stringu dostarczony w Boost jest 3 razy szybszy od tego co został ręcznie napisany w projekcie który mam przyjemność pisać (chcę umrzeć…). Ale nie można wykorzystać szybkich i gotowych bibliotek Boost, bo musiałoby to przejść przez całą biurokrację aby była możliwość wstawienia jednego include’a i dorzucenia kilku plików… jakby nietechniczna biurokracja wiedziała lepiej ode mnie co jest mi potrzebne do napisania wydajnego kodu. Dlaczego tak? Bo jest to znacząca zmiana powodująca rozrastanie się kodu. A to że większość softu mają w Javie EE i wrzucenie tam czegoś powoduje ogromne narzuty wydajności, pamięci i dysku to już nikt tego nie widzi. Żeby było ciekawiej kod nie zawiera praktycznie żadnych komentarzy, dokumentacja niewiele mówi i jest pisana dla biurokratów, nie dla programistów. Na sam koniec trzeba przeprowadzić i udokumentować testy. Bardzo szczegółowo… czy ja mogę prosić o równie szczegółową dokumentację i komentarze do kodu (chcę umrzeć po raz drugi…)? Po wszystkim piszemy dokumentację końcową opisującą jakie zmiany zaszły w kodzie. Żeby nie było za łatwo, należy ją napisać na wzór poprzednich dokumentacji, które zupełnie nic nie mówią o tym co zostało zmienione. Znaczy nic nie mówią programistom, bo ten język to chyba tylko gryzi-ołówki na wysokich szczeblach rozumieją, którym trzeba tą samą informację powtórzyć w kilku różnych sekcjach których tytuły nie odpowiadają temu ani co zostało zmienione ani gdzie (chcę umrzeć po raz trzeci).
Wniosek: nic tylko podziwiać programistów. Pracują na marnym kodzie, piszą głupoty (bo inaczej się nie da) w dokumentacji, której nikt techniczny i tak później nie przeczyta, bo nie zawiera grama przydatnych informacji.
