Скільки можна навчатися?

Безперервне навчання є одним із сучасних базвордів. Соціологи пишуть дисертації, психологи морально готують людей, держави створюють плани зі сприяння, а компанії виділяють мільйонні бюджети на впровадження. У цьому есе я опишу, як ми реалізуємо його в Binary Studio, а далі спробую розібратися, яка в нас мотивація слідувати цьому і як це позначається на людях у результаті.

Одна з чотирьох фундаментальних цінностей Binary Studio — Student Always. Дослівно — “Завжди Студенти”, цей лаконічний вислів описує наше розуміння навчання не просто як процесу набуття знань, а радше як способу прожити життя.

Фактично навчання довгий час було в серці компанії, а саме формулювання ми запозичили в каліфорнійської бізнес-школи Haas School of Business, University of California Berkeley, яку закінчив CEO нашої компанії, Артем (здається, цей факт сам яскраво ілюструє нашу відданість навчанню, адже Артем свідомо пішов отримувати чергову освіту в 30 років).

Звичайно, цінність, записана в корпоративному буклеті, не має жодного впливу на об’єктивну реальність. Натомість, вона має бути чітко вираженою в діях.

Академія

Найяскравішим доказом нашої пріоритизації навчання є Binary Studio Academy. Ми щороку присвячуємо декілька місяців навчанню студентів.

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

Академія є навчальним проектом не тільки для студентів, але і для кожного з нас. Наприклад, за технікою Фейнмана (одного з найяскравіших фізиків 20 століття), найкращий спосіб щось насправді зрозуміти — це пояснити іншому. Так лектори отримують глибокі знання під час підготовки своїх лекцій. Ментори отримують досвід лідерства і досвід використання технологій, що не задіяні в їх основних проектах. Програмісти, що виконують роль Product Owner, щотижня проводять демо проектів Академії та мають змогу подивитися на розробку продукта з нової позиції.

ОКР

У Binary в більшості з нас є план професійного розвитку за системою OKR — Objectives and Key Results, тобто Цілі та Ключові Результати, яка широко використовується топовими технологічними компаніями — Intel, Google, Twitter. Люди визначають цілі свого розвитку: заглибитися в React, познайомитися з мобільною розробкою, розвинути лідерські навички тощо — та узгоджують їх зі своїм ментором — більш досвідченим інженером. Далі вони разом визначають, як саме вони можуть цього досягти: почитати книги, розробити пет-проекти, підготувати публічний виступ, контриб’ютити в опен-сорс. Компанія, зі свого боку, частково компенсує вартість відвідування мітапів та конференцій, купує книги, оплачує значну частину вартості сертифікацій.

ОКР переглядається щочверті: людина сама виставляє оцінку за минулу чверть, планує цілі на нову та переглядає результати з ментором — увесь процес самокерований.

Цей процес дозволяє структурувати:

а) Підхід до безперервного навчання — такий собі скрам для розвитку.

б) Менторство більш досвідчених інженерів — передачу “мудрості” з покоління в покоління.

в) Рефлексію щодо власного розвитку — чітке розуміння масштабу своїх інвестицій у навчання.

Але все ж таки...

Навіщо ми інвестуємо стільки часу в навчання?

1. Прагнемо майстерності

Перший постулат маніфеста Software Craftsmanship звучить так: “Not only working software, but also well-crafted software” — “Не тільки продукт, що працює, а й майстерно зроблений продукт”. Впевнений, що абсолютна більшість моїх колег асоціює себе з ремісниками, що підписали цей маніфест.

Робота програміста великою мірою творча — задачі, які програміст вирішує щодня, можуть суттєво відрізнятися одна від одної. У той же час інструменти і техніки, що задіяні у вирішенні задач, переважно фіксовані. Отже, мені видається, що спеціаліст має одночасно майстерно володіти цими інструментами — мовою, фреймворком, платформою — та підходами, що є здебільшого універсальними для всіх задач, як-то SOLID та функціональне програмування. Така майстерність дозволяє ефективно створювати системи, що є легкі в розумінні та надійні у використанні, базуючись на досвіді поколінь інженерів (детальніше про це ви можете почитати в статті мого колеги Макса).

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

2. Потребуємо актуальних знань

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

Окрім того, щоб підтримувати знання інструментів, що ви вже використовуєте, стане в пригоді ще й слідкувати за ринком рішень, дотичних до вашої сфери, в цілому. Місія нашої компанії — будувати програмне забезпечення світового рівня для малих та середніх бізнесів. Отже, ми беремо на себе відповідальність за якість технічних рішень, що будуть застосовані на проекті. У 2015 році до нас прийшов замовник з ідеєю десктопного додатку. Він хотів розробити його на базі найновітніших веб-технологій та запропонував платформу Electron і Aurelia в якості фронтенд фреймворку. Не впевнений, що ви чули про цей фреймворк, але тоді навколо нього був певний хайп. Ми вмовили його використовувати React, адже після дослідження Aurelia ми зрозуміли, що інструмент ще зовсім не готовий для комерційного використання — ані сталого комьюніті з опен-сорс рішеннями, ані вичерпної документації. Для цього аналізу нам потрібно було на пару тижнів цілковито зануритися в Aurelia, але воно було того варте — ми досі розвиваємо цей проект, а замовник безмежно вдячний, що ми допомогли йому вибрати відповідний інструмент (хайп навколо Aurelia згас дуже швидко).

До того ж я впевнений: щоширші і глибші знання має спеціаліст, то більш розсудливим він є — у стилі сократівського “Я знаю лише те, що я нічого не знаю”. Це сприяє відкритості до використання різних мов, технологій та підходів, а отже збільшує ймовірність прийняття раціональних технічних рішень. Відома гіпотеза Даннінѓа-Крюгера ілюструє той факт, що досвід і спеціальні знання зменшують самовпевненість людини, аж поки вона не стає експертом:

3. Керуємося допитливістю

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

Я гадаю, що допитливість — це найголовніша риса, яку ми шукаємо в інженерах (і не тільки) на співбесідах. Саме для цього ми ставимо, наприклад, такі питання: “Як влаштований async / await під капотом?”. Напевно, це не стане в пригоді під час роботи над проектом і незнання відповіді не буде мінусом, але допитливий інженер скоріше за все цікавився тим, як працюють інструкції, які він пише щодня. Здається, такий спеціаліст зможе самостійно знайти відповіді на більшість питань.

Як нам із цим живеться?

Отже, я розповів вам, як ми навчаємося і чим ми це виправдовуємо. Чи подобається це нам? Не завжди.

Бувають чверті, коли твій результат близько 0 — і це нормально, адже ти взяв паузу на подумати і відпочити. Та в інші чверті просуваєшся дуже добре і наближаєшся до 100% запланованого. Буває, що плани реалізуються самі собою, наприклад, під час Академії — адже від тебе залежить багато людей, і ти точно виконаєш обіцяне. А буває, що маєш змушувати себе вийти із зони комфорта.

Деякі з нас жваво занурюються в роботу над власним ОКР, інші — частіше прокрастинують.

Хлопці зробили внутрішній мем із відомої сцени з Сяйва:

Буває таке, що закінчуєш чверть із відчуттям задоволеності, що ти все ж таки нормально розібрався з Kubernetes. Іншого разу проклинаєш себе за те, що запланував ознайомитися з платіжними системами, адже це тобі взагалі не цікаво. Через навчання може доволі швидко настати “криза чверті життя”. Ти вже багато чого навчився, тебе важко здивувати, ти не знаєш, що робити далі та кого слухати. Проте ментори постійно шукають виклик, який є релевантним для конкретної людини конкретно в цей момент. Як ви самі розумієте, інколи їхні рекомендації досягають мети, а інколи — мимо.

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

Чи є кінець цьому навчанню? Думаю, що ні. То чи варто воно того? Мені здається, що так. Змінивши відомий політичний вислів про демократію Вінстона Черчілля: “Життя в навчанні не є ідеальним, але воно краще за всі інші сценарії життя”. [1]

Виноски:

[1] — вислів насправді не належить йому, але був ним відомо процитований.