Techlead Skyeng Кирило Роговий () виступає на конференціях з доповіддю, в якій розповідає про навички, розвивати які варто кожному хорошому розробнику, щоб стати найкращим. Я попросив його поділитись цією історією з читачами Хабри, передаю Кирилові слово.
Міф про хорошого розробника говорить, що він:
- Пише чистий код
- Знає багато технологій
- Швидше кодує завдання
- Знає купу алгоритмів та шаблонів проектування
- Вміє відрефакторити будь-який код за Clean Code
- Не витрачає час на непрограмістські завдання
- 100% майстер своєї улюбленої технології
Так бачать ідеальних кандидатів HRи, і вакансії відповідно виглядають теж так.
Але мій досвід каже, що це не дуже відповідає дійсності.
Спершу два важливі дисклеймери:
1) мій досвід – продуктові команди, тобто. компанії зі своїм продуктом, а чи не аутсорсом; в аутсорсі все може сильно відрізнятися;
2) якщо ви джуніор, то не всі поради будуть застосовні, і я б на вашому місці поки що сконцентрувався на програмуванні.
Хороший розробник: реальність
1: Кодит краще за середній
Хороший розробник уміє створювати класну архітектуру, писати класний код, не робити надто багато багів; загалом, у нього все виходить краще за середнє, але він не входить до топ-1% фахівців. Більшість найкласніших розробників, що я знаю, не такі вже й прекрасні кодери: вони чудово розуміються на своїй галузі, але нічого супер-понад не вміють.
2: Вирішує проблеми, а не створює їх
Припустимо, що нам потрібно в проект інтегрувати зовнішній сервіс. Ми отримуємо ТЗ, дивимося доки, бачимо, що там щось застаріло, розуміємо, що потрібно передавати додаткові параметри, щось милити, намагаємося все це якось реалізувати і змусити якийсь кривий метод працювати правильно, нарешті, через пару днів розуміємо, що далі так не можна. Стандартна поведінка розробника в цій ситуації – повернутися до бізнесу і сказати: «Я зробив те й те, ось це ось працює не так, а ось то он не працює взагалі, загалом, йдіть самі розбирайтеся». У бізнесу постає проблема: треба вникнути в те, що сталося, з кимось спілкуватися, намагатися якось це дозволити. Починається зламаний телефон: "Ти скажи йому, я напишу їй, подивися, що вони відповіли".
Хороший розробник, зіткнувшись із такою ситуацією, сам знайде контакти, спишеться-задзвониться, обговорить проблему, а якщо нічого не вийде, збере потрібних людей, все пояснить і запропонує альтернативи (швидше за все, є інший зовнішній сервіс із кращою підтримкою). Такий розробник бачить проблему бізнесу та вирішує її. Його завдання закрите тоді, коли він вирішив проблему бізнесу, а не коли щось уперся.
3: Намагається витратити мінімальні зусилля, отримавши максимальний результат, навіть якщо доведеться писати милиці
Розробка софту в продуктових компаніях - майже завжди найбільша стаття витрат: розробники коштують дорого. І добрий розробник розуміє, що бізнес хоче отримати максимальну кількість грошей, витративши мінімальну. Щоб допомогти йому, хороший розробник хоче витратити мінімальну кількість свого дорогого часу для отримання максимального профіту роботодавця.
Тут з'являються дві крайності. Одна полягає в тому, що можна взагалі всі завдання вирішувати милицею, не морочитися по архітектурі, не рефакторити і т.д. Усі ми знаємо, чим це зазвичай закінчується: ніщо не працює, переписуємо проект із нуля. Інша – коли на кожну кнопочку людина намагається вигадати ідеальну архітектуру, витрачає годину на завдання і чотири на рефакторинг. Результат такої роботи виглядає чудово, але проблема в тому, що з боку бізнесу на кнопочку йде по десять годин, що в першому, що в другому випадку, просто з різних причин.
Хороший розробник уміє балансувати між цими крайнощами. Він розуміє контекст і приймає оптимальне рішення: у цьому завдання я пилятиму милицю, тому що це код, який чіпають раз на півроку. А ось у цій – заморочусь і зроблю все максимально правильно, тому що від того, що в мене вийде, залежатиме сто нових фіч, які ще треба розробити.
4. Має власну систему ведення справ, здатний відпрацьовувати у ній проекти будь-якої складності
Робота за принципами - коли ви записуєте всі справи в якусь текстову систему, не забуваєте ніяких домовленостей, всіх пушите, скрізь вчасно з'являєтеся, знаєте, що важливо, що не важливо зараз, у вас ніколи не губляться завдання. Загальна характеристика таких людей – коли з ними щось домовляєшся, ніколи не хвилюєшся, що вони забудуть; а також знаєш, що вони всі записують і не будуть ставити тисячу запитань, відповіді на які вже обговорювалися.
5. Ставить під сумнів та уточнює будь-які умови та вступні
Тут також бувають дві крайнощі. З одного боку, можна скептично ставитися взагалі до всіх вступних. Люди до тебе придумали якісь рішення, а ти вважаєш, що можна зробити краще та починаєш переобговорювати все взагалі, що було до тебе: дизайн, бізнес-рішення, архітектуру тощо. Це витрачає купу часу як розробника, так і оточуючих, і негативно позначається на довірі всередині компанії: інші люди не хочуть приймати рішення, тому що знають, що він той чувак знову прийде і все поламає. Інша крайність – коли розробник сприймає будь-які вступні, ТЗ та хотілки бізнесу як щось висічене в камені, і тільки упершись у нерозв'язну проблему починає думати, чи він взагалі займається. Хороший розробник тут теж знаходить золоту середину: намагається зрозуміти рішення, прийняті до або без нього, перш ніж завдання перейде в розробку. Що хоче бізнес? Чи вирішуємо ми його проблеми? Продакт-дизайнер вигадав рішення, але чи розумію я, чому це рішення працюватиме? Чому тим-лід вигадав саме таку архітектуру? Якщо щось незрозуміло, то треба піти запитати. У процесі цього з'ясування хороший розробник може побачити альтернативне рішення, яке до нього просто нікому не спало на думку.
6. Покращує процеси та людей навколо себе
Навколо нас йдуть купи процесів – щоденні мітинги, мітапи, скрами, тих ревью, код ревью тощо. Хороший розробник встане і скаже: слухайте, ми збираємося і обговорюємо те саме щотижня, я не розумію, навіщо, з тим самим успіхом можна було витратити цю годину на «Контру». Або: третє завдання поспіль не можу в'їхати в код, нічого не зрозуміло, діркова архітектура; можливо, у нас кульгає код ревью і треба зайнятися рефакторингом, давайте проводити раз на два тижні рефакторинг мітап. Або під час коду рев'ю людина бачить, що хтось із колег недостатньо ефективно використовує якийсь інструмент, отже, треба пізніше підійти і підказати. У хорошого розробника це інстинкт, він робить такі речі автоматом.
7. Відмінно менеджує інших, навіть якщо не менеджер
Ця навичка добре пов'язується з темою про «вирішення, а не створення проблем». Часто в тексті вакансії, на яку ми приходимо, про менеджмент нічого не написано, але потім, при зіткненні з проблемою, що не залежить від тебе, все одно доводиться так чи інакше менеджувати інших, домагатися від них чогось, якщо забули – пушити, переконуватися що вони всі зрозуміли. Хороший розробник знає, хто в чому зацікавлений, може зібрати з цими людьми зустріч, записати домовленості, скинути в слак, нагадати потрібний день, переконатися, що все готове, навіть якщо він особисто не несе безпосередньої відповідальності за це завдання, але його результат залежить від виконання.
8. Чи не сприймає свої знання як догму, постійно відкритий до критики
Кожен може згадати колегу з попередньої роботи, який нездатний йти на компроміс щодо своєї технології, кричить, що всі згорять у пеклі за якісь не ті мутації. Хороший розробник, якщо він працює 5, 10, 20 років в індустрії, розуміє, що в нього половина знань протухла, а в половині, що залишилася, він не знає в десять разів більше, ніж знає. І щоразу, коли з ним хтось не погоджується і пропонує альтернативу, це не атака на його его, а можливість чогось навчитися. Це дозволяє йому зростати набагато швидше, ніж оточуючі.
Порівняємо моє уявлення про ідеального розробника із загальноприйнятим:
На цій картинці видно, скільки пунктів описаних вище мають відношення до коду, а скільки ні. Розробка в продуктовій компанії - тільки на третину програмування, решта 2/3 до коду мають мало відношення. І хоча коду ми пишемо реально багато, наша ефективність сильно залежить від цих двох третин, що не мають відношення.
Спеціалізація, генералізм та правило «80-20»
Коли людина вчиться вирішувати якісь вузькі проблеми, навчається довго й наполегливо, зате потім вирішує їх легко і просто, але не має експертизи у суміжних сферах, – це спеціалізація. Генералізм – це коли половина часу навчання інвестується в зону своєї компетенції, а ще половина – у суміжні області. Відповідно, у першому випадку я роблю одну річ добре, а решта – погано, а в другому – я все роблю більш-менш добре.
Правило "80-20" говорить нам, що 80% результату досягаються за рахунок 20% зусиль. 80% виручки приносять 20% клієнтів, 80% прибутку генерують 20% співробітників тощо. У навчанні це означає, що 80% знань ми отримуємо за перші 20% витраченого часу.
Існує ідея: кодери мають лише кодити, дизайнери дизайнувати, аналітики аналізувати, а менеджери – менеджити. На мою думку, ця ідея токсична і працює не дуже добре. Мова не про те, що всі мають бути універсальними солдатами, йдеться про економію ресурсів. Якщо розробник хоч трохи розбирається в менеджменті, дизайні та аналітиці, він зможе багато завдань вирішувати без залучення інших людей. Якщо тобі треба зробити якусь фічу, а потім перевірити, як з нею працюють користувачі в певному розрізі, для чого потрібно два SQL-запити, то добре вміти не відволікати на це аналітика. Якщо тобі треба впиляти кнопочку за аналогією з наявними, і ти розумієш загальні принципи, ти зможеш зробити це без залучення дизайнера, і компанія скаже за це спасибі.
Разом: можна витратити 100% часу вивчення якогось навички до краю, і можна той час витратити п'ять областей, прокачавшись на 80% у кожному. Наслідуючи цю наївну математику, ми можемо за один і той же час отримати вчетверо більше навичок. Це перебільшення, але воно ілюструє ідею.
Суміжні скіли можна тренувати не так на 80%, але в 30-50%. Витративши 10-20 годин, ви помітно прокачаєтесь в суміжних областях, отримаєте масу розуміння процесів, що відбуваються в них, і станете набагато автономніше.
У сучасній екосистемі IT краще мати якнайбільше навичок і не бути в жодному з них експертом. Тому що, по-перше, всі ці навички швидко протухають, особливо якщо мова про програмування, а по-друге, тому що 99% часу ми користуємося не те щоб базовими, але точно не найвитонченішими скилами, і цього достатньо навіть у кодингу, навіть у крутих компаніях.
Ну і, нарешті, навчання – це інвестиція, а інвестиції важлива диверсифікація.
Що вчити
Так що ж вивчати і як? Типовий розробник у сильній компанії регулярно використовує:
- спілкування
- самоорганізацію
- планування
- дизайн (як правило, коду)
- і іноді менеджмент, лідерство, аналіз даних, письменство, найм, менторство та багато інших навичок
І практично жоден із цих скілів ніяк не перетинається із самим кодом. Їх треба вчити та прокачувати окремо, і якщо цього не робити, вони залишаться на дуже низькому рівні, що не дозволяє їх ефективно використовувати.
У яких областях варто розвиватись?
-
Софт-скіли – це все, що не стосується натискань на кнопки редактора. Це як ми пишемо повідомлення, як поводимося на зустрічах, як спілкуємось із колегами. Начебто всі очевидні речі, але дуже часто їх недооцінюють.
-
Система самоорганізації. Особисто для мене за останній рік це стало дуже важливою темою. Серед усіх відомих мені крутих працівників сфери IT це один із найрозвиненіших скілів: вони супер-організовані, вони завжди роблять те, що кажуть, вони точно знають, чим займатимуться завтра, через тиждень, через місяць. Необхідно будувати навколо себе систему, в якій записані всі справи та всі питання, це суттєво полегшує і саму роботу, і допомагає взаємодіяти з іншими людьми. За моїми відчуттями, за останній рік розвиток у цьому напрямку прокачав мене набагато сильніше, ніж прокачування технічних навичок, я почав виконувати значно більше роботи за одиницю часу.
-
Проактивність, неупередженість та планування. Теми дуже спільні та життєві, не унікальні для IT, і розвивати їх варто всім. Проактивність означає не чекати сигналу, щоб почати діяти. Ти саме джерело подій, а не реакцій на них. Неупередженість - вміння об'єктивно ставитися до будь-якої нової інформації, оцінювати ситуацію у відриві від власного світогляду та старих звичок. Планування - ясне бачення того, як сьогоднішнє завдання вирішує завдання на тиждень, місяць, рік. Якщо бачити перспективу далі конкретної таски, набагато простіше займатися тим, що потрібно, і не боятися з часом усвідомити, що воно було витрачено марно. Ця навичка особливо важлива для кар'єри: можна роками успішно досягати результатів, але не там, де треба, і зрештою втратити весь накопичений багаж, коли стане ясно, що рухався не туди.
-
Усі суміжні сфери до базового рівня. Конкретні сфери у кожного свої, але важливо розуміти, що, витративши 10-20 годин часу на прокачування якогось «стороннього» скила, можна відкрити для себе багато нових можливостей і точок дотику в повсякденній роботі, і цього години, можливо, вистачить до кінця кар'єри.
Що почитати
Книг про самоорганізацію безліч, це ціла індустрія, де якісь незрозумілі хлопці пишуть збірки порад та збирають тренінги. При цьому неясно, чого вони самі в житті досягли. Тому важливо ставити фільтри на авторів, дивитися, хто вони такі, і що вони мають за плечима. На мій розвиток і кругозір найбільше вплинули чотири книги, всі вони так чи інакше пов'язані з прокачуванням описаних вище навичок.
1. Дейл Карнегі «Як завойовувати друзів та впливати на людей». Культова книга про софт-скіли, якщо незрозуміло, з чого почати, вибрати її безпрограшний варіант. Побудована на прикладах, легко читається, не потребує великих зусиль для осмислення прочитаного, і набуті навички можна відразу ж застосовувати. Загалом книга розкриває тему спілкування з людьми.
2. Стівен Р. Кові «7 навичок високоефективних людей». Мікс різних навичок, від проактивності до софт-скілів, з акцентом на досягнення синергії, коли треба невелику команду перетворити на величезну силу. Читається також легко.
3. Рей Даліо «Принципи». Розкриває теми неупередженості та проактивності, заснована на історії побудованої автором компанії, якою він керував 40 років. Безліч життєвих вистражданих прикладів, чудово показує, наскільки упередженим і залежним може бути людина, як цього позбутися.
4. Девід Аллен «Як упорядкувати справи». Обов'язковим є читання для навчання самоорганізації. Читати її не так просто, але вона дає вичерпний набір інструментів для організації життя та справ, детально розглядає всі аспекти, допомагає вирішити, що саме тобі потрібно. Я з її допомогою побудував свою систему, що дозволяє завжди займатися найважливішим, не забуваючи про інше.
Потрібно розуміти, що тільки читати – мало. Можна ковтати хоч по книзі на тиждень, але ефект зберігатиметься кілька днів, а потім все повернеться на місце. Книги треба використовувати як джерело порад, які одразу ж перевіряються на практиці. Якщо цього не робити, то все, що вони дадуть – це деяке розширення світогляду.
Джерело: habr.com