Від Еріха Фромма до Кента Бека. 5 книжок для розвитку soft і hard skills

Start With Why by Simon Sinek

Російською — «Найди свое почему» Саймона Синека

Що відіграє найбільшу роль у тому, досягне людина успіху в житті чи ні? Це не знання і не талант. Знання застарівають. Талант не реалізується, якщо він не поєднується із зусиллями. Найголовніше — звички та наш спосіб мислення. Бо саме вони залишаються з нами на все життя і визначають, чи ми мотивовані, чи вчимося та розвиваємося, чи відкриті до нових можливостей, чи прагнемо до чогось. І, врешті-решт, саме це й визначає, наскільки людина реалізується. Тому я починаю свою добірку з книги, що розкриває найбільш важливий, як на мене, принцип мислення — Start with Why.

Книга Саймона Сінека розкриває принцип Start with Why з погляду лідерства та мотивування людей. Хочеш надихнути когось на щось, розкажи, навіщо (Why) це потрібно. Бачення майбутнього, що стане кращим завдяки твоїм діям — ось що мотивує, об’єднує та веде до успіху.

Історії великих людей та компаній починалися з Why. У Мартіна Лютера Кінга це була його відома промова I have a dream. В Apple — їхній відомий слоган Think Different. Саме ця візія стала основною причиною їхнього успіху.

Основна ідея з книги: «People don’t buy WHAT you do; they buy WHY you do it».

Хоч автор акцентує на Why — на меті, ідеї, баченні, але не оминає і How та What. Це наступні питання, що йдуть за Why. Разом вони формують Golden Circle — фреймворк, рекомендований для лідерства, ухвалення рішень і мотивації.

• Why — навіщо щось робити? Яка є проблема? Бачення кращого майбутнього, мета.
• How — як цього досягти? Як треба змінити світ, індустрію, підхід тощо, щоб реалізувати мету.
• What — що треба для цього робити?

Для мене принцип Start with Why йде набагато далі, ніж ті сфери, що описані у книзі:

• Коли я працюю з клієнтами, я завжди запитую, навіщо виконувати ту чи іншу задачу, кому і навіщо потрібен продукт тощо. Коли я розумію це, перетворююсь з виконавця на партнера, який разом з клієнтом досягає спільної мети. Клієнти це відчувають і люблять працювати зі мною через такий підхід.
• Коли я вибираю технології для втілення проєкту, я чітко знаю, чому та чи інша технологія найкраще для нього підходить.
• Коли я дізнаюсь про нову трендову технологію, завжди цікавлюся: чому вона стала такою популярною? Навіщо саме її використовувати? Для яких сценаріїв вона краща за інші?

Загалом звичку запитувати «Чому» та «Навіщо», мислити схожими категоріями можна описати одним словом — «допитливість» (curiosity). Нещодавно Адам Браянт під час написання своєї книги Corner Office провів опитування 700 успішних CEO і поставив усім однакове питання «What qualities do you see most often in those who succeed?». Відповідь була — curiosity (допитливість).

І я теж вважаю допитливість ключовою рисою будь-якого гарного спеціаліста: розробника, PM, QA, тощо. Серед тих фахівців, з якими мені доводилось працювати, допитливі люди, що копали глибше, намагались краще зрозуміти і ідею клієнта, і технології, були набагато успішніші за менш допитливих, які працювали тільки в межах поставлених задач.

Тому я вважаю Start with Why одним з найважливіших принципів, а однойменна книга — #1 у моєму списку.

The Art of Loving by Erich Fromm

Російською — «Искусство любить» Эриха Фромма

Українською — «Мистецтво любові» Еріха Фромма

Друга позиція в моєму списку — несподівано — про любов. The Art of Loving, або «Мистецтво любити» — це фундаментальна психологічна та філософська книжка, що на 100 сторінках у досить стислому вигляді дає стільки істин та інсайтів і відповідає на стільки питань, що я повертався до неї та перечитував тричі. Вона значно глибша за любовні романи й зачіпає не тільки тему любові між чоловіком і жінкою, а й питання стосунків між людьми загалом, цінностей, щастя, мотивації. Тому ця книга вплинула навіть на моє професійне життя.

Хоча кожна сторінка «Мистецтва любити» може бути розібрана на цитати й варта окремої дискусії, тут наведу всього кілька ідей з книги. Тих, що я використовую у професійному житті.

1. Людині потрібна єдність із соціумом, бо самотність веде до почуття слабкості та тривожності. Самотність — це мука, тортура, найбільша кара (вигнання чи карцер). Щастя полягає у позбавленні від неї (у прийнятті, реалізації). Є різні методи для цього, але всі вони неповноцінні, мають недоліки. А єдиний спосіб, що веде до повного позбуття самотності та щастя — це любов.

2. Любов може бути не тільки між чоловіком і жінкою. Любов — це насамперед не стосунки з однією людиною, а стан душі, ставлення, орієнтація характеру, що визначає відносини людини з цілим світом, а не з одним об’єктом любові. Неможливо любити когось одного і водночас не любити нікого більше. Тоді це не любов, а симбіотична залежність.

3. Любов — це передусім «give, not receive» (віддавати, а не отримувати). Але give (давати, ділитись) не означає бути позбавленим чогось, не означає жертвувати. Так це поняття сприймають люди, які вміють лише експлуатувати, спрямовані переважно на receive (брати, отримувати). Якщо така людина віддає і не отримує нічого натомість, почувається обманутою. Саме тому вона боїться віддавати й фактично не вміє любити.

Для зрілої продуктивної людини give — це найвище вираження можливостей. У процесі віддавання відчуваєш свою силу, багатство, владу. Це наповнює, дає радість. «Віддавати» дає більше насолоди, ніж «отримувати». Віддавати означає бути багатим. Багатий не той, хто багато має, а той, хто багато дає. Скупий (у психологічному плані) є бідним, незалежно від того, скільки він має.

4. Окрім giving, любов охоплює турботу, відповідальність, повагу, знання. Любов — це усвідомленість і відповідальність: «Stand in love», not «fall in love». Любов — це й повага: прийняття іншої думки, визнання особистих кордонів.

5. Любов і праця нероздільні. Люблять те, заради чого трудяться. І трудяться заради того, що люблять. Любов — це активність: «action», not «passion». А точніше, це активний інтерес до іншої людини та до світу навколо. Неможливо проявляти активний інтерес, якщо ти лінуєшся, якщо не перебуваєш у постійному стані усвідомленості, уважності. Сон — це єдина ситуація, що допускає неактивність. В інший час лінощам не має бути місця. Активна діяльність, допитливість, розвиток — ось що робить тебе цікавою людиною. І це і є основа того, щоб бути цікавим і продуктивним у всіх сферах життя. Зокрема і в любові.

The Art of Game Design: A Book of Lenses by Jesse Schell

Російською — «Геймдизайн. Как создать игру, в которую будут играть все» Джесси Шелла

Слово «гра» дуже по-різному сприймають люди. Хтось вважає, що ігри — це весело, захопливо та навіть корисно. А хтось ставить їх в один ряд з алкоголем і наркотиками, вважає причиною жорстокості та насильства. Або твердить, що від ігор люди тупіють.

Якби це справді було так, як вважають другі, рівень штучного інтелекту не порівнювали б з рівнем людського інтелекту за грою в шахи або Го. Країни не змагалися б за свій престиж в Олімпійських іграх або у футболі. Як писав Ерік Берн у книзі «Ігри, у які грають люди», люди постійно грають в ігри й часто навіть не усвідомлюють цього. Діти вчаться через ігри. Компанії використовують ігрові механіки, щоб збільшувати лояльність клієнтів. А побудова кар’єри та шлях до успіху — це, мабуть, найпопулярніша гра сьогодення :)

То що таке ігри? І як їх створювати? На ці та інші питання відповідає книга Джессі Шелла The Art of Game Design. Альтернативна назва — The Book of Lenses. І ця книга побудована саме на метафорі лінз. Кожна «лінза» у книзі — це окрема перспектива, погляд на ігри. Ось лише декілька з цих «лінз»: емоції, досвід, здивування, розваги (fun), допитливість, задоволення, «потік», мотивація, цілі, правила, виклик або змагання (challenge), нагорода, покарання, баланс, крива інтересу (interest curve), перешкоди, свобода, дружба, самовираження, любов.

Ці слова, звичайно ж, не нові для нас. І все це складові ігор та емоції, що можна викликати за їх допомогою. А також це складові нашого життя. Гра ж, як видно із книги — поєднання усіх цих знайомих речей, що приносить задоволення, надихає працювати над собою та ставати кращими. Ігри — надпотужний інструмент. Це ключ до нашого фокусу, мотивації та навіть щастя. І доки ігри робить хтось інший, а ми в них тільки граємо, хтось інший контролює те, що нам цікаво та що приносить задоволення. Коли ж ми починаємо розуміти, як самим створювати ігри та робити речі цікавими, тоді отримуємо більше контролю над своїм життям, можемо зробити цікавим те, що справді важливо для нас, і вивільнити величезну кількість енергії для досягнення власних цілей. А також залучити інших до наших ідей.

Колись я обрав цю книгу, бо розробка комп’ютерних ігор — один з напрямів, у якому я працюю. Вона допомогла мені краще збагнути, як створювати успішні ігрові продукти. Але видання буде корисне не тільки тим, хто запускає ігри. Багато уваги тут приділено тому, як «слухати» користувачів, як проводити дослідження, як робити продукт саме для когось, а не для себе. Як вигадувати ідеї, розвивати творчість, де брати натхнення. Ці навички корисні для будь-яких представників творчих професій та ІТ.

Test Driven Development: By Example by Kent Beck

Російською — «Экстремальное программирование: разработка через тестирование» Кента Бека

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

Одна з найважливіших навичок для розробника — це вміння так писати код, щоб його було легко розуміли інші, легко підтримували та тестували. А найкращий спосіб це зробити — написати його за підходом TDD (Test-driven development).

Цей підхід працює так:

1. Перед тим як зробити зміну в коді, треба написати юніт-тест. Запустити його і побачити, що він завершується із помилкою (адже функціонал ще не зроблений).
2. Реалізувати маленьку, атомарну зміну у функціоналі, для якої був написаний тест.
3. Запустити юніт-тести й побачити, що тепер тест завершився успішно.

Цей процес виконується для кожної атомарної зміни у коді та повторюється багато разів протягом розробки продукту.

Багато розробників скептично ставиться до такого підходу. Адже, схоже, з ним треба писати більше коду, а це займає більше часу. Але це так лише для маленьких проєктів. Якщо проєкт середнього чи великого розміру з відповідними командами, то набагато більше часу йде на вирішення проблем, пов’язаних із непорозуміннями між розробниками у тому, як працює той чи інший функціонал. Або з тим, що один розробник зламав код іншого. Чи просто з поганою архітектурою та накопиченим технічним боргом. І юніт-тести економлять цей час, адже вони є одночасно і перевіркою на регресії, і документацією для розробників, і гарантією, що архітектура коду гарна. Адже гарна архітектура — це та, де різні частини програми можна тестувати окремо одна від одної (що і досягається за допомогою юніт-тестів).

Звичайно, до написання коду за цим підходом треба звикнути. Тому я і рекомендую книгу Кента Бека. У ній не тільки розписана теорія, а й багато практики. Із програмним кодом і поясненнями. Якщо повторювати самостійно ті дії, що робить автор, та стежити за ходом його думок, можна швидко зрозуміти, як це — писати код за TDD, та виробити у себе таку звичку.

Так вийшло, що я прочитав цю книгу, коли займався переважно розробкою ігор на Unity. У гейм-розробці TDD не популярний, використовується рідко. Переважно через те, що візуальні речі складно тестувати за допомогою юніт-тестів. Але у той час ця книга дала мені розуміння, які патерни варті уваги, а які є, по суті, «антипатернами». Та як будувати підтримувану архітектуру програмного коду.

Суть дуже проста. Хороша архітектура — це «незв’язна» архітектура. Та, при якій можна тестувати частини коду окремо одна від одної. І де зміни одного модуля не впливають на роботу іншого. Через це розуміння я практично відмовився від деяких патернів у своєму коді, наприклад Singleton або Service Locator, і віддав перевагу іншим, як-от Dependency Injection та ECS (Entity Component System).

Уже пізніше я почав користуватися TDD на практиці. Уперше — 2015 року для написання плагіну LINQ to iOS на Unity Asset Store. Цей підхід допоміг мені зробити стабільну бібліотеку у нестабільних умовах. Тоді Unity-ігри та застосунки падали на iOS під час застосування стандартного LINQ у C# через особливості компілятора Mono. І причини не були задокументовані. Завдяки юніт-тестам, методом спроб і помилок мені вдалося реалізувати бібліотеку з абсолютно ідентичним функціоналом, яка працювала на iOS.

Тепер ми розробляємо не тільки ігри, а й веб- та мобільні застосунки на Python (Django, Flask) та JavaScript (React, React Native, Vue, Node). І на веб-проєктах активно впроваджуємо TDD. Навіть в іграх ми почали використовувати його для серверної ігрової логіки та ігрових правил, адже це покращує якість продуктів та економить час на тестування та відладку.

Dependency Injection in .NET by Mark Seeman

Російською — «Внедрение зависимостей в .NET» Марка Симана

Dependency Injection — це один з найпопулярніших патернів у комп’ютерному програмуванні, що дає змогу писати «незв’язний код» — такий, де різні частини (чи модулі) програми можна тестувати окремо одна від одної й де зміни в одному модулі не впливають на інші модулі. Його часто використовують у парі з TDD.

У багатьох сучасних фреймворках Dependency Injection уже вбудований. Наприклад, у Spring, ASP.NET Core та Angular. В інших випадках використовують окремі бібліотеки, які ще називають DI Container. Для більшості розробників Dependency Injection — це «магія», що працює за допомогою DI-контейнера. А він, своєю чергою, якимось магічним чином додає залежності у компоненти програми.

Проблема в тому, що без розуміння теорії можна написати заплутаний код навіть із DI-контейнером. І я бачив багато такого коду на практиці.

Колись книга Марка Сімана допомогла мені глибоко розібратись у тому, що таке Dependency Injection насправді, як його використовувати. І навіть як використовувати Dependency Injection без DI-контейнера!

Книга написана досить розлого... Істини про DI поєднуються з думками автора про кулінарію та іншою філософією. Тому довелося набратися трохи терпіння, щоб її прочитати. Але коли я її завершив, пазли склалися!

Довгий час я думав над тим, як краще будувати архітектуру коду. Пробував різні підходи. Писав проєкт, а потім у кінці хотілось переписати його з нуля :) А тоді знову по колу. Коли ж я розібрався у деталях DI, то збагнув, що можу писати програми будь-якого розміру й робити це так, щоб код можна було легко розуміти, тестувати та підтримувати.

Після цього було багато нових відкриттів. Але TDD та Dependency Injection — це та основа хорошої архітектури, яку я рекомендую вивчити кожному розробнику.