Я дивлюся на шматок коду. Можливо, це найгірший код, що мені колись зустрічався. Щоб оновити лише один запис у базі даних, він отримує всі записи в колекції, а потім надсилає запит на оновлення кожного запису в базі, навіть ті, які оновлювати не потрібно. Тут є map-функція, яка просто повертає передане їй значення. Є умовні перевірки змінних з очевидно однаковим значенням, просто названих у різних стилях (firstName и first_name). Для кожного UPDATE'а код відправляє повідомлення в іншу чергу, яка обробляється іншою serverless-функцією, але яка виконує всю роботу для іншої колекції в тій же базі даних. Я не згадав, що ця serverless-функція з хмарної «сервіс-орієнтованої архітектури», що містить понад 100 функцій в оточенні?
Як загалом можна було таке зробити? Я закриваю обличчя і виразно схлипую крізь сміх. Мої колеги запитують, що трапилося, і я у фарбах переказую Worst Hits Of BulkDataImporter.js 2018. Усі співчутливо кивають мені і погоджуються: як вони могли так з нами вчинити?
Негатив: емоційний інструмент у програмістській культурі
Негатив грає у програмуванні важливу роль. Він убудований у нашу культуру і використовується для того, щоб поділитися впізнаним («ти не повіриш, на що був схожий цей код!»), для вираження співчуття через розлад («Господи, НАВІЩО так робити?»), щоб показати себе у вигідному світлі («я б ніколи так не зробив»), щоб звалити провину на іншого («ми зафейлилися через його код, який неможливо супроводжувати»), або, як прийнято в «токсичних» організаціях, щоб керувати іншими через почуття сорому («ти про що взагалі думав - Виправляй »).
Негатив настільки важливий для програмістів оскільки це дуже ефективний спосіб передачі цінності. Колись я навчався у таборі для програмістів, і стандартною практикою щеплення студентам цехової культури було щедре постачання мемами, історіями та відео, найпопулярніші з яких експлуатували . Добре, коли можна використовувати емоційні інструменти для позначення методик Хороших, Поганих, Жахливих, Ніколи Так Не Робіть, Взагалі Ніколи. Потрібно підготувати новачків до того, що їх, напевно, розумітимуть помилково колеги, далекі від IT. Що їхні друзі почнуть втюхувати їм ідеї додатків на мільйон. Що їм доведеться блукати в нескінченних лабіринтах застарілого коду з купою мінотаврів за рогом.
Коли ми починаємо вперше вчитися програмування, наше уявлення про глибину «досвіду програмування» ґрунтується на спостереженнях за емоційними реакціями інших людей. Це добре видно по постах у , в якому тусується багато новачків-програмістів Багато гумористичних у тому чи іншою мірою забарвлені різними відтінками негативу: розчарування, песимізму, обурення, поблажливості та інших. А якщо вам цього здасться мало, почитайте коментарі.
Я помітив, що в міру накопичення досвіду у програмістів стає все більше негативу. Новачки, які не підозрюють про труднощі, що очікують їх, починають з ентузіазмом і готовністю повірити, що причина цих труднощів просто в нестачі досвіду і знань; і, зрештою, вони зіткнуться з реальним станом речей.
Проходить час, вони набираються досвіду і знаходять можливість відрізнити Хороший код від Поганого. І коли цей момент настає, молоді програмісти зазнають прикрості від роботи з явно поганим кодом. А якщо вони працюють у колективі (дистанційно чи очно), то часто переймають емоційні звички досвідченіших колег. Нерідко це призводить до збільшення негативу, адже молоді тепер можуть глибокодумно говорити про код і розділяти його на поганий і добрий, показуючи тим, що вони «в темі». Це ще більше посилює негатив: на ґрунті розчарування легко зійтися з колегами та стати частиною групи, критика Поганого коду підвищує ваш статус та професіоналізм в очах інших: .
Посилення негативу необов'язкове явище. Обговорення програмування, крім іншого, украй зосереджено якості написаного коду. Те, чим є код, повністю визначає функцію, для якої він призначений (відкинемо обладнання, мережу тощо), тому важливо мати можливість висловити свою думку про цей код. Майже всі дискусії зводяться до того, чи досить добрий цей код, і до засудження самих маніфестів поганого коду у виразах, емоційне забарвлення яких характеризує якість коду:
- "У цьому модулі багато логічних невідповідностей, це хороший кандидат на значну оптимізацію продуктивності".
- "Цей модуль досить поганий, нам потрібно його рефакторити".
- "Цей модуль не має сенсу, його потрібно переписати".
- "Цей модуль відстій, його потрібно патчити".
- «Це шматок барана, а не модуль, його взагалі не треба було писати, про що блін, думав його автор».
До речі, саме ця «емоційна розрядка» змушує розробників називати код «сексі», що рідко буває справедливим — якщо ви не працюєте в PornHub.
Проблема полягає в тому, що люди — дивні, неспокійні, сповнені емоцій створення, і сприйняття та вираження будь-яких емоцій змінює нас: спочатку ледь помітно, але згодом — кардинально.
Неспокійна слизька доріжка негативу
Декілька років тому я був неформальним тимлідом і співбесідував одного розробника. Він нам дуже подобався: був розумним, ставив добрі питання, був технічно підкований і чудово вписувався в нашу культуру. Мені особливо імпонувала його позитивність і те, яким заповзятливим він здавався. І я його найняв.
На той момент я працював у компанії кілька років і відчував, що прийнята у нас культура не надто ефективна. Ми намагалися запустити продукт двічі, тричі і ще пару разів до мого приходу, що призводило до великих витрат на переробки, протягом яких нам не було чого показати крім довгих ночей, стислих термінів і типу-працюючих продуктів. І хоча я ще старанно працював, проте скептично висловлювався щодо останнього дедлайну, призначеного нам керівництвом. І недбало вилаявся під час обговорення з моїми колегами деяких аспектів коду.
Так що не було нічого дивного в тому — хоча я здивувався, — що через кілька тижнів цей новий розробник висловився в тому ж негативному ключі, що і я (включаючи лайку). Я зрозумів, що він поводився б інакше в іншій компанії з іншою культурою. Він лише підлаштувався під ту культуру, яку я створив. Мене накрило почуття провини. Через свій суб'єктивний досвід я прищепив песимізм новачкові, якого я сприймав зовсім іншим. Навіть якщо він насправді не був таким і лише намагався здаватися, щоб показати, що може влитися в колектив, я нав'язав йому своє лайнове ставлення. А все сказане, хай навіть жартома чи мимохідь, має погану манеру перетворюватися на те, у що вірять.
Шляхи негативу
Повернемося до наших колишніх новачків-програмістів, які трішки набралися мудрості та досвіду: вони ближче познайомилися з індустрією програмування та розуміють, що поганий код скрізь, його не можна уникнути. Він зустрічається навіть у найбільш просунутих компаніях, зосереджених на якості (і дозвольте помітити: зважаючи на все, сучасність зовсім не рятує від поганого коду).
Гарний сценарій. Згодом розробники починають упокорюватися з тим, що поганий код — реальність програмного забезпечення, і що їхня робота полягає в тому, щоб його покращити. І що якщо не можна уникнути поганого коду, то немає сенсу піднімати через нього шум. Вони встають на шлях дзена, зосереджуються на вирішенні проблем чи завдань, що постають перед ними. Дізнаються, як можна точно виміряти та подати якість ПЗ власникам бізнесу, на основі свого багаторічного досвіду пишуть чудово обґрунтовані кошториси, і зрештою отримують щедрі винагороди за свою неймовірну та незмінну цінність для бізнесу. Вони так добре роблять свою роботу, що їм платять преміальні бонуси $10 млн., і вони виходять на пенсію, щоб до кінця життя займатися тим, чим хочеться (будь ласка, не приймайте на віру).
Інший сценарій – це шлях темряви. Замість того, щоб прийняти поганий код як неминучість, розробники беруть на себе обов'язок сповіщати про все погане у світі програмування, щоб вони могли перемогти це. Вони відмовляються покращувати існуючий поганий код через безліч добрих причин: «люди повинні більше знати і не бути такими тупими»; "це неприємно"; "це погано для бізнесу"; "це доводить, наскільки я розумний"; «Якщо я не розповім, який це паршивий код, вся компанія скинеться в океан», і так далі.
Напевно, не маючи можливості реалізувати бажані ними зміни, оскільки бізнес, на жаль, повинен продовжувати розробляти і не може витрачати час на турботу про якість коду, такі люди набувають репутації скаржників. Їх тримають за високу компетентність, проте витісняють на задвірки компанії, де вони не багатьом докучатимуть, але при цьому підтримуватимуть роботу критично важливих систем. Позбувшись доступу до нових можливостей у розробці, вони втрачають навички і перестають відповідати вимогам індустрії. Їх негатив перетворюється на запеклу гіркоту, і в результаті вони тішать своє его, сперечаючись із двадцятирічними студентами про шлях, пройдений їхньою улюбленою старою технологією і чому вона ще бадьорком. Зрештою вони виходять на пенсію і проживають старість, лаючись на птахів.
Ймовірно, реальність перебуває десь посередині між цими двома крайнощами.
Деякі компанії надзвичайно досягли успіху у створенні вкрай негативних, відокремлених, вольових культур. ) — найчастіше це компанії з продуктами, що чудово відповідають ринку, і необхідністю зростати якнайшвидше; або компанії з ієрархією управління та контролю (Apple у найкращі роки Джобса), де кожен робить те, що накажуть. Однак сучасні бізнес-дослідження (та й здоровий глузд) говорять про те, що для максимальної винахідливості, що призводить до інноваційності компанії, і високої продуктивності окремих людей необхідний низький рівень стресу, щоб підтримувати безперервне творче та методичне мислення. І вкрай важко виконувати творчу роботу, в основі якої лежать обговорення, якщо постійно переймаєшся тим, що твої колеги повинні будуть сказати про кожен рядок твого коду.
Негатив – це інженерна поп-культура
Сьогодні щодо інженерів приділяється стільки уваги, як ніколи. В інженерних організаціях все популярнішим стає правило.«. У Твіттері з'являється все більше анекдотів та історій про людей, які покинули цю професію тому, що не змогли (не захотіли) і далі миритися з ворожістю та недоброзичливістю до сторонніх. Навіть Лінус Торвальдс за роки своєї ворожості та критики на адресу інших Linux-розробників це призвело до дискусії про ефективність такого підходу.
Хтось досі відстоює право Лінуса бути дуже критичним — ті, хто має багато знати про переваги та недоліки «токсичного негативу». Так, коректність вкрай важлива (навіть фундаментальна), але якщо резюмувати причини, з яких багато хто з нас дозволяє висловити негативну думку перетворитися на «токсичність», то ці причини виглядають патерналістськими або підлітковими: «вони заслуговують на це, тому що ідіоти», «він повинен бути впевнений, що вони цього не повторять», «якби вони так не вчинили, йому не довелося б на них кричати», і таке інше. Прикладом того, який вплив емоційні реакції лідера на співтовариство програмістів, є абревіатура MINASWAN у співтоваристві Ruby — «Matz is nice so we are nice» (Мац [творець мови] хороший, отже й ми хороші).
Я помітив, що багато палких прихильників підходу «убий дурня» часто дуже дбають про якість та коректність коду, ідентифікуючи себе зі своєю роботою. На жаль, вони часто плутають твердість із жорсткістю. Недолік такої позиції випливає з простого людського, але непродуктивного бажання відчути свою перевагу над іншими. Люди, які поринають у це бажання, застряють на шляху пітьми.
Світ програмування швидко зростає і упирається в межі свого контейнера - світу непрограмування (або це світ програмування є контейнером для світу непрограмування? хороше питання).
У міру того, як наша індустрія розширюється наростаючими темпами і програмування стає все доступнішим, дистанція між «технарями» та «нормальними» швидко скорочується. Світ програмування дедалі більше піддається впливу міжособистісного спілкування людей, які зросли в ізольованій культурі «ботанів» початку технобуму, і вони сформують новий світ програмування. І незважаючи на будь-які аргументи щодо соціальної сфери чи поколінь, ефективність в ім'я капіталізму виявиться в культурі компаній та підходах до найму: найкращі компанії просто не будуть наймати тих, хто не зможе взаємодіяти з іншими нейтрально, не кажучи вже про добрі стосунки.
Що я дізнався про негатив
Якщо ви дозволяєте надлишку негативу керувати вашим розумом і спілкуванням з людьми, перетворюючись на «токсичність», це небезпечно для продуктових команд і дорого для бізнесу. Я бачив незліченну кількість проектів (і чув про такі), які розвалилися і були повністю перероблені з великими витратами, бо один із розробників, якому довіряли, точив зуб на технологію, іншого розробника чи взагалі єдиний файл, вибраний для представлення якості всієї кодової бази .
Також негатив деморалізує та руйнує стосунки. Я ніколи не забуду, як колега лаяв мене за те, що я поклав CSS не в той файл, мене це засмутило і не давало зібратися з думками кілька днів. І в майбутньому я навряд чи дозволю подібній людині опинитися поблизу однієї з моїх команд (втім, хто знає, люди змінюються).
Зрештою, негатив .
Мені здається, так має виглядати майстер-клас з посмішок.
Звичайно, це не аргумент на користь того, щоб лучитися щастям, вставляти десять мільярдів смайлів у кожен pull request або вирушити на майстер-клас з усмішок (ні, ну якщо ви саме цього хочете, то не питання). Негатив є вкрай важливою частиною програмування (і людського життя), сигналізуючи про якість, дозволяючи висловити почуття та поспівчувати людям-братам. Негатив свідчить про проникливість та розважливість, про глибину проблеми. Я часто помічаю, що розробник досяг нового рівня, коли він починає висловлювати недовіру в тому, що раніше був боязкий і невпевнений. Своїми думками люди демонструють розважливість та впевненість. Не можна відкинути вираз негативу, це було б по-оруелівськи.
Однак негатив потрібно дозувати та врівноважувати іншими важливими людськими якостями: співчуттям, терпінням, розумінням та гумором. Завжди можна сказати людині, що вона облажалася, без крику і лайки. Не треба недооцінювати такий підхід: якщо тобі без емоцій кажуть, що ти серйозно накосячив, це справді лякає.
На той раз, кілька років тому, зі мною поговорив СEO. Ми обговорили поточне положення проекту, потім він запитав, як я почуваюся. Я відповів, що все нормально, проект рухається, потихеньку працюємо, мабуть, я дещо упустив і треба переглянути. Він сказав, що чув, як я ділився песимістичнішими міркуваннями з колегами в офісі, і що інші теж це помітили. Він пояснив, що якщо я маю сумніви, я можу повною мірою висловити їх керівництву, але не «спускати вниз». Будучи провідним інженером, я повинен пам'ятати, як мої слова діють на інших, тому що я маю великий вплив, навіть якщо того не усвідомлюю. І все це він сказав мені дуже по-доброму, і на завершення сказав, що якщо я справді відчуваю такі почуття, то мені, мабуть, треба обміркувати, чого я бажаю для себе та своєї кар'єри. Це була неймовірно м'яка розмова у стилі «візьми себе в руки або виметайся». Я подякував йому за інформацію про те, як моє ставлення, що змінилося за півроку, непомітно для мене впливає на інших.
Це був приклад чудового, ефективного управління та сили м'якого підходу. Я зрозумів, що мені лише здавалося, ніби я цілком вірю в компанію і її здатність досягти цілей, а насправді говорив і спілкувався з іншими зовсім інакше. Також я зрозумів, що навіть відчуваючи скептицизм щодо проекту, над яким я працював, мені не слід було показувати своє ставлення колегам і поширювати песимізм наче заразу, зменшуючи наші шанси на успіх. Натомість я міг агресивно транслювати реальне становище своєму керівництву. І якби я відчув, що вони мене не слухають, то міг би висловити свою незгоду з відходу з компанії.
Я отримав нову нагоду, коли обійняв посаду керівника з оцінки персоналу. Будучи колишнім головним інженером, я дуже уважно стежу за висловленням своєї думки про нашу (постійно поліпшується) легасі-код. Щоб схвалити зміну, потрібно представляти поточну ситуацію, але ви ні до чого не прийдете, якщо забруднете в стогнаннях, нападках чи подібному. Зрештою, я тут для того, щоб виконати завдання, і не повинен скаржитися на код, щоб зрозуміти його, оцінити чи виправити.
Фактично чим більше я стримую свою емоційну реакцію на код, тим краще розумію, яким він міг би стати, і тим менше сум'яття відчуваю. Коли я висловлювався стримано («тут мають бути можливості для подальших покращень»), то тим самим радував себе та інших і не приймав ситуацію надто близько до серця. Я усвідомив, що можу стимулювати і знижувати негатив в інших, будучи ідеально (дратівливо?) розсудливим («ви маєте рацію, цей код досить поганий, але ми його покращимо»). Я радий тому, наскільки далеко можу пройти дорогою дзена.
По суті, я постійно навчаюсь і переучую важливий урок: життя надто коротке, щоб постійно злитися та страждати.
Джерело: habr.com