Традиційний кар’єрний шлях в ІТ виглядає приблизно так:
👶Джун
→ 🛼 Мід
→ 🤘 Сіньйор
→ 👔 ТехЛід/Архітект або податися в управління
Перша стрілка доволі очевидна та передбачає екстенсивний ріст: вивчай більше ⚙️-технологій, вдосконалюй свої навички, і буде щастя.
Проте, наступні кроки значно менше зав’язані на ⚙️-технології; там варто більше зважати на інтереси бізнесу та на аспекти управління. Звісно, технологія сама по собі залишається — але як інструмент для чогось більшого.
⚙️ Технологія як інструмент
Майже будь-яку технічну ціль сьогодні можна досягнути багатьма способами. Але який спосіб є найкращим?
Джуни та Міди, як правило, починають холіварити на тему X проти Y. А ті, хто “вже бачив деяке лайно” ©️, втомлено зітхають: it depends.
Все залежить від занадто багатьох не-⚙️ аспектів.
- Чи маємо ми ресурси ($, час) на X?
- Чи вміє наша команда робити X?
- Як це відповідає нашим планам на наступні
5 років2 квартали? - Як ми це підтримуватимемо?
Рішення, прийняті на цьому етапі, можуть виглядати ху неоптимальними — якщо дивитися виключно з виключно технічного боку. Але пройоб тут може коштувати компанії занадто дорого (втрата темпу, як конкурентної переваги, частки ринку і/або ніші; вонюча купка маргариток, а під нею лежить той фраєр, що любив експериментувати з технологіями) Як-то кажуть, no pressure at all, шановний техлід 🤭.
⚠️Warning
Іронічно, але розробнику не так погано.
Розробнику цікаво отримати додатковий навичок навіть unrelated в резюме. А воно їм згодиться, коли компанія піде боком.
Байка з життя
Компанія співпрацює з університетом: студенти роблять свої дипломні проекти на базі компанії. Це взаємовигідно: студенти отримують досвід; компанія отримує проекти. Навіть не говорячи про фінансовий інтерес.
Студенти обирають технології для своїх проектів навмання. Чому? — а чому би й ні? Вони нещодавно прочитали якусь статтю. Або їм подобається логотип технології та її спільнота.
❗ Важливо: їхні технології не є поганими! В масштабах дипломного проекту важко вибрати дійсно неправильний стек (хіба, якщо постаратися).
Студенти успішно завершують свої проекти, захищають дипломи і йдуть пиячити.
Круто?
Так, але не без ложекчи лайна. Уявіть техліда в тій компанії. Якщо студентам дати волю, доведеться інтегрувати цілий йобаний зоопарк різних версій, стеків та підходів в 10-річну кодову базу, яка підтримує пару тисяч пристроїв з десятком типів/версій по всьому світу.
👥 Люди важливіші за технології
Чим досвідченіший розробник, тим серйознішими стають задачі. На якомусь етапі масштаб задачі перевищує можливості однієї пари рук. Доведеться залучати допомогу. А разом і цим, доведеться:
- Доносити до людей свю точку зору. Обговорювати, аргументувати, погоджуватися.
Опція “ми робимо так, тому, що я так сказав/-ла” спрацює ненадовго; люди дуже швидко проголосують ногами. - Розподіляти (можливо, навіть призначати – ?) завдання.
- Планувати. Адже тепер результат залежить не тільки від well-known тебе!
Писати код — це найлегше
і найцікавіше в ІТ.
🤝 Команда важливіша за особу
Після третього реджекта пулл-реквесту через серйозні архітектурні косяки, виникає думка про те, як уникнути цього в майбутньому.
В гру вступає навчання та тренування команди. Це не так просто, як здається. Бути хорошим виконавцем ≠ бути хорошим вчителем. Радше навпаки: професіонал, захоплений своєю справою, часто ігнорує решту людей.
Насправді ми любимо відчуття потоку. Але є ціна: ми ігноруємо зовнішній світ та віддаляємося від нього.
Скільки разів ви ловили себе на думці
“Краще зроблю це сам(а); це буде швидше, і якісніше.”
Ось така хуйня, малята ©️. А тепер це обов’язок. На якомусь етапі розвиток кумулятивних навичок всієї команди стає важливішим, ніж прокачування власного перса. Незважаючи на те, що індивідуальний ріст швидший і, що, сука, характерно, цікавіший, команда досягне більшого в перспективі.
Колись мене запитали мене про мову та інструмент, який я використовую на роботі. Я відповів: TypeScript та WebStorm “Markdown та Confluence”. Тоді я зрозумів, що Рубікон перейдений.