3 речі, що псують програміста

Головне

• Трикутник «швидко / якісно / дешево — обери два» всі приймають як аксіому, а він ставить його під сумнів: можливо, можна мати всі три — якісний код часто і дешевший, і швидший у розробці (залежить від масштабу; обіцяє окреме відео).
• Чому поганий код шкодить програмісту, а не лише бізнесу: у сеньйорів є інтуїція — вони відкривають незнайомий код і, ще по-справжньому не читаючи його, ставлять правильні запитання й передбачають, де будуть проблеми, просто побачивши абстракції. Цей «нюх» на запах коду виробляється роками написання доброго коду. Якщо постійно писати сміття, перестаєш його відчувати і ніколи не розвинеш інтуїцію, яка й робить розробника вищого рівня (якість коду, кар'єрне зростання).
• Його означення якості тут — явно не перфекціонізм і не стійкий до навантажень, повністю покритий тестами код: якісний код — це код, який не заважає себе розширювати: пишеш трохи зараз, додаєш ще потім, додаєш тести — і абстракції продовжують працювати, а не летять на смітник.
• Приклади догматизму, які він назбирав: в українському фронтенд-чаті твердили як абсолют, що «використовувати props у getInitialState — антипатерн», — тоді як документація React казала, що це антипатерн за певних умов, і важать саме причини, а не синтаксис (глибоке вивчення основ).
• Догма моків у TDD: люди вирішили, що TDD означає юніт-тести, а юніт-тести означають мокати все в ізоляції. Він відсилає до розмов "Is TDD Dead?" (Кент Бек, Мартін Фаулер, DHH — посилання під відео), де Кент Бек — який, власне, і винайшов TDD та написав книгу — каже, що майже ніколи не мокає і мокає якнайменше. «Люди просто вирішили, що має бути так».
• Та сама історія з Ґреґом Янґом та event sourcing: Янґ сам каже, що показав на конференції приклад, а всі канонізували його як єдиний спосіб — події не обов'язково обробляти саме так (він також зауважує, що Redux — споріднена ідея). І патерни проектування (GoF, Фаулер): патерн — не сакральне знання, а класифікована назва того, що спрацювало в багатьох людей; суть — у проблемі, яку він розв'язує, а не в еталонній реалізації. Best practices існують, щоб ви не писали жахливо поганий код, а не щоб вийшов найкращий — якщо розумієш причини, що стоять за практикою, можеш свідомо її порушити (проектування ПЗ).
• Його формула всієї цієї хвороби: люди читають щось і вірять у це замість розуміти — віра в програмування замість розуміння програмування. Зважуйте все (включно з його власними відео) на власному досвіді.
• Зневага до колег вмикається саме тоді, коли починаєш почуватися крутим: завжди будьте готові вислухати менш досвідчених колег — вони нерідко пропонують краще рішення, ніж ваше. Геніальний одинак, який допомагає людям навколо, створює значно більше, ніж будь-коли зміг би сам, і саме таке лідерство відкриває більші проєкти. У Google (де він працює) це базова цінність — люди надзвичайно кваліфіковані, але завжди відкриті до вашої думки, і в такій команді «можна будувати те, чого ніколи не збудуєш сам».