Patrzę na kawałek kodu. To może być najgorszy kod, jaki kiedykolwiek widziałem. Aby zaktualizować tylko jeden rekord w bazie danych, pobiera wszystkie rekordy w kolekcji, a następnie wysyła żądanie aktualizacji do wszystkich rekordów w bazie danych, nawet tych, które nie wymagają aktualizacji. Istnieje funkcja map, która po prostu zwraca przekazaną jej wartość. Istnieją testy warunkowe dla zmiennych o najwyraźniej tej samej wartości, tylko nazwanych w różnych stylach (firstName и first_name). W przypadku każdej AKTUALIZACJI kod wysyła komunikat do innej kolejki, która jest obsługiwana przez inną funkcję bezserwerową, ale która wykonuje całą pracę dla innej kolekcji w tej samej bazie danych. Czy wspomniałem, że ta bezserwerowa funkcja pochodzi z opartej na chmurze „architektury zorientowanej na usługi” zawierającej ponad 100 funkcji w środowisku?
Jak w ogóle można było to zrobić? Zakrywam twarz i wyraźnie płaczę przez śmiech. Koledzy pytają, co się stało, a ja opowiadam to w barwach Najgorsze hity BulkDataImporter.js 2018. Wszyscy kiwają mi ze współczuciem głowami i zgadzają się: jak mogli nam to zrobić?
Negatywność: narzędzie emocjonalne w kulturze programisty
Negatywność odgrywa ważną rolę w programowaniu. Jest osadzony w naszej kulturze i służy do dzielenia się tym, czego się nauczyliśmy („nie musisz uwierzysz w to, jaki był ten kod!”), wyrażać współczucie poprzez frustrację („Boże, DLACZEGO to robisz?”), popisywać się („Nigdy bym tak tego nie zrobił”), zrzucić winę na kogoś innego („ponieśliśmy porażkę z powodu jego kodu, którego nie da się utrzymać”) lub, jak to jest w zwyczaju w najbardziej „toksycznych” organizacjach, kontrolować innych poprzez poczucie wstydu („O czym w ogóle myślałeś?”? Poprawnie”).
Negatywność jest tak ważna dla programistów, ponieważ jest bardzo skutecznym sposobem przekazywania wartości. Kiedyś uczestniczyłem w obozie programistycznym i standardową praktyką zaszczepiania wśród studentów kultury przemysłu było hojne dostarczanie memów, opowiadań i filmów, z których najpopularniejsze wykorzystywały . Dobrze jest móc używać narzędzi emocjonalnych do identyfikowania Dobrego, Złego, Brzydkiego, Nie rób tego, Nigdy. Nowicjuszy trzeba przygotować na to, że prawdopodobnie zostaną źle zrozumiani przez kolegów, którzy są daleko od IT. Że ich przyjaciele zaczną sprzedawać im pomysły na aplikacje warte milion dolarów. Że będą musieli przemierzać niekończące się labirynty przestarzałego kodu z bandą minotaurów tuż za rogiem.
Kiedy po raz pierwszy uczymy się programować, nasze zrozumienie głębi „doświadczenia programowania” opiera się na obserwacji reakcji emocjonalnych innych ludzi. Widać to wyraźnie po postach w , gdzie spędza czas wielu początkujących programistów. Wiele żartów jest w takim czy innym stopniu zabarwionych różnymi odcieniami negatywności: rozczarowaniem, pesymizmem, oburzeniem, protekcjonalnością i innymi. A jeśli to nie wydaje Ci się wystarczające, przeczytaj komentarze.
Zauważyłem, że w miarę zdobywania doświadczenia programiści stają się coraz bardziej negatywnie nastawieni. Początkujący, nieświadomi czekających ich trudności, zaczynają z entuzjazmem i chęcią wiary, że przyczyną tych trudności jest po prostu brak doświadczenia i wiedzy; i w końcu zostaną skonfrontowani z rzeczywistością.
Czas mija, zdobywają doświadczenie i potrafią odróżnić dobry kod od złego. A kiedy nadchodzi ten moment, młodzi programiści odczuwają frustrację związaną z pracą z wyraźnie złym kodem. A jeśli pracują w zespole (zdalnie lub osobiście), często przejmują nawyki emocjonalne bardziej doświadczonych kolegów. Często prowadzi to do wzrostu negatywizmu, ponieważ młodzi ludzie mogą teraz w przemyślany sposób rozmawiać o kodzie i dzielić go na zły i dobry, pokazując w ten sposób, że „wiedzą”. To jeszcze bardziej wzmacnia negatyw: w wyniku rozczarowania łatwo jest dogadać się z kolegami i stać się częścią grupy; krytykowanie Złego Kodu podnosi Twój status i profesjonalizm w oczach innych: .
Zwiększanie się negatywizmu niekoniecznie jest czymś złym. Dyskusje na temat programowania są między innymi niezwykle skupione na jakości napisanego kodu. To, czym jest kod, całkowicie definiuje funkcję, jaką ma pełnić (pomijając sprzęt, sieć itp.), dlatego ważne jest, aby móc wyrazić swoją opinię na temat tego kodu. Prawie wszystkie dyskusje sprowadzają się do tego, czy kod jest wystarczająco dobry i do potępiania samych przejawów złego kodu w kategoriach, których emocjonalna konotacja charakteryzuje jakość kodu:
- „W tym module jest wiele niespójności logicznych, jest to dobry kandydat do znacznej optymalizacji wydajności”.
- „Ten moduł jest dość zły, musimy go zrefaktoryzować”.
- „Ten moduł nie ma sensu, należy go napisać od nowa.”
- „Ten moduł jest do niczego, trzeba go załatać.”
- „To kawałek pamięci RAM, a nie moduł, w ogóle nie musiał być pisany, co do cholery myślał jego autor.”
Swoją drogą, to właśnie to „emocjonalne uwolnienie” sprawia, że programiści nazywają kod „seksownym”, co rzadko jest sprawiedliwe – chyba że pracujesz w PornHub.
Problem w tym, że ludzie są dziwnymi, niespokojnymi, emocjonalnymi stworzeniami, a postrzeganie i wyrażanie wszelkich emocji nas zmienia: początkowo subtelnie, ale z czasem dramatycznie.
Niespokojna, śliska równina negatywności
Kilka lat temu byłem nieformalnym liderem zespołu i przeprowadziłem wywiad z programistą. Naprawdę go polubiliśmy: był mądry, zadawał dobre pytania, znał się na technologii i dobrze wpasował się w naszą kulturę. Byłem pod szczególnym wrażeniem jego pozytywnego nastawienia i jego przedsiębiorczości. I zatrudniłem go.
Pracowałem wtedy w firmie już kilka lat i czułem, że nasza kultura pracy nie jest zbyt efektywna. Przed moim przyjazdem próbowaliśmy wypuścić produkt dwa, trzy i jeszcze kilka razy, co wiązało się z dużymi wydatkami na przeróbki, podczas których nie mieliśmy nic do pokazania poza długimi nocami, napiętymi terminami i działającymi produktami. I choć nadal ciężko pracowałem, byłem sceptyczny co do ostatniego wyznaczonego nam przez kierownictwo terminu. I przeklinał mimochodem, omawiając niektóre aspekty kodu z moimi kolegami.
Nie było więc zaskakujące – chociaż byłem zaskoczony – że kilka tygodni później ten sam nowy programista powiedział te same negatywne rzeczy co ja (łącznie z przekleństwami). Zdałem sobie sprawę, że zachowywałby się inaczej w innym towarzystwie, o innej kulturze. Po prostu dostosował się do kultury, którą stworzyłem. Ogarnęło mnie poczucie winy. Ze względu na moje subiektywne doświadczenie zaszczepiłem pesymizm w przybyszu, którego postrzegałem jako zupełnie innego. Nawet jeśli naprawdę taki nie był i tylko udawał, że może się dopasować, narzuciłam mu swoje gówniane podejście. A wszystko, co zostało powiedziane, nawet w żartach lub mimochodem, w zły sposób zamienia się w to, w co się wierzy.
Negatywne sposoby
Wróćmy do naszych byłych programistów, którzy zdobyli trochę mądrości i doświadczenia: lepiej poznali branżę programistyczną i zrozumieli, że zły kod jest wszędzie, nie da się go uniknąć. Dzieje się tak nawet w najbardziej zaawansowanych firmach nastawionych na jakość (a zaznaczę: widocznie nowoczesność nie chroni przed złym kodem).
Dobry scenariusz. Z biegiem czasu programiści zaczynają akceptować fakt, że zły kod jest rzeczywistością oprogramowania i że ich zadaniem jest jego ulepszanie. I że jeśli złego kodu nie da się uniknąć, to nie ma sensu robić z tego powodu zamieszania. Podążają ścieżką zen, koncentrując się na rozwiązywaniu problemów lub zadań, które przed nimi stoją. Uczą się, jak dokładnie mierzyć jakość oprogramowania i przekazywać ją właścicielom firm, sporządzać uzasadnione szacunki w oparciu o swoje wieloletnie doświadczenie, a ostatecznie otrzymują hojne nagrody za swoją niesamowitą i stałą wartość dla firmy. Wykonują swoją pracę tak dobrze, że otrzymują 10 milionów dolarów premii i przechodzą na emeryturę, aby robić, co chcą przez resztę życia (proszę nie brać tego za pewnik).
Innym scenariuszem jest ścieżka ciemności. Zamiast akceptować zły kod jako coś nieuniknionego, programiści biorą na siebie obowiązek wytykania wszystkiego, co złe w świecie programowania, aby móc to przezwyciężyć. Odmawiają poprawy istniejącego złego kodu z wielu dobrych powodów: „ludzie powinni wiedzieć więcej i nie być tacy głupi”; „to jest nieprzyjemne”; „to jest złe dla biznesu”; „to dowodzi, jaki jestem mądry”; „jeśli nie powiem, jaki to kiepski kod, cała firma wpadnie do oceanu” i tak dalej.
Z pewnością niezdolni do wprowadzenia zmian, których chcą, ponieważ firma niestety musi się rozwijać i nie może tracić czasu na martwienie się o jakość kodu, ci ludzie zyskują reputację narzekaczy. Zatrzymują się ich ze względu na wysokie kompetencje, ale są spychani na margines firmy, gdzie nie będą drażnić wielu osób, a nadal będą wspierać działanie krytycznych systemów. Bez dostępu do nowych możliwości rozwoju tracą kompetencje i przestają sprostać wymaganiom branży. Ich negatywizm zamienia się w gorzką gorycz, w wyniku czego karmią swoje ego, kłócąc się z dwudziestoletnimi studentami o podróż, jaką odbyła ich ulubiona stara technologia i dlaczego wciąż jest tak popularna. Przechodzą na emeryturę i dożywają starości, przeklinając ptaki.
Rzeczywistość prawdopodobnie leży gdzieś pomiędzy tymi dwiema skrajnościami.
Niektóre firmy odniosły ogromny sukces w tworzeniu wyjątkowo negatywnej, wyspiarskiej kultury o silnej woli (jak Microsoft wcześniej ) – często są to firmy posiadające produkty idealnie wpasowane w rynek i potrzebę jak najszybszego rozwoju; lub firmy z hierarchią dowodzenia i kontroli (Apple w najlepszych latach Jobsa), w których każdy robi, co mu każą. Jednak współczesne badania biznesowe (i zdrowy rozsądek) sugerują, że maksymalna pomysłowość, która prowadzi do innowacyjności w firmach i wysokiej produktywności u jednostek, wymaga niskiego poziomu stresu, aby wspierać ciągłe kreatywne i metodyczne myślenie. Niezwykle trudno jest wykonywać kreatywną pracę opartą na dyskusjach, jeśli ciągle martwisz się tym, co Twoi współpracownicy będą mieli do powiedzenia na temat każdej linijki Twojego kodu.
Negatywność to inżynieria popkultury
Dziś na postawę inżynierów zwraca się większą uwagę niż kiedykolwiek wcześniej. W organizacjach inżynierskich obowiązuje zasada „„. Na Twitterze pojawia się coraz więcej anegdot i historii o osobach, które odeszły z tego zawodu, ponieważ nie mogły (nie chciały) dalej znosić wrogości i złej woli wobec osób z zewnątrz. Nawet Linusa Torvaldsa lata wrogości i krytyki wobec innych twórców Linuksa - doprowadziło to do debaty na temat skuteczności tego podejścia.
Niektórzy nadal bronią prawa Linusa do bycia bardzo krytycznym – ci, którzy powinni dużo wiedzieć o zaletach i wadach „toksycznej negatywności”. Tak, uprzejmość jest niezwykle ważna (wręcz fundamentalna), ale jeśli podsumujemy powody, dla których wielu z nas pozwala, aby wyrażanie negatywnych opinii zamieniło się w „toksyczność”, to powody te wydają się paternalistyczne lub młodzieńcze: „zasługują na to, bo są idiotami” „, „musi być pewien, że więcej tego nie zrobią”, „gdyby tego nie zrobili, nie musiałby na nich krzyczeć” i tak dalej. Przykładem wpływu reakcji emocjonalnych lidera na społeczność programistów jest akronim społeczności Ruby MINASWAN – „Matz jest miły, więc jesteśmy mili”.
Zauważyłem, że wielu zagorzałych zwolenników podejścia „zabić głupca” często bardzo dba o jakość i poprawność kodu, utożsamiając się ze swoją pracą. Niestety często mylą twardość ze sztywnością. Wada tego stanowiska wynika z prostego, ludzkiego, ale bezproduktywnego pragnienia poczucia wyższości nad innymi. Ludzie zanurzeni w tym pragnieniu utknęli na ścieżce ciemności.
Świat programowania rozwija się dynamicznie i napiera na granice swojego kontenera – świata nieprogramowania (a może świat programowania jest kontenerem na świat nieprogramowania? Dobre pytanie).
W miarę jak nasza branża rozwija się w coraz szybszym tempie, a programowanie staje się coraz bardziej dostępne, dystans między „technologami” a „normalnymi” szybko się zmniejsza. Świat programowania jest coraz bardziej narażony na interakcje międzyludzkie ludzi, którzy dorastali w izolowanej kulturze nerdów wczesnego boomu technologicznego i to oni będą kształtować nowy świat programowania. I niezależnie od argumentów społecznych czy pokoleniowych, efektywność w imię kapitalizmu będzie widoczna w kulturze firmy i praktykach zatrudniania: najlepsze firmy po prostu nie zatrudnią nikogo, kto nie potrafi zachować neutralnego kontaktu z innymi, nie mówiąc już o dobrych relacjach.
Czego nauczyłem się o negatywności
Jeśli pozwolisz, aby zbyt dużo negatywności kontrolowało Twój umysł i interakcje z ludźmi, zamieniając się w toksyczność, jest to niebezpieczne dla zespołów produktowych i kosztowne dla biznesu. Widziałem (i słyszałem o) niezliczonych projektach, które się rozpadły i zostały całkowicie odbudowane wielkim kosztem, ponieważ jeden zaufany programista miał pretensje do technologii, innego programisty, a nawet do pojedynczego pliku wybranego do reprezentowania jakości całej bazy kodu.
Negatywność również demoralizuje i niszczy relacje. Nigdy nie zapomnę, jak kolega mnie zbeształ za umieszczenie CSS w złym pliku, zdenerwowało mnie to i nie pozwoliło zebrać myśli przez kilka dni. A w przyszłości raczej nie pozwolę takiej osobie przebywać w pobliżu jednego z moich zespołów (ale kto wie, ludzie się zmieniają).
Na koniec negatyw .
Myślę, że tak powinien wyglądać mistrzowski kurs o uśmiechu.
Nie jest to oczywiście argument za promienieniem szczęścia, wstawianiem dziesięciu miliardów emotikonów do każdego pull requestu czy pójściem na mistrzowski kurs z uśmiechu (nie, cóż, jeśli tego właśnie chcesz, to nie ma problemu). Negatywność jest niezwykle ważną częścią programowania (i życia ludzkiego), sygnalizującą jakość, pozwalającą wyrażać uczucia i współczuć bliźnim. Negatywność wskazuje na wnikliwość i rozwagę, głębokość problemu. Często zauważam, że deweloper wszedł na nowy poziom, kiedy zaczyna wyrażać niedowierzanie w to, czego wcześniej był nieśmiały i niepewny. Ludzie wykazują się rozsądkiem i pewnością siebie w swoich opiniach. Nie można odrzucić wyrażenia negatywizmu, byłoby to orwellowskie.
Jednak negatywność należy dozować i równoważyć innymi ważnymi cechami ludzkimi: empatią, cierpliwością, zrozumieniem i humorem. Zawsze możesz powiedzieć komuś, że schrzanił sprawę, bez krzyku i przekleństw. Nie lekceważ tego podejścia: jeśli ktoś bez emocji powie Ci, że poważnie schrzaniłeś, jest to naprawdę przerażające.
Wtedy, kilka lat temu, rozmawiał ze mną dyrektor generalny. Omówiliśmy aktualny status projektu, po czym zapytał, jak się czuję. Odpowiedziałem, że wszystko w porządku, projekt postępuje, pracujemy powoli, może coś przeoczyłem i trzeba to przemyśleć. Powiedział, że słyszał, jak dzieliłem się bardziej pesymistycznymi myślami z kolegami w biurze i że inni też to zauważyli. Wyjaśnił, że jeśli mam wątpliwości, mogę w pełni wyrazić je kierownictwu, ale nie „usuwać ich”. Jako główny inżynier muszę zwracać uwagę na to, jak moje słowa wpływają na innych, ponieważ mam duży wpływ, nawet jeśli nie zdaję sobie z tego sprawy. I opowiedział mi to wszystko bardzo uprzejmie, aż w końcu stwierdził, że jeśli naprawdę tak się czuję, to chyba muszę się zastanowić, czego chcę dla siebie i swojej kariery. To była niezwykle delikatna rozmowa w stylu „wejdź albo wstań”. Podziękowałem mu za informację o tym, jak moje zmienione nastawienie w ciągu sześciu miesięcy niezauważone przeze mnie wpłynęło na innych.
Był to przykład niezwykłego, skutecznego zarządzania i siły miękkiego podejścia. Zdałem sobie sprawę, że tylko z pozoru miałem całkowitą wiarę w firmę i jej zdolność do osiągania swoich celów, ale w rzeczywistości rozmawiałem i komunikowałem się z innymi w zupełnie inny sposób. Uświadomiłam sobie też, że nawet jeśli jestem sceptyczna wobec projektu, nad którym pracuję, nie powinnam okazywać swoich uczuć współpracownikom i zarażać się pesymizmem jak zarazą, zmniejszając nasze szanse na sukces. Zamiast tego mógłbym agresywnie przekazać mojemu kierownictwu prawdziwą sytuację. A jeśli czułem, że mnie nie słuchają, mogłem wyrazić swój sprzeciw odchodząc z firmy.
Otrzymałem nową szansę, gdy objąłem stanowisko kierownika ds. oceny personelu. Jako były główny inżynier bardzo ostrożnie wyrażam swoje opinie na temat naszego (ciągle udoskonalanego) starszego kodu. Aby zatwierdzić zmianę, musisz wyobrazić sobie obecną sytuację, ale donikąd nie zajdziesz, jeśli będziesz tarzać się w jękach, atakach i tym podobnych. Ostatecznie jestem tutaj, aby wykonać zadanie i nie powinienem narzekać na kod, aby go zrozumieć, ocenić lub naprawić.
Tak naprawdę, im bardziej kontroluję swoją reakcję emocjonalną na kod, tym lepiej rozumiem, czym może się stać i tym mniej czuję zamieszania. Kiedy wyrażałem się powściągliwie („tu musi być miejsce na dalszą poprawę”), uszczęśliwiałem siebie i innych i nie traktowałem sytuacji zbyt poważnie. Zdałem sobie sprawę, że mogę stymulować i redukować negatywne nastawienie u innych, zachowując się doskonale (irytująco?) rozsądnie („masz rację, ten kod jest dość zły, ale poprawimy go”). Cieszę się, że mogę zajść na ścieżce zen.
Zasadniczo ciągle uczę się ważnej lekcji: życie jest za krótkie, aby ciągle się złościć i odczuwać ból.
Źródło: www.habr.com