hacker vs inżynier i znów metro bez spodni

Witam ponownie po przydługiej przerwie spowodowanej lenistwem:) dzisiejszy post z tytułu obserwacje dziwnej treści.
Przyszedł nowy rok, przyszły nowe postanowienia. Okazuje się, że jednym z najbardziej promowanych postanowień na nowy rok jest nauczenie się …. kodowania. Tutaj podlinkuje artykuł. Właściwie nie wiem czy powinienem się cieszyć, czy też może akurat płakać. No zobaczymy co życie przyniesie. Mam na szczęście wrażenie, że z nauczeniem programowania jest jeszcze trudniej niż z chodzeniem na siłownię, więc Ci którzy będą mieli jednak to samozaparcie mogą się okazać dobrym dodatkiem do społeczności. Ale wracając do tematu.

Pracując tam gdzie pracuję zauważyłem dwa typy ludzi. Bardzo specyficznych ludzi. Hackerzy. Wbrew pozorom nie są to ludzie włamujący się w wolnych chwilach do pentagonu, albo łamiący zabezpieczenia transakcji giełdowych i kont internetowych, przegryzając pizzę i zmieniając system świateł w nowym jorku. Nie tym zajmują się inni ludzie. Zatrudnieni w pewnych firmach. Oni są ekspertami od bezpieczeństwa i konstrukcji systemów. Niektórzy bronią, inni atakują. Taka różnica. Hackerzy, z kolei, potrafią coś bardzo szybko sklecić na poczekaniu co …. działa. I robi mniej więcej to co miało robić. Innymi słowy potrafią zrobić coś prototypopodobnego co działa trochę lepiej, nawet się jakoś skaluje i jest dobre… na jakiś czas. Umieją odsunąć problem w przyszłość, albo szybko zrobić demo jakiegoś rozwiązania. w całości, albo w dużym fragmencie. Niejednokrotnie są bardzo błyskotliwi ale nigdy nie zajmują się faktem, czy ich rozwiązanie będzie działać 3-5 i więcej lat później. Bo przecież do tego czasu wymyślą coś innego. Nie wnikają w szczegóły platformy bo najczęściej nie ma takiej potrzeby. Zawsze się znajdzie ktoś kto problem rozwiązał (w googlach, firmie, etc). Nie ma co czasu tracić na zbyt dużo wiedzy, bo technologia przeterminuje się szybko, a ja muszę zawsze być na leading edge. A jeśli będzie trzeba to rozwiązanie zmienić. Nie ma problemu. JEst przecież w jego głowie. A jeśli to nie on będzie zmieniał. Też nie ma problemu, a raczej to nie jest jego problem. Można go porównać do takiego playboya programowania. Coś zaczyna, działa to, będzie działać, bo inni potem to będą utrzymywać, zmieniać, a on już będzie wymyślał nowe rzeczy. Bo nowe rzeczy sprawiają mu przyjemność. Stare jest złe, niefajne, i ogólnie lepiej tego nie dotykać.

Po drugiej stronie stają inżynierowie. Goście co to zęby zjedli na czymś, zanim coś poważnego zrobią, muszą sobie narysować, popróbować, przedyskutować. Są defensywni, wiedzą, że jak coś nie będzie działać, to oni potem będą musieli to poprawić, ludzie będą na nich krzyczeć, że to ich wina, i w ogóle, przecież soft ma działać długo i bezawaryjnie, a to jest…. trudne.Goście którzy, chcą zrobić system, który będzie działał dla 100 użytkwonikó, ale jak będzie trzeba to i dla miliona. Z natury ostrożni, nie obiecują za wiele, trudno ich kupić wielkimi wizjami, wiedzą, że wielkie rzeczy można zbudować, ale najczęściej po drodze, ze dwa razy trzeba będzie sporo zmieniać. Nienawidzą czytać kodu innych hackerów, bo muszą zaśmiecać swój umysł niepotrzebnymi zależnościami, pamiętać jakieś głupoty i generalnie boli ich od tego głowa. Najchętniej chcieliby, żeby wszystko było rozdzielone, modularne i pluginowane a części można było wymieniać jak obudowy nokii. Wiedzą, że taki kod działa pięknie i najczęściej szybko (z niewielkim overheadem) i zawiera pewną ilość magii, której poza nimi nikt nie rozumie. Na pytanie jak to debugować, mówią po co, przecież testy pokazują że nie trzeba:) Dostarczają w terminach, najczęściej dłuższych niż hackerzy, ale zmiany w takich systemach najczęściej przychodzą szybciej. Najlepiej im się gada z innymi inżynierami;)

W rzeczywistości najczęściej wygląda to tak, że pierwsze linie kodu w systemach budowane są przez hackerów, bo trzeba prezentację, demo dostarczyć na już i byleby się nie wywalało. Potem jak stopniowo soft dojrzewa i powstaje coraz większa liczba lista życzeń do produktu, ktoś (najczęściej twórca czyli CTO), że przydałby sie jakiś proces, jakaś przewidywalność większa elastyczność. Ale hackerzy nie chcą zmieniać swoich dróg, stopniowo więc mixowani są z inżynierami. I choć obie grupy są utalentowanymi inżynierami współpraca przebiega ciężko. Czy tak musi być? Chyba tak, bo cechy tworzące dobrych hackerów (którzy umieją coś hack together) są inne niż dobrych inżynierów. Można się pokusić, że duże firmy potrzebują i takich i takich ludzi. Google na przykład wyrzuca nieprzeciętne ilości wykonanej przez swoich programistów pracy, licząc, że jak coś już zadziała, to będzie po prostu multi bilion dollar business (no bo jak inaczej przy tej skali). W USA hackerów darzy się wielkim szacunkiem, niejednokrotnie przypisując im cechy wielkich inżynierów. A tak naprawdę kombinacja tych dwóch rodzajów, jest niezwykle rzadka. U nas z kolei dużo bardziej ceni się inżynierów. Powoduje to jednak wielki strach przed innowacyjnymi projektami, bo inżynier zwyczajnie nienawidzi wyrzucać swoich dzieł na śmietnik.

I tak pojedynek trwa. NA pytanie kim ja jestem?… chyba bardziej jednak inżynierem, choć kiedyś byłem bardziej hackerem (studia to wymuszały).

Poza tym dzisiaj odbył się kolejny, coroczny przejazd metrem bez spodni. Aura akurat byłą sprzyjająca +10 stopni, można więc spokojnie było zdjąć spodnie. Podobnie jak w zeszłym roku, frekwencja dopisała. Z różnych źródeł słyszałem, że akcja odbyła się w tym roku również w Warszawie. Ktoś coś może opowiedzieć. Czy było to dla Was śmieszne, podobało sie, a może wzięliście udział?:)
pozdrawiam
nerd