Ten artykuł zawiera ohydne, ze wszech miar odrażające, do granic podłości bezczelne lokowanie produktu.
Przełom 1999/2000. Turbo Pascal się skończył. Okazało się, iż 640 kB to jednak za mało, a Windows 95, wbrew przewidywaniom mojego CTO/CEO/CFO/CMO w jednej osobie, zachwycił odbiorców swoją wygodą, funkcjonalnością i ogólnym “look’n’feel”. I nikt się nie przejmował tym, iż do zrobienia tego samego w arkuszu kalkulacyjnym potrzebują teraz zabójczego Pentium z 4 MB RAM. Podsumowując: ludzie chcieli okienek, a nie MS-DOS.
Gdzieś w tym czasie przez przypadek, serię niepowiązanych ze sobą wydarzeń oraz kilka drobnych, acz moralnie uzasadnionych kłamstewek i niedopowiedzeń (wiecie rodzina, człowiek po studiach, dzieci w planach, nie takie kłamstwa ludzkość usprawiedliwiała), zdobywam swoją pierwszą pracę w Java. Na dobre i na złe.
Jest nas 20 ( a może 30?), klepiemy w Emacs, kompilujemy z make, na produkcji mamy SPARC i Solaris. Mamy Agile, ale my to nazywamy “programming motherfucker” (ktoś później zrobi koszulki, stronę, manifest i hasj). Jaramy się jak wyschnięte łąki na wiosnę. Robimy aplikację webową w Apache Cocoon, XML wydaje się przyszłością, a XSLT jutrzenką rewolucji, która nadchodzi. W domu nie mam internetu. Do pracy przychodzę z dyskiem, wsuwam w kieszeń i ściągam internet na wieczór do poczytania. 🙂
Startuje nowy projekt. Po kilku miesiącach, zostaję senior developerem, bo trzeba mnie opakować i ładnie sprzedać nowemu klientowi w UK. kilka się od tego czasu zmieniło. Wysyłają mnie na delegację. Pierwszy zagraniczny wyjazd w życiu. Matka w panice, babcia omdlewa na hasło, iż będę leciał czymś metalowym ze skrzydłami nad bezkresem Bałtyku ( czy też innego akwenu, z punktu widzenia babci to nie miało znaczenia). Trafiam do firmy, gdzie ludzie kod wysyłają sobie mailem. W CC zawsze jest nasz “configuration manager”, czyli “senior merge wizard”. Nie pytajcie co on robił z tym kodem…
Dobra sami chcieliście. Wczytuje do swojego IDE (Visual Age for Java, jedyna licencja na firmę) i robił za git i Jenkinsa – taka wersja białkowa (białkowo etanolowa, był Szkotem). Wysyła nam potem “jar” do sprawdzenia.
To wszystko trwa, zajmuje czas, generuje masę frustracji i agresji. I tu wchodzę ja ze swoją młodzieńczą wiarą w potrzebę zmian, rewolucji, rozwalenia układu, zniszczenia kasty senior developerów i configuration managera. Władza w ręce ludu. Każdy może zbudować projekt sam. Każdy ma prawo zmienić kod według swoich potrzeb. Ależ ja wtedy wierzyłem w to, iż ludzie są bytami kierującymi się logiką i zasadą zmniejszenia pracy przy jednoczesnej maksymalizacji zysków. Po 20 latach już wiem, iż ludzie najchętniej kierują się zasadą zmniejszenia pracy przy jednoczesnej maksymalizacji swego ego, ale to temat na inny post.
Proponuję żeby wrzucić nasz kod do CVS i napisać solidnego Makefile (SVN pojawił się jakieś 2-3 tygodnie po tym spotkaniu, Ant niedługo później, ale kto to pamięta).
“We don’t do things this way here”,”why change? it works”,”it will slow us down”, “we don’t have time for this shit”. Klasyka. Nic się nie zmieniło. Słyszę to ciągle na konferencjach, przy wódce podczas afterów, na meetupach.
Wracam do kraju. Na drugi dzień trafiam na dywanik do CEO. “Jarek, to są nasi klienci. I to, iż przeklinasz po polsku nie oznacza, iż oni nie rozumieją. A nazwanie project managera skończonym pajacem nie pomaga nam w budowaniu długotrwałych relacji biznesowych”.
(I tu się muszę zgodzić. Jakiś czas później zamknęli firmę nie informując nas choćby łaskawie, iż wypłata za ostatnie 3 miesiące nie przyjdzie). Jaki jest sens w tym przydługim wstępie?
Kolejne firmy, kolejne projekty. Chcemy więcej, dalej, mocniej, szybciej. Czas jest zasobem nieskończonym, jednak ilość pracy którą my, zespoły, organizacje, procesory, “chmury” jesteśmy w stanie wykonać w jednostce czasu, jest ograniczona. Dlatego próbujemy ten problem rozwiązać zatrudniając jeszcze więcej, skalując na jeszcze więcej maszyn.
Nasza branża mknie jak oszalała do przodu. Coraz szybsze maszyny, coraz lepsze narzędzia. Wydaje mi się, iż prędkość, wydajność jest tym co nakręca branżę. Szybcy i wściekli. 4 rdzenie, 8 rdzeni, 64 rdzenie, CI/CD, Agile (miało być szybciej, ale w wielu przypadkach wyszło jak wyszło), JIT, G1, Shenandoah, wojna IDE na czas startu (serio, to jest ten problem, który chcemy rozwiązać, no chyba, iż musisz co chwilę restartować IDE bo się zawiesza).
Tym co nas kręci jest prędkość, wiatr w bajtach. Na różnych poziomach. Wydajniejsze zespoły, wydajniejszy ja sam (a Ty ile skrótów klawiszowych nauczyłeś się dziś?), wydajniejszy kod, wydajniejsze systemy.
Może żyję w jakiejś bańce, którą sam sobie zbudowałem i sam się w niej zamknąłem. Uważam, iż wszyscy, devops, testerzy, agile coache, programiści, gdzieś na końcu mierzymy swój sukces tym jak szybko, wydajnie, efektywnie udało nam się dostarczyć. Jak szybki i wydajny system wyszedł spod naszych zgrabiałych i męczonych artretyzmem palców.
Wydaje mi się, iż dostarczyć to tylko część sukcesu – czasami najtrudniejsza do osiągnięcia.
Jednak duma nas rozpiera gdy każdy następny element układanki dostarczamy szybciej, kod topi “pipeline” w procesorach, a z klawiatur wylewa się ciekły krzem (dobra, poniosło mnie).
Czasami warto w tym pędzie zatrzymać się na chwilę i porozmawiać z innymi. Posłuchać jak inni optymalizują siebie, swoje zespoły, swój kod.
Chciałbym aby wydajność i efektywność była tematem przewodnim tegorocznej edycji SegFault Unconference. Spotkajmy się w Krakowie, by pogadać o optymalizacji przez wszystkie warstwy, od organizacji, przez zespoły, nas samych i nasz kod.
Mam już w głowie kilka nazwisk, które mają piękne historie. Bo to jest najważniejsze w SegFault. Historie i ludzie. Dokumentację do frameworka, znajdziesz w Google, o brakach w dokumentacji poczytasz na StackOverflow.
Drugiego dnia, robimy open space unconference. Po tych wszystkich ciepłych i pełnych zachwytów słowach po naszej ubiegłorocznej edycji, nie możemy wam tego nie zrobić. Drugi dzień wyrwie Was z Waszych foteli lub z kapci, jeżeli pracujecie przy stojącym biurku. Zaglądajcie na naszą stronę, bo już za chwilę pojawią się pierwsze nazwiska.
