Кент Бек — одна з ключових фігур у сучасній розробці: автор Extreme Programming, співтворець JUnit, співавтор Agile Manifesto. У розмові на The Pragmatic Engineer Podcast він раптово зміщує фокус із мов і фреймворків на те, що роками вважав «другорядним» — комунікацію, емпатію, вміння витримувати конфлікт і продуктивний дискомфорт. І робить це не з позиції коуча з красивими слайдами, а через власне вигорання, «втрачене десятиліття» та кількарічну програму Good to Great у Facebook.
«Нас обдурили»: коли головною проблемою виявилися не комп’ютери
Бек формулює те, що багато інженерів відчувають, але рідко озвучують: найбільша складність у розробці — не технологічна.
Він описує це як «найбільший космічний практичний жарт». Поколінню, яке погано розуміло людей, але добре тягнулося до машин, пообіцяли простий шлях: «Ось комп’ютер. Якщо повністю зрозумієш комп’ютер — і все буде добре. Це все, що тобі потрібно». Він чесно пішов цим маршрутом: першу частину кар’єри будував як «найкращий програміст, яким тільки можу бути», бо здавалося, що цього достатньо.
Реальність вдарила пізніше: «Виявилося, що є ціла людська сторона, і твоя здатність впливати на зміни у світі обмежена твоєю здатністю комунікувати, емпатувати, розуміти інших людей — саме ті навички, які я думав, що не потрібно вчити». Бек прямо визнає: емпатія для нього «не природна сильна сторона», а вміння «заспокоювати й переконувати» людей він починав вивчати «з позиції, де вже був на десять років позаду».
Тут і проходить межа, яку він пропонує інженерам більше не ігнорувати. Ти можеш досягти глибокої майстерності в системах, але вплив на продукт, організацію і бізнес виявляється обмеженим саме тим, наскільки добре ти вмієш розуміти й витримувати інших людей.
Втрачене десятиліття: слава, крах і урок про кордони
Після буму кінця 90-х і початку 2000-х Бек опинився на піку впливу: Extreme Programming, JUnit, Agile Manifesto, безліч запитів на консалтинг, високі гонорари. Він отримував листи двох типів: «JUnit врятував мені життя», «XP змінив мою кар’єру» — і протилежні: «XP зруйнував моє життя, я втратив роботу, сім’ю, живу на вулиці, це твоя вина».
Ці емоційно полярні реакції стали детонатором кризи. Він описує період після дотком-кризи і 11 вересня як жорсткий злам: усі контракти на наступні місяці скасувалися «наступного дня після 9/11», паралельно потрібно було добудовувати будинок, а разом із замовленнями зник і звичний відгук індустрії.
Почалося те, що він називає «купа ментальних проблем»: тяжка депресія, повна неможливість працювати й програмувати. «У мене було втрачене десятиріччя з 2002 по 2011», — каже він. Довелося буквально відбудовувати мислення: спочатку судоку «на рівні easy», потім складніші головоломки, потім кросворди — і лише після цього він вперше знову відчув радість від вирішеної задачі в коді.
Ключовий урок цього періоду — про кордони і про те, що чужа потреба у «герої» чи «лиходії» майже не має стосунку до реальної людини, на яку це проєктують. Бек зрозумів: коли люди приписують тобі «геніальність» або «тотальну провину за їхній провал», вони часто задовольняють власну психологічну потребу. І якщо приймати це буквально, голова неминуче «розривається» між образом в чужих очах і реальним «я».
Саме цей досвід багато в чому привів його до коучингу: якщо вже інженери неминуче проходять через подібні напруження, їм потрібна не тільки технічна, а й людська підтримка.
Good to Great у Facebook: коучинг як каталізатор кар’єрного стрибка
До Facebook Бек прийшов у 2011-му — після «втраченого десятиліття» і без колишнього попиту на консалтинг, але з величезним багажем знань і сумнівів. Усередині компанії він виявив культуру, що працювала зовсім не за «його» книжками, але при цьому масштабувалася, росла й інновувала одночасно. Частину часу він працював над інфраструктурою, але вже через рік переключився на те, у чому мав унікальний досвід: коучинг інженерів.
Так народилася програма Good to Great. Ідея була простою: працювати з розробниками, які вже «хороші», але «зависли» на плато — накопичують досвід, не перетворюючи його на зростання. Він почав із трьох студентів, проводячи годинні розмови щодня, швидко зрозумів, що це занадто інтенсивно, скоригував формат — і програма почала масштабуватись.
Критичний момент — аналітика, яку зробив HR спільно з адміністраторкою програми. «Я запустив програму Good to Great… і виявилося, що люди, які були моїми студентами, удвічі частіше отримували підвищення у наступний рік, ніж схожа когорта без коучингу», — розповідає Бек.
Коучинг він описує максимально жорстко і чесно:
«Я кажу, що коучи існують, щоб ідентифікувати й індукувати продуктивний дискомфорт».
Це не «погладити по голові», а відверто сказати: «Ти це робиш погано, спробуй так-то, повернись і розкажи, що вийшло». Якщо людина не пробує — робота закінчена. Якщо пробує — з’являється шанс перейти на наступний рівень.
За кілька років через програму пройшло близько 200 людей один-на-один, ще тисячі — через курси, які він писав і передавав іншим інструкторам. До моменту, коли Бек залишав Facebook, він мав уже не лише «студентів», а й «правнуків»: тих, кого вчили люди, яких він колись коучив.
Кульмінаційний штрих — корпоративний offsite із топ-1% інженерів Facebook. «Було offsite з топ‑1% інженерів Facebook… із близько сотні людей десять були моїми колишніми студентами, які доросли до цього рівня». Це практичний доказ того, що м’які навички — не абстракція, а конкретний мультиплікатор кар’єри у висококонкурентному середовищі.
«Я просто казав правду»: як інженери ламають розмови, навіть цього не розуміючи
Окремий пласт розмови — неприємний для багатьох інженерів, але впізнаваний. Бек описує себе як людину на спектрі, з інженерною династією в родині, і дуже тверезо оцінює типові слабкі місця цієї групи.
«Нам, як інженерам, не вистачає емоційної регуляції, емпатії», — констатує він. Поширена стратегія поведінки в конфліктах — апеляція до «правди» і «просто питань». «Поширена стратегія — “я просто казав правду” або “я лише ставив питання”, але це найжахливіші речі, які я кажу, бо я поводжуся як мудак, сам того не усвідомлюючи».
Ситуація, яку він розбирає, проста: менеджер каже, що фіча потрібна за два тижні, інженер оцінює у чотири. Можна «зменшитися» й погодитись («добре, спробую»), можна агресивно відбити запит — обидві реакції руйнують довіру. Натомість потрібен третій шлях: поставити питання, щоб зрозуміти справжню потребу, артикулювати обмеження, запропонувати компроміс — і все це без пасивної агресії й сарказму.
Бек не романтизує цей процес: він каже, що для нього це не природна поведінка, а «чекліст», який потрібно свідомо проганяти в голові. Тут він згадує культову сцену з першого «Термінатора»: коли машина, не розуміючи нюансів комунікації, обирає фразу з випадаючого меню.
«Є список відповідей, як у першому “Термінаторі”… але краще мати це випадаюче меню відповідей, ніж зробити щось, що зруйнує розмову до того, як вона завершиться».
Таким чином, соціальна «просунутись» для нього — не стати «душею компанії», а перестати ламати розмови й відносини в критичні моменти.
Коучинг як інженерна задача: продуктивний дискомфорт замість токсичного «фідбеку»
Те, як Бек говорить про коучинг, виразно відрізняється від HR-риторики. Він не підміняє складні розмови «благополуччям» і «комфортом», але жорстко відділяє продуктивний дискомфорт від деструктивного приниження.
У його практиці коуч — це людина, яка:
- бачить, де інженер застряг — наприклад, у патерні «я завжди правий» або «я завжди відступаю»;
- формулює це прямо й конкретно;
- пропонує експеримент, що змусить учасника вийти з комфортної стратегії;
- утримує цей «продуктивний дискомфорт» достатньо довго, щоб з нього народилася нова поведінка.
При цьому верхній рівень поваги до інженера зберігається: коуч не живе його життям, не приймає рішень замість нього, але створює середовище, де відвертий погляд у дзеркало не руйнує особистість.
Цікаво, що саме такого роду дискомфорт Бек проектує й на себе. Він не раз підкреслює, що вчиться читати мову тіла, інтонацію, шукати аналогії з фінансами, спортом, історією — щоб краще зрозуміти небінарну картину світу інших людей і пояснити їм свій технічний погляд так, щоб він взагалі був почутий.
Чому м’які навички стають ще важливішими в епоху AI
На тлі бурхливого розвитку LLM і дискусій у дусі «coding is going away» Бек займає жорстку позицію: такі тези — від людей, які не розуміють, що таке інженерія. Він відділяє «написання коду» як механічний процес від ширшої діяльності, де одночасно:
- формується розуміння домену;
- вибудовується довіра до програми (через боротьбу з незнанням і перевірку гіпотез);
- росте людська довіра між учасниками команди і до користувачів.
Коли код «випльовує» модель за запитом, усе це випадає. І саме тут м’які навички несподівано стають критичними: інженер перетворюється з «людини, що пише код», на людину, яка вміє ставити питання, сумніватись, перевіряти, пояснювати ризики, домовлятися про компроміси. І робити це в середовищі, де швидкість генерації рішень різко зросла, а швидкість зміни бізнесу — не завжди.
У цьому сенсі досвід Бека з Good to Great виглядає як репетиція нового етапу в інженерії: коли найцінніший вклад senior-розробника — не в тому, щоб самому написати «найкращий» код, а в тому, щоб навчити інших проходити через продуктивний дискомфорт і конфлікти так, аби команда й продукт ставали сильнішими, а не розвалювалися.
Підсумок: межа впливу проходить через людське
У фіналі цієї лінії розмови вимальовуються кілька тверезих висновків.
По-перше, технічна майстерність залишається необхідною, але не єдина змінна. «Твоя здатність впливати на зміни у світі обмежена твоєю здатністю комунікувати, емпатувати, розуміти інших людей», — каже Бек. І особистий досвід показує: ігнорування цього веде не лише до конфліктів у командах, а й до вигорання самого інженера.
По-друге, коучинг і м’які навички — не «софтова» прикраса до хардових знань, а конкретний важіль кар’єрного зростання. У рамках однієї компанії — Facebook — можна було побачити, як системний коучинг множить шанси на промоушен і виводить людей у топ-1% інженерів.
По-третє, продуктивний дискомфорт — чесніший і корисніший інструмент, ніж комфортна брехня чи токсичний «я просто казав правду». І якщо інженерам не вистачає природної емпатії, це не привід спихувати відповідальність на світ — це запрошення поставитись до людських навичок як до ще однієї інженерної задачі, яку можна розкласти на кроки, перевірити й поліпшити.
Можливо, найбільш радикальна думка Бека полягає в тому, що тепер це — не опція, а необхідність. Світ, де код усе частіше генерують моделі, залишає інженерам поле, яке поки не здатний зайняти жоден LLM: простір довіри, конфліктів, домовленостей і рішень, прийнятих людьми. І межа реального впливу кожного з нас проходитиме саме тут.
Джерело
Повна розмова з Кентом Беком — на каналі The Pragmatic Engineer: