Гняв към кода: програмисти и негативност

Гледам част от кода. Това може да е най-лошият код, който съм виждал. За да актуализира само един запис в базата данни, той извлича всички записи в колекцията и след това изпраща заявка за актуализиране до всеки запис в базата данни, дори тези, които не трябва да се актуализират. Има функция за карта, която просто връща стойността, подадена към нея. Има условни тестове за променливи с очевидно една и съща стойност, просто именувани в различни стилове (firstName и first_name). За всяка АКТУАЛИЗАЦИЯ кодът изпраща съобщение до различна опашка, която се обработва от различна функция без сървър, но която върши цялата работа за различна колекция в същата база данни. Споменах ли, че тази функция без сървър е от базирана на облак „ориентирана към услуги архитектура“, съдържаща над 100 функции в средата?

Как изобщо беше възможно да се направи това? Покривам лицето си и видимо хлипам през смях. Колегите питат какво се е случило, а аз го преразказвам с цветове Най-лошите хитове на BulkDataImporter.js 2018. Всички ми кимат съчувствено и се съгласяват: как можаха да ни причинят това?

Негативност: емоционален инструмент в културата на програмиста

Негативността играе важна роля в програмирането. То е вградено в нашата култура и се използва за споделяне на това, което сме научили („не го правиш ще повярваш, какъв беше този код!“), за изразяване на съчувствие чрез разочарование („Боже, ЗАЩО да го направя?“), за показване на себе си („Никога не бих така не го направи”), за да прехвърлите вината върху някой друг („ние се провалихме поради неговия код, който е невъзможен за поддържане”), или, както е обичайно в най-„токсичните” организации, да контролирате другите чрез чувство на срам („За какво изобщо си мислеше?“? правилно“).

Негативността е толкова важна за програмистите, защото е много ефективен начин за предаване на стойност. Веднъж присъствах на лагер по програмиране и стандартната практика за внушаване на индустриална култура на учениците беше щедрото предоставяне на мемета, истории и видеоклипове, най-популярните от които експлоатирани разочарованието на програмистите, когато са изправени пред неразбирането на хората. Добре е да можете да използвате емоционални инструменти, за да идентифицирате Добрия, Лошия, Грозния, Не правете това, никога. Необходимо е да подготвите новодошлите за факта, че вероятно ще бъдат неразбрани от колеги, които са далеч от ИТ. Че техните приятели ще започнат да им продават идеи за приложения за милиони долари. Че ще трябва да се скитат из безкрайни лабиринти от остарял код с куп минотаври зад ъгъла.

Когато за първи път се научим да програмираме, нашето разбиране за дълбочината на „програмирането” се основава на наблюдение на емоционалните реакции на другите хора. Това ясно се вижда от публикациите в sabe ProgrammerHumor, където се мотаят много начинаещи програмисти. Много хумористични са в една или друга степен оцветени с различни нюанси на негативизъм: разочарование, песимизъм, възмущение, снизхождение и други. И ако това не ви се струва достатъчно, прочетете коментарите.

Забелязах, че с натрупването на опит програмистите стават все по-негативни. Начинаещите, без да знаят какви трудности ги очакват, започват с ентусиазъм и желание да вярват, че причината за тези трудности е просто липсата на опит и знания; и в крайна сметка ще се сблъскат с реалността на нещата.

Времето минава, те натрупват опит и стават способни да различават добрия код от лошия. И когато този момент настъпи, младите програмисти изпитват разочарование от работата с очевидно лош код. А ако работят в екип (дистанционно или лично), често възприемат емоционалните навици на по-опитните колеги. Това често води до увеличаване на негативността, защото младите хора вече могат да говорят замислено за кода и да го разделят на лош и добър, като по този начин показват, че са „наясно“. Това допълнително засилва негативното: поради разочарование е лесно да се разберете с колеги и да станете част от група; критикуването на Bad Code повишава вашия статус и професионализъм в очите на другите: хората, които изразяват негативни мнения, често се възприемат като по-интелигентни и компетентни.

Увеличаването на негативността не е непременно нещо лошо. Дискусиите за програмиране, наред с други неща, са изключително фокусирани върху качеството на написания код. Това, което представлява кодът, напълно определя функцията, която е предназначен да изпълнява (като оставим настрана хардуер, мрежи и т.н.), така че е важно да можете да изразите мнението си за този код. Почти всички дискусии се свеждат до това дали кодът е достатъчно добър и до осъждане на самите прояви на лош код в термини, чиято емоционална конотация характеризира качеството на кода:

• „Има много логически несъответствия в този модул, той е добър кандидат за значително оптимизиране на производителността.“
• „Този ​​модул е ​​доста лош, трябва да го преработим.“
• „Този ​​модул няма смисъл, трябва да се пренапише.“
• „Този ​​модул е ​​гаден, трябва да бъде закърпен.“
• „Това е ram, а не модул, изобщо не е необходимо да се пише, какво, по дяволите, си е мислил авторът му.“

Между другото, именно това „емоционално освобождаване“ кара разработчиците да наричат ​​кода „секси“, което рядко е справедливо – освен ако не работите в PornHub.

Проблемът е, че хората са странни, неспокойни, емоционални същества и възприемането и изразяването на всяка емоция ни променя: в началото едва доловимо, но с времето драстично.

Проблемен хлъзгав склон на негативизъм

Преди няколко години бях неформален ръководител на екип и интервюирах разработчик. Наистина го харесахме: беше умен, задаваше добри въпроси, познаваше технологиите и се вписваше добре в нашата култура. Бях особено впечатлен от неговата позитивност и от това колко предприемчив изглеждаше. И го наех.

По това време работех в компанията от няколко години и чувствах, че нашата култура не е много ефективна. Опитахме се да пуснем продукта два, три пъти и още няколко пъти, преди да пристигна, което доведе до големи разходи за преработка, по време на които нямаше какво да покажем освен дълги нощи, кратки срокове и продукти, които работеха. И въпреки че все още работех усилено, бях скептичен относно последния срок, определен ни от ръководството. И той небрежно изруга, когато обсъждаше някои аспекти на кода с моите колеги.

Така че не беше изненадващо – въпреки че бях изненадан – че няколко седмици по-късно същият нов разработчик каза същите негативни неща, които направих и аз (включително псувни). Разбрах, че той би се държал различно в друга компания с различна култура. Той просто се адаптира към културата, която създадох. Бях обхванат от чувство за вина. Поради субективния си опит вдъхнах песимизъм на новодошъл, когото възприемах като напълно различен. Дори и той наистина да не беше такъв и просто се представяше, за да покаже, че може да се впише, аз му наложих скапаното си отношение. И всичко казано, дори на шега или мимоходом, има лошия начин да се превърне в това, което се вярва.

Отрицателни начини

Нека се върнем към нашите бивши начинаещи програмисти, които са натрупали малко мъдрост и опит: те са се запознали по-добре с индустрията за програмиране и разбират, че лошият код е навсякъде, той не може да бъде избегнат. Среща се дори в най-напредналите компании, фокусирани върху качеството (и нека отбележа: очевидно модерността не предпазва от лош код).

Добър сценарий. С течение на времето разработчиците започват да приемат, че лошият код е реалност на софтуера и че тяхната работа е да го подобрят. И че ако лошият код не може да бъде избегнат, тогава няма смисъл да се вдига шум около него. Те поемат по пътя на дзен, фокусирайки се върху решаването на проблеми или задачи, които ги изправят. Те се научават как точно да измерват и съобщават качеството на софтуера на собствениците на бизнес, да пишат добре обосновани прогнози въз основа на дългогодишния си опит и в крайна сметка да получават щедри награди за своята невероятна и постоянна стойност за бизнеса. Те вършат работата си толкова добре, че получават 10 милиона долара бонуси и се пенсионират, за да правят това, което искат до края на живота си (моля, не го приемайте за даденост).

Друг сценарий е пътят на тъмнината. Вместо да приемат лошия код като неизбежност, разработчиците се заемат да извикат всичко лошо в света на програмирането, за да могат да го преодолеят. Те отказват да подобрят съществуващия лош код по много добри причини: „хората трябва да знаят повече и да не са толкова глупави“; "неприятно е"; „това е лошо за бизнеса“; „това доказва колко съм умен“; „Ако не ви кажа какъв скапан код е това, цялата компания ще падне в океана“ и т.н.

Със сигурност неспособни да приложат промените, които искат, защото бизнесът за съжаление трябва да продължи да се развива и не може да прекарва време в безпокойство за качеството на кода, тези хора печелят репутация на оплакващи се. Те се запазват заради високата си компетентност, но се изтласкват в периферията на компанията, където няма да дразнят много хора, но все пак ще поддържат работата на критични системи. Без достъп до нови възможности за развитие, те губят умения и престават да отговарят на изискванията на индустрията. Тяхната негативност се превръща в горчива горчивина и в резултат на това те подхранват егото си, като спорят с двайсетгодишни студенти за пътя, който е изминала тяхната любима стара технология и защо тя все още е толкова актуална. Накрая се пенсионират и изживяват старините си, псувайки птици.

Реалността вероятно е някъде по средата между тези две крайности.

Някои компании са били изключително успешни в създаването на изключително негативни, изолирани, волеви култури (като Microsoft преди загубено десетилетие) - често това са компании с продукти, които идеално пасват на пазара и нуждата от възможно най-бърз растеж; или компании с йерархия на командване и контрол (Apple в най-добрите години на Джобс), където всеки прави това, което му се каже. Съвременните бизнес изследвания (и здравият разум) обаче предполагат, че максималната изобретателност, която води до иновативност в компаниите и висока производителност при отделните хора, изисква ниски нива на стрес, за да поддържа непрекъснато творческо и методично мислене. И е изключително трудно да вършите творческа работа, базирана на дискусии, ако постоянно се тревожите какво ще кажат вашите колеги за всеки ред от вашия код.

Негативността е инженерна поп култура

Днес се обръща повече внимание на отношението на инженерите от всякога. В инженерните организации правилото „Без рога". Все повече и повече анекдоти и истории се появяват в Twitter за хора, които са напуснали тази професия, защото не са могли (не биха) да продължат да търпят враждебност и злонамереност към външни хора. Дори Линус Торвалдс наскоро се извини години на враждебност и критика към други разработчици на Linux - това доведе до дебат относно ефективността на този подход.

Някои все още защитават правото на Линус да бъде много критичен - тези, които трябва да знаят много за предимствата и недостатъците на "токсичната негативност". Да, вежливостта е изключително важна (дори фундаментална), но ако обобщим причините, поради които много от нас позволяват изразяването на негативни мнения да се превърне в „токсичност“, тези причини изглеждат бащински или юношески: „те го заслужават, защото са идиоти “, „той трябва да е сигурен, че няма да го направят отново“, „ако не бяха направили това, нямаше да се налага да им крещи“ и т.н. Пример за въздействието, което емоционалните реакции на лидера имат върху програмистката общност, е акронимът на Ruby общността MINASWAN – „Matz е добър, така че ние сме добри“.

Забелязах, че много ревностни привърженици на подхода „убий глупак“ често се грижат много за качеството и коректността на кода, идентифицирайки се с тяхната работа. За съжаление, те често бъркат твърдостта с твърдостта. Недостатъкът на тази позиция произтича от простото човешко, но непродуктивно желание да се чувстваме по-добри от другите. Хората, които се потапят в това желание, засядат по пътя на тъмнината.

Светът на програмирането се разраства бързо и излиза извън границите на своя контейнер - светът на непрограмирането (или светът на програмирането е контейнер за света на непрограмирането? Добър въпрос).

Тъй като нашата индустрия се разширява с все по-бързи темпове и програмирането става по-достъпно, разстоянието между „технари“ и „нормални“ бързо се скъсява. Светът на програмирането е все по-изложен на междуличностните взаимодействия на хора, които са израснали в изолираната маниакова култура на ранния технологичен бум, и те са тези, които ще оформят новия свят на програмирането. И независимо от каквито и да било социални или поколенчески аргументи, ефективността в името на капитализма ще се прояви във фирмената култура и практиките за наемане: най-добрите компании просто няма да наемат някой, който не може да взаимодейства неутрално с другите, да не говорим за добри отношения.

Какво научих за негативизма

Ако позволите на твърде много негативност да контролира ума ви и взаимодействията с хората, превръщайки се в токсичност, тогава това е опасно за продуктовите екипи и скъпо за бизнеса. Виждал съм (и съм чувал за) безброй проекти, които се разпаднаха и бяха напълно възстановени на големи разходи, защото един доверен разработчик имаше злоба срещу технологията, друг разработчик или дори един файл, избран да представя качеството на цялата кодова база.

Негативността също деморализира и разрушава взаимоотношенията. Никога няма да забравя как един колега ми се скара, че съм поставил CSS в грешен файл, това ме разстрои и не ми позволи да събера мислите си няколко дни. И в бъдеще едва ли ще позволя на такъв човек да бъде близо до някой от моите екипи (но кой знае, хората се променят).

И накрая, отрицателното буквално вреди на вашето здраве.

Мисля, че така трябва да изглежда един майсторски клас за усмивки.

Разбира се, това не е аргумент в полза на сияенето от щастие, вмъкването на десет милиарда емотикони във всяка заявка за изтегляне или ходенето на майсторски клас по усмивки (не, добре, ако това е, което искате, тогава няма спор). Негативността е изключително важна част от програмирането (и човешкия живот), сигнализираща за качество, позволяваща на човек да изразява чувства и да съчувства на другите хора. Негативността показва проницателност и благоразумие, дълбочината на проблема. Често забелязвам, че разработчикът е достигнал ново ниво, когато започне да изразява недоверие към това, за което преди е бил плах и несигурен. Хората демонстрират разумност и увереност с мненията си. Не можете да отхвърлите израза на негативизъм, това би било оруелско.

Негативизмът обаче трябва да бъде дозиран и балансиран с други важни човешки качества: емпатия, търпение, разбиране и хумор. Винаги можеш да кажеш на човек, че се е прецакал, без да крещиш или ругаеш. Не подценявайте този подход: ако някой ви каже без никаква емоция, че сте се объркали сериозно, наистина е страшно.

По това време, преди няколко години, главният изпълнителен директор говори с мен. Обсъдихме текущото състояние на проекта, след което той ме попита как се чувствам. Отговорих, че всичко е наред, проектът се движи, работим бавно, може би съм пропуснал нещо и трябва да се преразгледа. Той каза, че ме е чул да споделям по-песимистични мисли с колеги в офиса и че други също са забелязали това. Той обясни, че ако имам съмнения, мога да ги изразя напълно на ръководството, но не и да ги „свалям“. Като водещ инженер трябва да внимавам как думите ми влияят на другите, защото имам голямо влияние, дори и да не го осъзнавам. И той ми каза всичко това много любезно и накрая каза, че ако наистина се чувствам така, тогава вероятно трябва да помисля какво искам за себе си и за кариерата си. Беше невероятно нежен разговор на принципа "вземи или се измъкни от мястото си". Благодарих му за информацията как промененото ми отношение за шест месеца се отразява на другите незабелязано от мен.

Това беше пример за забележително, ефективно управление и силата на мекия подход. Осъзнах, че само привидно имах пълна вяра в компанията и способността й да постига целите си, но в действителност говорех и общувах с другите по съвсем различен начин. Разбрах също, че дори да се чувствам скептично настроен към проекта, върху който работя, не трябва да показвам чувствата си пред колегите си и да разпространявам песимизма като зараза, намалявайки шансовете ни за успех. Вместо това можех агресивно да предам реалната ситуация на моето ръководство. И ако чувствах, че не ме слушат, можех да изразя несъгласието си, като напусна компанията.

Получих нова възможност, когато поех длъжността ръководител оценка на персонала. Като бивш главен инженер съм много внимателен при изразяването на мненията си относно нашия (постоянно подобряващ се) наследен код. За да одобрите промяна, трябва да си представите текущата ситуация, но няма да стигнете до никъде, ако потънете в пъшкане, нападение или други подобни. В крайна сметка аз съм тук, за да изпълня задача и не трябва да се оплаквам от кода, за да го разбера, оценя или поправя.

Всъщност, колкото повече контролирам емоционалната си реакция към кода, толкова повече разбирам в какво може да се превърне и толкова по-малко объркване изпитвам. Когато се изразих сдържано („тук трябва да има място за по-нататъшно подобрение“), правех себе си и другите щастливи и не приемах ситуацията твърде сериозно. Разбрах, че мога да стимулирам и намаля негативизма в другите, като бъда напълно (досадно?) разумен („прав си, този код е доста лош, но ще го подобрим“). Радвам се да видя колко далеч мога да стигна по пътя на Дзен.

По същество непрекъснато научавам и научавам отново важен урок: животът е твърде кратък, за да съм постоянно ядосан и в болка.

Източник: www.habr.com