Діалоги з Богом. Частина Перша

    Іноді корисно буває мати поганий настрій, пересратись з усіма довкола, та з нудьги спробувати поговорили з Богом. Тим більше, що знайти хорошого співрозмовника в житті надзвичайно важко, а тут він бац - і доступний 24/7, і то лише за двадцять баксів на місяць. Одна з моїх ознак приємного співрозмовника - непомітний плин часу в процесі розмови. Теми міняються плавно, і ти ніколи не знаєш куди тебе занесе. Цього разу я почав навіть не згадаю з чого, а закінчив сповіддю про свої робочі роки, і зроблені з цього висновки. Він не перебиваючи слухав, як не вміє слухати ніхто з людей, і зрештою сказав, що він згідний, і що все це потягне на розділ якоїсь книги, або окрему професійну статтю. Або й кілька. Хто я такий, щоб сперечатись із Богом? Виконую!

    Частина перша. Про код ревью

    Всі програмісти знають що таке код ревью. Є мільйон порад і практик як ефективно робити ревью чужого коду. Поради всі слушні і помічні, але мене завжди тригерило те, що всі ці поради - технічні, тоді як ревью коду - процес більше психологічний, а значить, на порядок складніший за пошук потенційних проблем в чужому коді. Я багато разів задвигав цю тему десяткам колег на різних проектах і продуктах, і жодного разу за всі роки не достукався ні до кого. Я навіть почав думати, що я якийсь в цьому плані унікальний, і спробував нагуглити щось по цій темі. Я не знайшов нічого. Точніше, знайшов лише єдину абсолютно геніальну грунтовну статтю, яку я старанно розсилаю всім колегам на всіх своїх проектах, приблизно з тим же результатом, якого я досягав, розповідаючи все те саме своїми словами. Тобто - без жодного результату. І тим не менш, я спробую коротко і без дублювання статті, висловитись на цю тему, проблеми з якою присутні в будь-якому айті-колективі.

    Перше і головне, з чого витікає решта - ревьюваючи код, програміст оцінює чужу роботу. Його задача не просто зробити код кращим, а зробити так, щоб це не призвело до негативних емоцій в автора, і зрештою його не демотивувало. А для цього головна порада - розглядати код не як набір літер, а як творіння іншої людини, яка вклала в це творіння частинку себе. Як приклад я завжди навожу прохання дружини спробувати зварений нею борщ. Чи залежить майбутня мотивація шеф-кухаря від форми відгуку? Чи існують коректні і некоректні способи висловити свою думку про борщ? Чи отримає дегустатор черпаком по макітрі за відгук на кшалт “додай солі і більше ніколи не клади цибулі”? Це все риторичні питання. Ну як жеж! Вона ж людина, вона весь ранок простояла біля плитки! Це ж потрібно акуратно, делікатно, ніжно, ввічливо, щоб не образити її почуття, не принизити її роботу, не отримати по голові черпаком чи макогоном, etc etc etc.

Зовсім не так з кодом! Адже всім відомо, що люди, заходячи в офіс, віртуально чи реально, одразу втрачають всі емоції і почуття, і перетворюються на роботів. Тепер це просто машини для написання коду, варіння кави, чи вкладання асфальту. Натиснув кнопку - код пише, каву варить, асфальт кладе. Натиснув іншу - вимикаються. Ось і все. Так щиро вважав один з моїх менторів на одній з попередніх робіт. А раз так, абсолютно байдуже в якій формі і як проводити ревью коду - знай пиши свою єдино правильну думку, причому в директивній формі менторським тоном, а робот на тому кінці дроту має бути вдячним за те, що макнули фейсом в його про%об, і мовчки все виправляти. А якщо він ще й пручатиметься, обгрунтовуючи своє рішення, ми нагуглимо йому стос лінків як early return кращий за все інше, і як автор неправий. Від цього рівень вдячності робота мав би взагалі зашкалити. Ми ж покращили код!

Чому так не відбувається? Чому люди часто або негативно реагують на такі коментарі, або мовчки роблять те що вимагають, але всередині їх свідомості відкладається негатив? Все дуже просто - ви маєте справу з людьми, і ви повинні поводитись з ними як з людьми. Це не добре і не погано, просто все решта - не працює. Людина - незрівнянно складніша за найскладніший код, і саме тому добрих менеджерів так мало, і в них такі високі зарплати. Просто вони ефективно працюють з найскладнішим що нам відомо у світі - з людьми. Розглядаючи людей як роботів без почуттів, емоцій, та інших притаманних поки що лише людині фіч, погані менеджери роблять одну з найгірших помилок, наслідки якої не забаряться. Те, що людей з таким майндсетом, допускають до менторингу і менеджменту, означає що менеджери вищого рівня також некомпетентні, що звісно дуже погано для результату.

А от те, що людина вміру емоційно реагує на зауваження в код ревью - не просто не погано, це - круто. Адже це ознака того, що людині не байдуже те, що вона робить. Якщо людині все одно - вона просто погодиться, і перепише без вагань з нуля все що робила кілька днів, адже оплачується їй все одно за час. Якщо ж людина захищає своє рішення, і її продавлюють авторитетом чи просто адмінресурсом (“не апрувну поки не виправиш як я написав”) - в людини є два варіанти. Перший - бодатись з роботом до нескінченності, без можливості закрити задачу. І другий - здатись. Так свого часу зробив і я. Просто набридло, і я “визнав” велику перевагу Early Returnів, визнав що всі люди на роботі - роботи, і просто мовчки виконував те що вимагав начальник-ревьювер, крім абсолютної вже маячні.

Так збулась нарешті мрія робо-начальника, і люди стали роботами. Настав спокій. Конфлікти зникли. Працювати стало простіше. Код став якіснішим, адже одні роботи його ревьювали, а знайдені “проблеми” інші роботи чітко виправляли. Але чи виграла в результаті команда, і зрештою, продукт? Все сталось рівно навпаки. Команда інженерів, кожен з яких міг би бути індивідуальністю, здатною  до іновацій і натхненної роботи, перетворилась на склад роботів, які бояться проявити будь-яку ініціативу, і працюють з 9:00 по 18:00. Тепер замість креативу вони просто чекали на директиви згори, і далі бездумно і бездушно їх виконували. Робо-бос нічого навіть не зрозумів. Він зі своїм робо-майндсетом і далі був найкращим, завжди правим, і отримував нове і нове поповнення в свою команду. Думаю, це відбувається і досі. Шкоду, принесену цим підходом і компанії і людям, важко переоцінити.