Dlaczego kierownicy projektów to idioci?
Mój kierownik projektu naprawdę działa mi na nerwy. Matko Boska, o co znowu chodzi? Nie mogę się na niczym skupić - co pięć minut coś innego. Najpierw wysyła mi maila. Potem dzwoni, że wysłała mi e-mail. Dziesięć minut później słyszę powiadomienie ze Slacka - "tsst tytyty" i to znowu ona! Wszystko w ciągu pół godziny. Jeszcze jeden taki miesiąc i będę miał PTSD. Jak mogę robić cokolwiek produktywnego? Mam około 150 zgłoszeń w Jira do rozwiązania. Potrzebuję co najmniej 30 minut, aby złapać flow, ale przy tych wszystkich rozpraszaczach jest to prawie niemożliwe. Ale co osoba taka jak mój PM może o tym wiedzieć - potrzebujesz tylko dwóch aktywnych komórek mózgowych, aby nacisnąć przycisk "Prześlij dalej".
Dlaczego architekci IT to idioci?
Osoba, która zdecydowała się nazwać tych wielkich oszustów tytułem nawiązującym do pracy ludzi, którzy faktycznie wiedzą, jak projektować drapacze chmur lub mosty, musiała być pijana lub gorzej. Prawdziwi architekci muszą wiedzieć wiele rzeczy, np. obliczać naprężenia na ścianach nośnych, wiedzieć, gdzie umieścić kable elektryczne i gdzie szyby wentylacyjne, jaki balast zamontować i gdzie, aby zrównoważyć ruch wychylenia w drapaczach chmur, czy jak budować na obszarach o sporej aktywności sejsmicznej. Długo by wymieniać.
Z drugiej strony architekci IT niewiele wiedzą o czymkolwiek. Przez większość czasu rysują klocki i strzałki i spędzają mnóstwo czasu na dobieraniu kolorów do wspomnianych klocków. Wszystkie te rysunki są potrzebne jak rybie rower - połowa z nich nie ma prawie żadnego związku ze światem rzeczywistym, więc nikt nie traktuje ich poważnie i robi wszystko po swojemu. Gdy pojawiają się nowe wymagania, nasi "geniusze" rysują kolejne klocki i kolejne strzałki, nie sprawdzając nawet, w jaki sposób zostały zaimplementowane kolorowe klocki z poprzedniego rysunku. Tak powstają te "cudowne" systemy, do których można się zalogować tylko przy pełni księżyca, w ostatni piątek miesiąca.
Dlaczego programiści to idioci?
Mam marzenie, że każdy nowy projekt, który wykonujemy przy użyciu tych samych technologii, rozwiązując te same problemy biznesowe, będzie pewnym sukcesem. Jeśli wszystko jest takie samo, powinniśmy po prostu to zainstalować, może dokonać drobnych dostosowań (np. zmienić logo klienta) i czerpać korzyści. Ale nie - życie nie może być takie proste, przynajmniej nie z deweloperami.
Przychodzę do developerów, zmęczony procesem sprzedaży, ale szczęśliwy, że pozyskaliśmy nowy projekt do realizacji. Mówię z uśmiechem - "drużyno, jest nowa robota"! Zamiast radości widzę lekko uniesione brwi, więc próbuję powiększyć ich spokój mówiąc - "No stres - ten projekt to będzie bułka z masłem! Robimy prawie to samo co u poprzedniego klienta". No i oni zamiast wyrazu błogości na twarzy patrzą na mnie tym spojrzeniem żołnierza, który widział o jedną pacyfikację wioski za dużo.
Zaczynają narzekać, że to nie to samo, że muszą wdrożyć nową bibliotekę, nowy framework, stworzyć nowy DSL. Mówią, że to, co zostało zrobione wcześniej, to w zasadzie młody się uczył, jest nieoptymalne, a cały ten kod najlepiej wyrzucić do kosza na śmieci i nie dotkną go nawet 50-metrowym kijem.
Normalnie gdybyśmy robili w innym biznesie, np. byli stolarnią, każdy nowy projekt rozpoczynalibyśmy od wynalezienia nowego rodzaju młotka lub dłuta:
"- Dlaczego nie możemy użyć tego, którego używaliśmy wcześniej?"
"- Ponieważ tym razem potrzebujemy takiego z wbudowaną latarką."
"- Dlaczego nie możemy po prostu przykleić latarki do istniejącego młotka? I tak go wyrzucisz po zakończeniu projektu."
"- To nie zadziała, potrzebujemy wbudowanej latarki."
Zaczynamy więc budować całą linię produkcyjną młotków z wbudowanymi latarkami (może w przyszłości będziemy potrzebować ich więcej). "W przyszłości" - ha ha ha, to jest dobre, bardzo zabawne. Przy następnym projekcie będę miał inny "piękny umysł", który powie, że wszystkie te młotki z latarkami są naprawdę fajne, jeśli masz do dyspozycji baterie AAA. On jednak ma tylko baterie AA, więc musi zbudować nową (bo kupno odpowiedniego zestawu baterii ograniczyłoby jego kreatywność!!!). Żaden z nich nie zdaje się rozumieć, że zaspokajanie ich kreatywności poważnie szkodzi rentowności!
Dlaczego młodsi programiści to idioci?
Czy tytuł nie mówi wszystkiego? Nienawidzę pracować z juniorami. Ostatnio robiłem przegląd kodu i widzę "IFy" latające wszędzie. Wołam juniora, żeby przyszedł i grzecznie pytam: "Urodziłeś się głupi czy to nabyta umiejętność?". Przysięgam, że zacznę robić zdjęcia kodu, który piszą i wysyłać je do HRów, żeby mogli zobaczyć, kogo wpuszczają na obiekt. Dzięki wszystkim starym i nowym bogom, że nie tworzymy tutaj oprogramowania o krytycznym znaczeniu dla bezpieczeństwa. Skończyłoby się to karuzelą bagażową na lotnisku strzelającą walizkami do pasażerów albo jeszcze gorzej, gdybyśmy tworzyli oprogramowanie medyczne lub wojskowe.
Dlaczego DevOps / SysOps to idioci?
Mówię temu facetowi, że potrzebuję VPN site2site i potrzebuję go natychmiast. Powinien wiedzieć, jak to zrobić, nawet budząc się o 5 rano po nocnym wyjściu z chłopakami. Wygląda na to, że nie jest tego rodzaju SysOpsem. Mówi, że potrzebuje pięciu dni, aby zrobić to dobrze. Kolejne zadanie, kolejny "sukces":
"- Musimy zainstalować Jira w siedzibie klienta" - mówię mu.
"- Ale widzę, że to wymaga Javy. Nie znam Javy. Muszę to przemyśleć, przeczytać kilka instrukcji i obejrzeć kilka tutoriali na youtube. Czy jest jakiś łatwy instalator albo przynajmniej RPM?"
Jeszcze jedna taka rozmowa i zrobię komuś krzywdę. Gdyby całość wymagała bezmyślnego klikania next-next-next nie musiałbym zatrudniać wysoko przepłacanego eksperta, który szczyci się znajomością clouda, kubernetesa i innego sposobu na Alcybiadesa.
Dlaczego testerzy są idiotami?
Nawet nie zaczynaj ze mną tego tematu. Zapytasz ich "Ile to jest 2+2?", a oni odpowiedzą "To zależy", "Czy powinniśmy testować wszystkie przypadki brzegowe?", "Czy stół, na którym leży kartka z równaniem, to stolik kawowy czy stół operacyjny?". To są ludzie, którzy nie potrafią prowadzić normalnej rozmowy, zawsze szukają drugiego dna i trzeciej dziury w całym.
"- Zróbcie tak, żeby żadne błędy nie trafiły do produkcję" - mówię im.
"- Czy mamy specyfikację wymagań dla tego systemu, który mamy przetestować?"
"- Jest już prawie gotowa, mamy około 20%. Ale mogą być pewne zmiany."
"- Niee, to nawet nie ma sensu, żebyśmy czytali te dokumenty."
Nie mogę tak dłużej pracować. Wszyscy narzekają, że jest ciężko i nie mogą wykonywać swojej pracy z jakichś wymyślonych powodów. QA w dzisiejszych czasach mają zbyt łatwo. Dajesz im wszystko na srebrnej tacy, a i tak nie możesz oczekiwać, że cokolwiek zostanie zrobione. Muszę poprosić mojego terapeutę o większą dawkę Prozacu, bo inaczej nie dotrwam do końca roku.
Dlaczego analitycy biznesowi / systemowi to idioci?
Nasz nowy dostawca oprogramowania ma zbudować dla nas nowy, superwydajny i przyjazny użytkownikom system. Wysyła do mnie analityka, który ma spisać wymagania. Sprawdzę go szybko, czy wie cokolwiek o specyfice mojej pracy. Nie zgadniesz - zapytałem o proste rzeczy, takie jak ADR, AMT, EBIDTA, HSV, VfB a on NIC o nich nie wiedział!!! Jak mogę pracować z takimi ludźmi, jeśli nie znają przynajmniej 50 podstawowych pojęć związanych z moimi codziennymi zadaniami. Mówią, że są ekspertami w tworzeniu oprogramowania, a nie w księgowości. Mówią, że może nie znają co to ADR, AMT ale za to znają jakieś dziwne akronimy jak SQL, XML, HTML, SOAP, REST, SSO - jakby mnie to cokolwiek obchodziło.
Jestem miłosierną osobą. Łatwo zapominam. Postanowiłem nie rozwodzić się nad faktem, że zmarnowali mój cenny czas z powodu ich indolencji. Czy oni myślą, że rozmawianie z nimi to moje jedyne zajęcie??? No dobra, ale spróbujmy iść dalej z projektem. Daję im więc szczegółowe wymagania do nowego systemu. Mówię do analityka tak: "Stwórz mi system, który gromadzi wszystkie dane, dzięki czemu mogę je przeciągać i upuszczać oraz generować wszystkie raporty, których potrzebuję w mojej pracy". No mówię Wam - tłumaczę już jak krowie na rowie, prościej się nie da - żadna tam fizyka jądrowa.
Po tygodniu wracają z kolejnymi pytaniami. Normalnie zaraz nie wytrzymam - dlaczego w ogóle my im płacimy. Przysięgam, że gdybym nie miał pracy, nauczyłbym się tych wszystkich programistycznych rzeczy i sam bym to zrobił. Ehh, w dzisiejszych czasach nikt nic nie wie i nie chce wiedzieć, nie mówiąc o braniu na siebie jakiejkolwiek odpowiedzialności.
Dlaczego klienci są idiotami?
Największą tragedią w tym biznesie IT są klienci. Nie rozumiem, dlaczego wciąż ich potrzebujemy. Gdyby nie oni, tworzylibyśmy już systemy, które umieściłyby nas w 22 wieku - dobrze zaprojektowane, z najczystszym kodem, jaki można sobie wyobrazić. Gdyby nie klienci, mielibyśmy już latające samochody. A z tymi klientami zawsze coś nie tak, ciągle narzekają.
Jakiś drobiazg przestaje działać i nagle robi się atmosfera jak podczas II wojny światowej. "Rzuć cokolwiek robisz i leć to migiem naprawić". Czytam zgłoszenie w Jira i widzę, że to tylko błąd ortograficzny (w nagłówku na stronie głównej, ale nieważne). Rany, to nie tak, że ktoś mógłby ukraść pieniądze z kont bankowych ludzi - o co wielkie halo. Mówię ci, nie znoszę tych klientów. A najgorsze, że ostatnio mój kierownik powiedział mi, że to klienci płacą nam pensje. Nie obchodzi mnie to. Przysięgam - jeszcze jedna taka Jira i odchodzę. Założę biznes z food truckami. Będę z radością przerzucał hamburgery i sprzedawał je na ulicy. Albo zostanę psim groomerem. Tak czy inaczej na zawsze porzucę te całe programowanie i tą bzdurną branżę.