Про [псевдо]сіньйорів

by Sergii Gulenok

Час від часу мені на очі попадаються всякого роду оголошення про щодо программістських вакансій. І є одна річ від якої у мене завжди смикається око: це вакансії типу Senior C++/Java/ASP.Net/React/... (десятки їх) Developer.

От мене напрягає сам факт "сеньйорності" у вузькій спеціалізації. Як на мене, там максимум може стояти узагальний напрямок дільності. Backend, frontend, mobile, AI, game, тощо... Не факт, що навіть це має першочергове значення, але в такому розподілі є раціональне зерно. У фіксації стеку технологій його практично немає.

Весь мій скромний більш ніж 10-річний досвід роботи в сфері розробки ПЗ підказує одну річ. Якщо людина — Senior XXX Developer (де XXX — певна мова або стек, знання якого ексклюзивно домінують над всіма іншими), то це взагалі не senior. Справа в тому, що senior — це такий рівень, коли розробник має розв'язувати проблеми, а не виконувати задачі. Він має займатись інженерною діяльністю.

Інжене́рія (від лат. ingenium — здібність, винахідливість; син. — інжиніринг, рідше вживають «інженерна справа», ще рідше «інженерство») — галузь людської інтелектуальної діяльності по застосуванню досягнень науки до вирішення конкретних проблем людства. Це реалізується через застосування як наукових знань, так і практичного досвіду (інженерних навичок, умінь) до створення (перш за все проектування) корисних (найчастіше технологічних) процесів та технічних об'єктів, що реалізують такі процеси.

Вузька спеціалізація, ну... не допомагає цьому взагалі. Як мінімум у наступних аспектах.

По-перше, є теза Авраама Маслоу, більш відома як "закон інструмента", або "золотий молоток". Він звучить приблизно так: "Коли у вас є лише молоток, то навколо ви побачите одні гвіздки." Я з різними людьми і різними проектами надивився багато цікавих речей, які підтверджують цю тезу :) Наприклад, я бачив що буде, коли досвідчені C++ розробники з багаторічним досвідом вперше пишуть на діалекті JavaScript. Або перший проект професійного Wordpress-розробника з використанням Laravel. Чи треба казати, що в обох випадках результат схожий на продукт їх колишнього досвіду, і вельми далекий від кращих практик для нового інструменту? Але "винуватим" в тому, що написане лайно звісно ж був поганий JS, або Laravel :) В той же час, якби C++ програмісти зверстали хоч раз одну просту сторінку з використанням сучасних методів frontend розробки, а PHP розробник мав досвід роботи з будь-яким іншим сучасним web фреймворком, то результат був би на порядок кращим.

По-друге, щоб вирішувати інженерні задачі, треба накопичити певний багаж знань. І знову ж таки, тут широкий кругозір важить набагато більше, аніж глибина. Ефект стояння на плечах у гігантів: ми будуємо нові рішення на основі попередніх. Чим більше ми бачили різних практик та підходів, тим більший технічний арсенал, на основі якого можна будувати нові рішення. Такий же підхід сповідує, наприклад, Елон Маск.

Важливо розуміти, що senior розробник — це не той, хто може вирішувати всі проблеми без використання stackoverflow.com. Він хоча б приблизно бачить цілісну картинку того, що має бути в результаті. Як реалізувати концепт в рамках певної технології він може і не знати на початку роботи. І так, вони теж копіюють рішення з stackoverflow. Але з однією особливістю: вони розуміють як і чому це працює [1].

Коли знання будуються на основі ідей та концептів, а не їх часткових реалізацій, то будь-який код сприймається ось так:

К/ф "Матриця"

Саме до цього треба прагнути і це є ознакою крутого розробника.

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

Працедавцям не завжди потрібні інженери. Принаймні в таких об'ємах. Особливо це стосується аутсорсу та всякого роду великих проектів підтримки. Для побудови будинку вам не потрібна команда виключно з архітекторів і прорабів, вам треба робочі — каменщики та штукатури. Це нормально. Тут питання виключно ваших персональних пріоритетів. Якщо ви все життя будете класти цеглу, то через 5-10 років ви будете класти її швидше за інших, але навряд ви самостійно зможете спроектувати і побудувати будинок. Вас це влаштовує? Ну тоді ок.

Спеціаліст, звісно, може більш ефективно вирішувати якісь проблеми у його спеціалізації. Але в моїй практиці це ніколи не було того варте. Найбільш показовий випадок був, коли команда довго не могла вирішити проблему з падінням аппки у одного з клієнтів. Задача кочувала з рук в руки, "універсалісти" по кілька тижнів не могли докопатись до джерела проблем. Поки задача не попала до "спеціаліста", який за кілька днів знайшов проблему та виправив. При цьому той самий "спеціаліст" потім був найбільшим головним болем на наступному проекті, коли задачі потребували навичок практичного вирішення нових проблем (читай придумувати речі, яких раніше не існувало), а не знань тонкощів роботи C++.

Якщо ж у вас стартап чи продуктова розробка, а у вас більше половини розробників це "робочі" — буде скрутно. Коли у вас їх взагалі немає (і я кажу про senior по духу, а не за "личкою"), то вам просто дупа. Я зі сторони спостерігав як одна команда втратила справжнього senior'а, замінила двома типу "java архітекторами" зі здається 8+ річним стажем, а на попередню ефективність так і не вийшла. Тим часом senior (дівчина, до речі) перейшла в іншу компанію вільно змінивши Java стек на Python, який бачила вперше.

У Річа Хікі (автора мови Clojure), є чудова доповдь "Гамако-орієнтоване прогамування". Воно не про програмування взагалі, а про те як налаштувати мозок на вирішення інженерних задач. Хто читав "Прагматичне мислення та навчання" Енді Ханта, то там особливо нічого нового — основні думки схожі. Але в доповіді є чудовий фрагмент, який я зацитую:

... як людські істоти ми досягаємо успіху в тому, чим ми займаємося. Неважливо в чому саме. Є неймовірні приклади, коли люди займались речами, до яких у них не було хисту. Але тим не менш вони досягали успіху, тому що постійно практикувались. Якщо ви будете практикувати навчики вирішення проблем, ви начитесь ефективно їх вирішувати. Якщо ви будете практикуватися у методології Х, ви навчитесь ефективно використовувати її. Але я хочу вас спитати: як ви думаєте, що дасть вам більший важіль? Мені все одно що це за X. Обирайте будь-який. То ви краще будете шарити Х, чи мати прокачаний загальний навчок вирішення проблем?

P.S. Взагалі я починав писати про інше, але пролог до того дописувиріс в окремий :)

  1. В моїй улюбленій книжці з прогамування, "Програміст Прагматик" (The Pragmatic Programmer: From Journeyman to Master), є чудова глава "Programming by Coincidence". Її назву як можна перекласти як "Програмування на "авось". Так от, справжні сіньйори так не роблять :) ↩︎