Pracuję jako programista i moim zadaniem miało być rozwijanie systemu informatycznego. System ten tworzony jest od około 1999 roku, więc można powiedzieć że ma on już swoje lata. Rzesze ambitnych programistów podobnych do mnie wylewało z siebie siódme poty, próbując zmusić krnąbrną aplikację do współpracy. Efektem tej krucjaty jest istny miszmasz archaizmów i nowoczesnych rozwiązań, mieszanka kodu napisanego w miarę dobrze i tego tworzonego pod presją zbliżającej się nieubłaganie linii śmierci. Ogólnie cyrk na kółkach, ale przynajmniej jest zabawnie.
Jakiś czas temu, zajęty ogarnianiem wszechobecnego syfu, jaki powstał po kolejnej awarii bazy danych, zdałem sobie sprawę, że podobne sytuacje od jakiegoś czasu powtarzają się niepokojąco często. Zainteresowany tematem, zagłębiłem się w starożytne pisma, zwane przez niektórych logami systemowymi, i rozpocząłem analizę bebechów w poszukiwaniu źródła problemu. Niestety mistyczne duchy bazy danych najwyraźniej wyczuły moją ingerencję w ich tajemne knowania. Kolejna awaria była istnym pierdo... Była bardzo poważna i administratorzy za cholerę nie mogli podnieść bazy na nogi. Wybuchła panika. Zapytacie o kopię zapasową. A co to jest kopia zapasowa, kto by się takimi pierdołami w ogóle przejmował? Po tygodniowej walce wiktoria, wszystko chyba działa.
Sytuacja ta dała zarządowi firmy co nieco do myślenia. Nasze wcześniejsze błagania o zatrudnienie kilku nowych pracowników były za każdym razem zbywane. Dajecie se jakoś radę? To po jaki wałek kręcicie temat? Tym razem zatrudniono pięciu nowych pracowników do działu IT. Czterech juniorów i ON. Dla ułatwienia sprawy nazwijmy go Mietek.
Mietek jest tak zwanym "Uber Senior Master Yoda Developerem". Serio, można mu zarzucić wiele, ale wiedzę chłop ma ogromną. I być może współpraca z nim nie byłaby taka zła, gdyby Miecio za punkt honoru nie obrał sobie przekształcenia naszego małego działu IT w trybik wielkiej maszyny zwanej korpo. I nie zrozumcie mnie źle, nie mam kompletnie nic do wielkich korporacji. Jednak nie zawsze systemy, które działają w przypadku licznej ekipy projektowej sprawdzą się w przypadku małego ośmioosobowego zespołu. Chociaż jeżeli w korpo odwalają się takie jaja, jakie Mietek zgotował nam, to ja chyba nie chcę pracować w korporacji. :)
Początek nie był aż tak zły. Miecio stwierdził, że zanim zacznie działać, musi poznać zarówno aplikację, jak i ekipę. Zrozumiałe. Sprowadzało się to do tego, że Mietek pół dnia siedział i dłubał coś w kodzie, przeklinając pod nosem. Natomiast drugie pół chodził między biurkami, podrzucając piłeczkę i raz po raz zadając irracjonalne pytania. Serio, skąd mam wiedzieć, co się stanie, jak zmienię warunek w metodzie klasy, którą ostatnio na oczy widziałem ponad pół roku temu. Dla zobrazowania debilizmu tego pytania: wyobraźcie sobie, że jesteście na plaży, zrobiliście babkę z piasku i nagle ktoś was pyta, czy to ziarenko piasku, na lewo od tego kamyczka, jest szare, czy brązowe...
Aż w końcu nadszedł dzień, gdy nasz nowy szef stwierdził, że już wszystko wie i zaczynamy działać. Hurra!
Plan był taki, że on będzie analizował kod i pisał, co i jak mamy zmienić, a my zajmiemy się gwałceniem klawiatur. Sensowne, ale:
- za wszystko dostawaliśmy gwiazdki lub czaszki (przedszkole wita).Osoba, która nazbierała najwięcej gwiazdek mogła (UWAGA!) wybrać sobie, czym będzie się zajmować w następnym tygodniu, natomiast najskuteczniejszy nekromanta w zespole dostawał najtrudniejsze zadanie.
- zadania (poza dwoma w/w przypadkami) były losowane z magicznego pudełka. Co z tego, że A świetnie znał daną część systemu, jeśli to B wylosował zadanie jej modyfikacji. A tylko spróbuj się zamienić!
- wygodne krzesła zostały wymienione na piłki. Ogólnie rozumiem, dobre to dla kręgosłupa, ale na niższe biurka do kompletu to chyba budżetu zabrakło.
- codziennie rano organizowane było spotkanie, które wyglądało następująco - Mietek rzucał piłkę do losowej osoby, a ta musiała natychmiast powiedzieć, co wczoraj robiła w pracy. Zawahałeś się chociaż sekundę, dostawałeś czaszkę.
- Mieciu lubił prowadzić tak zwane testy dyspozycyjności. Dostajesz maila od Mietka i nie odpisujesz w ciągu 20 sekund? Dostajesz czachę! Byłeś w kiblu na dwójce i nie odebrałeś telefonu od Miecia? CZACHA!
- Masz problem i chcesz skorzystać z wiedzy bardziej doświadczonego przełożonego? Cytat: "Google jest jak Bóg, znajdziesz tam wszystkie odpowiedzi.". To ja z szefem gadam, czy znowu na elektrodę wszedłem?
- Mieciu stwierdził, że załatwi nam książki, które na bank pomogą nam w pracy. Super! Z niecierpliwością czekamy na jakieś książki opisujące zaawansowane meandry języka, którego używamy. Dostajemy cztery pseudokołczingowe ścierwa a la "JESTEŚ ZWYCIĘZCĄ!" i poradnik podstaw języka. Super!
Było ciężko, ale jakoś wytrzymywaliśmy z męczącym szefuńciem. Nadszedł jednak dzień, w którym Mietek oznajmił nam, że zarząd jest niezadowolony i trzeba jak najszybciej napisać cały system od nowa, utrzymując w międzyczasie stary w jako takim porządku. Poza tym zagroził, że od teraz osoba z co najmniej pięcioma czaszkami może zapomnieć o premii, a delikwent z aż dziesięcioma czaszkami wyleci na zbity pysk. Postanowiliśmy przyśpieszyć trochę tę akcję i stara ekipa tego samego dnia złożyła wypowiedzenie.
Za kilka dni kończy nam się okres wypowiedzenia, a Mietek zostanie z czterema juniorami, którzy ledwo poruszają się po kodzie, zaczątkiem nowej aplikacji i dogorywającym trupem, który ledwo działa.
Powodzenia. :)
Świetne! :D
OdpowiedzSuper się czytało :D Czy Mietek jest z tych, co uważają, że 9 kobiet może urodzić dziecko w miesiąc? ;)
OdpowiedzZmodyfikowano 1 raz. Ostatnia modyfikacja: 10 maja 2018 o 23:11
Mam przeczucie, że Miecio może daleko zajść w korporacji, bo świetny z niego team leader, co to nie boi się wyzwań, jest kreatywny, organizuje spotkania motywacyjne dla pracowników. Ci z tego, że nie ma pojęcia, jak sprawnie zorganizować pracę. Ot, przerost formy nad treścią typowy dla wielu strategii marketingowych traktowanych wręcz jako wyrocznia. Poza tym, jak to czytam, to przypomina mi się ta historyjka, czyli jak rozpieprzyć zespół, który sprawnie funkcjonuje i wie, co robi. https://strefamanagera.wordpress.com/2012/10/14/odwrocona-piramida-czyli-historia-o-mrowce/
OdpowiedzŚwietny przykład zasady, że ludzi awansuje się tak długo, aż dojdą do poziomu który ich przerasta. Myślę że Mietek był świetnym programistą, i dlatego właśnie awansowano go wyżej. Ale można być świetnym programistą, a nie ogarniać organizacji pracy w zespole (tym bardziej jeżeli wcześniej pracował w miejscu gdzie był jedynym fachowcem), to zupełnie inne umiejętności.
Odpowiedz@JanMariaWyborow: Pełna zgoda. Do tego szokujące, że koleś próbował traktować jak dzieci ludzi w takiej branży, w której robota sama ich szuka.
OdpowiedzCo to za język programowania?
OdpowiedzSuper zareagowaliscie... ciekawe, czy go to czegokolwiek nauczy. Powodzenia w szukaniu nowej pracy ( jak to mowia najdluzsze pol godziny w zyciu programisty to to, w ktorym szuka pracy) :)
OdpowiedzMoim zdaniem nie nauczy. Zwali winę na tych którzy odeszli. Tak wewnętrzne, w swojej głowie. Że się nie odnaleźli we współczesnym zarządzaniu. Że są nieodpowiedzialni. Że nie umieją współpracować, sprostać wymaganiom itd. On w to wierzy.
Odpowiedz@bazienka: Myślę, że tu masz odpowiedź: https://strefamanagera.wordpress.com/2012/10/14/odwrocona-piramida-czyli-historia-o-mrowce/
OdpowiedzPracuję w korpo. To co opisano w historii to nie są zasady korpo. To są zasady debila.
Odpowiedz@greggor: problem polega na tym, że zbyt dużo debili pracuje i awansuje w korporacjach. Niestety, zasada Petera nadal obowiązuje ("W organizacji hierarchicznej każdy awansuje aż do osiągnięcia własnego progu niekompetencji")
OdpowiedzTeż jestem programistą. I z mojego punktu widzenia, piekielny jest nie tylko "guru", ale też Ty (lub Wy, w zależności kto odpowiadał wcześniej za całość). Brak kopii zapasowej, awaria którą ogarnialiście przez tydzień - to nie są małe błędy, to są olbrzymie błędy, przy których należałoby się zastanowić, czy obecne podejście ma w ogóle sens. Mówiąc krótko - ktoś tym beznadziejnie zarządzał. "raz po raz zadając irracjonalne pytania. Serio skąd mam wiedzieć co się stanie jak zmienię warunek w metodzie klasy" To nie jest irracjonalne pytanie. Ono jest bardzo dobre, pozwala szybko określić, czy znacie kod na którym pracujecie. Oczywiście, nikt nie będzie wiedział wszystkiego, ale jeśli na 10-20 pytań na żadne nie jesteś w stanie odpowiedzieć bez problemu, to raczej coś jest nie tak. Juniorom można to wybaczyć, bardziej zaawansowanym programistom już nie bardzo. "zadania (poza dwoma w/w przypadkami) były losowane z magicznego pudełka. Co z tego, że A świetnie znał daną część systemu" Dzięki temu masz szanse poznać cały kod. I nie będzie później sytuacji, gdy jedna osoba pójdzie na urlop, a reszta nie ma najmniejszego pojęcia o co chodzi w jakieś klasie, czy metodzie. "Mietek rzucał piłkę do losowej osoby a ta musiała natychmiast powiedzieć co wczoraj robiła w pracy." Może i nie jest to przyjemne, jeśli musisz od razu powiedzieć, ale z drugiej strony - wiedzieliście o tym, że co rano coś takiego będzie. Przecież to nie jest trudne, kilka minut przed spotkaniem sprawdzasz co robiłeś poprzedniego dnia (jeśli jakimś cudem tego nie pamiętasz) i jesteś w stanie bez problemu powiedzieć. "masz problem i chcesz skorzystać z wiedzy bardziej doświadczonego przełożonego? Cytat: "Google jest jak Bóg, znajdziesz tam wszystkie odpowiedzi."" Zależy co to były za pytania. Jeśli odpowiedzi można znaleźć bez problemu w google, to nie ma sensu pytać przełożonego. Tym bardziej że jeśli on dostaje takich pytań z 20 na dzień, to może mieć tego naprawdę dość.
Odpowiedz@Leone: To może po kolei :) Za bazę danych są odpowiedzialni administratorzy. My tylko pomagamy ogarnąć syf po kolejnych awariach. A brak kopii wynika z decyzji zarządu. My jako dział IT nie mamy sobie nic do zarzucenia gdyż już od dawna zgłaszaliśmy, że baza powoli dogorywa. Poza tym mimo, że nie leży to w moich kompetencjach starałem się znaleźć co się sypie. To były irracjonalne pytania, gdyż Mietka nie obchodziło co wiemy na temat danej klasy lub metody. On chciał już, natychmiast, bez możliwości spojrzenia w kod wiedzieć co dokładnie jest przechowywane w tej i tej zmiennej, itp. Przy mniejszych systemach da się to jeszcze jakoś ogarnąć, ale przy molochu, który my rozwijaliśmy jest niewykonalne to spamiętać. Poza tym sprawy nie ułatwiało niedbalstwo niepracujących już w firmie developerów. Po co się wysilać i nazwać zmienną np. $sumOfStateComponents jak można jeb*ąć $s. Tutaj się z tobą zgodzę, ale nie do końca. Rzeczywiście pomaga to poznać większą część systemu, ale tak jak już wspomniałem aplikacja była ogromna. O wiele lepiej sprawdzała się metoda: ty ogarniasz to, ja to a ten tamto. A jak któryś się zwolni tworzy dokumentację dla przyszłych pokoleń. Poza tym goniły nas deadline'y i przy takim losowaniu 50% czasu pracy to było wertowanie kodu by zrozumieć jego działanie i przeszkadzanie co chwile osobie, która się na tym zna. To akurat było najmniej piekielne z dziwactw Mietka. Jednak takie spotkanie zabierało około 20 min z rana gdzie tylko rzucaliśmy piłeczką, bo i tak pod koniec każdego dnia wysyłaliśmy Mietkowi krótkie raporty z postępu prac. Nie były to pytania typu: "Te stary a pamiętasz jak tablicę zrobić eee...?". Najczęściej dotyczyły one optymalizacji zapytań bazodanowych lub jak według niego optymalniej stworzyć strukturę klasy (dziedziczenia, interfejsy i inne pierdy).
Odpowiedz@Satsu: i tu sie klania nazywanie zmiennych, klas i metod jak najbardziej konkretnie, zeby po nazwie wiedziec, co ona robi ;) Czy Mietek mial jakiekolwiek pojecie o programowaniu, cyz udawal, ze ma?
Odpowiedz@bazienka: Ja to wiem, ty to wiesz, ale tak jak mówiłem system stary i z tego co wiem do dziś pracowało nad nim ponad 40 różnych osób. Poza tym idea czystego kody urodziła się stosunkowo niedawno. Kiedyś (lata bliżej 2000 roku) pisało się kod byle działał :D Natomiast Miecio cholera miał wiedzę, ale ludźmi zarządzać nie potrafił. A szkoda.
Odpowiedz@bazienka: Nazwy wskazujące na cokolwiek? A na co to komu? :P Na PWr jest mnóstwo wykładowców, którzy jako przykłady (w ich mniemaniu idealnego kodu) dają 10 linijek, w których rozszyfrowanie czegokolwiek zajmuje dobrą minutę-dwie: nazwa klasy A, B lub C, zmienne d, e, f, g, metody h, i, j, k. A teraz posadź na takich wykładach człowieka, który przed studiami nie miał żadnej styczności z programowaniem i uznaje takie nazewnictwo za jakiś standard - bo "oszczędzamy klawiaturę, palce i bajty na kod źródłowy". Dorzuć do tego standardy z końcówki lat 90. (bo o nowszych "doktorki nie słyszały") i przepis na katastrofalnego klepacza kodu gotowy. Pomijam już takie "pierdoły" jak wcięcia czy klamry na jednym poziomie (a nie 5 zamykających w jednej linii i weź tu ogarnij, która co zamyka - nawet z podświetleniem jest ciężko). Od jakiegoś czasu rozglądam się za jakąś pracą w swoim przyszłym zawodzie i dziwiło mnie częste pojawianie się w wymaganiach "dbanie o czystość kodu". Niedawno miałem okazję pomagać znajomym w projektach - i teraz w ogóle mnie takie wymagania nie dziwią. Połowa błędów w ich programach (które jakby nie było, wcale duże nie są - łącznie 1000-2000 linijek) to efekt kompletnego zignorowania zasad nazewnictwa (o wcięciach mało kto z nich słyszał), przez co sami się gubili. Taki trochę nie na temat komentarz wyszedł :/
Odpowiedz@kitusiek: Spoko, zmienne a,b,c to ja mialam na kursie w ramach tylko przykladu pisania logiki, nie ogarniam jak mozna ludzi takiej fuszerki uczyc ...
Odpowiedz@kitusiek: hehe widzę że PWr dalej trzyma poziom :) Chociaż to kiedyś zależało, na kogo się trafiło i wtedy zamiast takich enigmatycznych nazw ćwiczyło się notację węgierską :D
OdpowiedzLudzie mamy lekki pszypał. Okazało się, że Mietek czyta piekielnych. Nadal jednak nie wie kto dokładnie napisał tę historię :D Ps. Pozdro Mietek :)
Odpowiedz@Satsu: i nie dał "słabe" XD
Odpowiedz@Kamaiou: Może po prostu nie ma konta ;)
Odpowiedz@Satsu: Pytanie, czy to robił w godzinach pracy?
Odpowiedz@Satsu: Może właśnie to ten jeden co dał "słabe" :D A tak swoją drogą to może odrobina prawdy da mu do myślenia.
Odpowiedz1@Satsu: Ha ha ha! Witaj Mietku jak tam w pracy? :D
Odpowiedz@Satsu: To niech teraz opisze to ze swojej perspektywy! Lud Piekielnych domaga się chleba i igrzysk! Albo chociaż odrobinki dramy. :D
OdpowiedzObrazując pewną zasadę zarządzania, którą nam wyłuszczył profesor na wykładzie z zarządzania zasobami ludzkimi "Świetny mechanik samochodowy tzw. "złota rączka" niekoniecznie możne nadawać się do zarządzania ludźmi, czy kierowania firmą." Chociaż taki pracownik to skarb i powinien za odpowiednio wyższą pensje pracować i kontrolować robotę po innych, ale nie koniecznie ją organizowac.
OdpowiedzToć to jedna z najbardziej oczywistych prawd na świecie. Wiadomo, że bycie dobrym w A nie oznacza automatycznie bycia dobrym w B, nawet jeśli B jest powiązane z A. No, ale celebryci i inne osoby publiczne o tym nie wiedzą, i często wypowiadają się na tematy o których nie mają pojęcia.
OdpowiedzTak się w pracy powstrzymywałam od śmiechu, kiedy po raz kolejny czytałam o czaszkach, że aż mi łzy pociekły. Swoją drogą Mietek mi bardzo przypomina mojego znajomego programistę imieniem Marek :)
OdpowiedzZmodyfikowano 2 razy. Ostatnia modyfikacja: 14 maja 2018 o 13:12
>Serio, skąd mam wiedzieć, co się stanie, jak zmienię warunek w metodzie klasy. Hmm, Proste. W klasach dziedziczących z klasy xyz (inna zupełnie) metoda abc i uvw będą rzucały nieobsługiwanymi wyjątkami. Ta metoda odpowiadania na bzdurne pytania jest przydatna, niestety nie może być od czapy, wymaga wiedzy. >Dostajesz maila od Mietka i nie odpisujesz w ciągu 20 sekund? Overloading - umiejętność przychodzi z doświadczeniem. Ja zwykle reaguję tekstem: Chętnie, tylko powiedz co z tego co mam na tapecie jest nieważne i mogę odłożyć. Jaki kierownik przyzna się, że nie wie co robisz i że zlecił nieważne zadania?
Odpowiedz@vezdohan: A co powiesz na kierownika odpowiadającego "ty nie cwaniakuj, tylko zajmij się tym teraz, natychmiast"?
OdpowiedzCzytam to już drugi raz i nieodmiennie się zachwycam tym, z jakim kunsztem napisana jest ta historia - jestem kompletnym laikiem w tematach IT, a tu dzięki precyzyjnym porównaniom do analogicznych przykładów z bardziej znanych dziedzin wszystko rozumiem i mogę w pełni czerpać przyjemność z tego co czytam.
OdpowiedzŚwietna i bardzo dobrze napisana historia!
Odpowiedz