Несправжні сеньйор-девелопери, або чому роки досвіду ні про що не говорять

Досвідчений програміст з Торонто Метт Бріггс так любить свою роботу, що каже: «я б писав код, навіть якщо б це було нелегальним». А коли він опублікував у своєму блозі пост про джуниорах, мидлах і старших розробників, то зібрав більше сотні захоплених коментарів. Ми в Alconost теж захопилися і перевели цю статтю для вас.

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

Ми відчуваємо серйозну брак талантів, хоча індустрія досить молода. Більшість софтверних проектів провалюються, і практично всі перевищують бюджет. А найкраща ідея, яку можуть запропонувати найсильніші розум, зводиться до «Є кілька стандартних способів вирішення подібних проблем, але наші рішення часто не спрацьовують. Єдине, що можна зробити — це спробувати і подивитися на результат».

Реальність така, що під «старшим розробником» розуміється людина, яка ліпить код понад 3 років. Його ставлять на керівну позицію, і зазвичай все закінчується очікувано плачевно.

Насправді, спроба оцінювати людей тимчасовими інтервалами – занадто спрощений спосіб для таких тонких матерій, як знання і професійний досвід. Але справи йдуть саме так. І якщо продовжувати класифікувати фахівців подібним чином, то саме час нашої індустрії брати тайм-аут. Є різниця між людиною з 10-річним досвідом, і тим, хто за те ж час став досвідченішим в 10 разів.


Постер з серіалу «Комп'ютерники»

Етапи зростання розробника
Як програмісти, ми живемо у світі складних систем і змінних. У цьому світі навіть просте виконання добре поставленої конкретної задачі може викликати труднощі. Особливо якщо немає величезного досвіду з наявними інструментами або базою коду.


Кадр із серіалу «Комп'ютерники»

Ось яка життя junior-розробника. Закінчивши навчання, ви здаєтеся собі всезнаючим. Але раптово приходить розуміння, що школа слабо підготувала вас до тих проблем, з якими доводиться стикатися. Реальність хаотична, не так приємна і далека від теорії. Доводиться крутитися в середовищі компромісів, без можливості будувати припущення про що-небудь.

Робота з урахуванням всього цього і буде вашим головним уроком і предметом зосередження. Молодшим розробникам потрібні регулярні настанови, допомога і підтримка. В іншому випадку, вони можуть тупцювати на місці дуже і дуже довго (недавно я зіткнувся з товаришем, який робив софт майже 10 років, але фактично залишився все тим же початківцям розробником). Можна сказати, цей період цілком присвячений пізнанню тактичних підходів до вирішення щоденних завдань.

Джуніор-розробник зациклений на коді, а не на процесі розробки. Та й різницю він не особливо вловлює. Якщо програміст каже, що «з радістю кодил б більше, якщо б не ці користувачі» — з високою ймовірністю, ви спілкуєтеся з новачком.

Хорошому junior-розробнику можна дати знайому завдання і чекати її швидкого виконання

Кадр із серіалу «Комп'ютерники»

Розробник середнього рівня вже починає бачити в помилках певні закономірності (зазвичай, у власних помилках). Він розуміє, що для написання працездатного коду, який не розвалиться при першому ж зміну, потрібно багато більше простого завершення своєї ділянки роботи. Ще він зазвичай проходить через той унікальний досвід, коли дивишся на свою минулу гордість (код однорічної давнини) і розумієш, що це повний непотріб.

Така людина вивчає питання правильної розробки софта, і знаходить для себе відповіді в експериментах, літературі та обговорення з колегами. На цьому рівні все спрямовано на вивчення теорії розробки продукту, а не написання коду (цього вчать у школі).

Написані «середніми» розробниками самостійно системи провалюються за зовсім інших причин, ніж творіння молодих фахівців. Джуніор просто напише гору умовно-робочих алгоритмів. А хороший «середній» частково втілить вміст книг «Design Patterns» і «Domain Driven Design». Звичайно, це чудові книжки для вивчення процесу розробки великих систем. Але просте слідування їх постулатам призводить до побудови надмірно складних систем, які згинання там, де це не важливо, і неповороткі в значущих речах.

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

«Мидлы» добре усвідомлюють свою роль в організації і цінність для неї. Хороші middle-девелопери також розуміють, що кодинг для вирішення проблеми означає роботу до логічного завершення, а не просто до кінця завдання. І все ж вони ще занадто захоплені будівництвом вежі з слонової кістки і пошуками «Правильного Шляху» в розробці софта.

Хороший середній розробник вимагає менше нагляду. Їм можна довіряти пошук проблемних ділянок проекту, і вони грають важливу роль в ухваленні ключових рішень. Ще вони «робочі конячки» команди, але вимагають більш високорівневого наставництва.

Кадр із серіалу «Комп'ютерники»

Старший розробник близько знайомий з власними невдачами. Такі люди створювали як недороблений, так і надміру складний код бачили плачевні результати в обох випадках. Вони виважено підходять до роботи, тверезо і спокійно оцінюючи власні удачі та поразки при виникненні проблем. Старший розробник вже розлюбив складність, яка захоплює уми «середніх» колег, і тепер одержимий простотою.

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

Senior враховує контекст при застосуванні теорії. Він розуміє, що не існує «Правильного Шляху». Єдиний спосіб побудувати хороший продукт – це адаптація теорії до вимог клієнта, бази коду, команди, інструментів і організації. Така людина розуміє, що все навколо нас вимагає компромісів, і буде шукати їх для патернів дизайну, бібліотек, фреймворків і процесів.

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

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

У той час як «середній» розробник загрузне в незліченних днями монотонної діяльності, «старший» спершу поцікавиться першопричинами ситуації. Він оцінить витрати на нейтралізацію причини, і або відразу її виправить, або направить процес у потрібне русло.

Ще він розуміє, що не можна зробити все самостійно. Його першочергова роль – допомогти команді стати краще, часто тими ж способами, якими самовдосконалюються окремі учасники. Адже сила не у владі, а в делегуванні. Не в управлінні, а в підтримці.

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

Більш того, в нашій індустрії прийнято цінувати зухвалих розумних молодих хлопців після університету. Ці хлопці дійсно цінні і необхідні, але не більше, ніж їхні колеги з 15-20 роками «польового» досвіду. Пора переставати стереотипно наймати людей і почати більше думати про команду і сполучуваності талантів. Якщо все в команді будуть думати однаково – ви зробите ведмежу послугу і проектом, і організації.

Переведено в Alconost Translations

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.