Куди котиться вектор розвитку IT-інженерів? Або просто про наболівше

Всім привіт! Мене звати Гліб, і я ідентифікую себе як Front-End інженер. У мене було чотири роки командної розробки, щоб трохи побарахтатися в цій індустрії і трохи зрозуміти, що до чого.

Перш за все, хочу повідомити, що я вперше пишу щось подібне, і за стіною від мене сусід вже шосту годину свердлить стіну. Тому в цьому топіку деякі речі можуть здатися доволі різкими чи просто суб’єктивними. У будь-якому випадку, вставлю це тут: «Всі персонажі вигадані, і будь-яка схожість з реальними людьми або подіями є випадковою». Зі вступом закінчили, можемо рухатися далі.

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

Ситуація: від PM-a до інженера спускається тасоска в Jira. Інженер вперше в житті її читає, перетягує до колонки «In progress», звідти в інші колонки і зрештою в колонку «Done».

1. Чи вирішує ця таска бізнес-проблематику?
— Можливо.
2. Чи розуміє цю бізнес-проблематику інженер?
— Скоріш за все, ні. Скоріш за все, він взагалі не знає, для кого і для чого це робилося з точки зору бізнесу.
3. Чи професійний цей інженер?
— Ні. Це просто кодер, яких багато.
4. Але ж він знає прототипи і знає про всі 3 тисячі методів, як можна відцентрувати блок в HTML/CSS.
— Тоді це професійний інженер. Він же має такі глибокі концептуальні знання!
5. І він професійний інженер, навіть при тому, що він ніколи не використовував всі ці речі?
— Так, це професійний інженер!
6. І навіть при тому, що він запитав всі ці речі за 10 хвилин до співбесіди у GPT?
— Так, це професійний інженер!

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

Хто такий IT-інженер? Тепер зупиніться після цього речення і дайте собі відповідь.

На мою думку, IT-інженер — це людина, яка в першу чергу розуміє бізнес-проблематику. Під бізнес-проблематикою я маю на увазі такі питання: Що відбувається з бізнесом? Що робить цей бізнес? Куди він рухається? Яку проблематику вирішує нова бізнес-вимога від PO?

Якщо інженер може відповісти на ці питання, то це цінний кадр у бізнесі. І це вірно! Коли я входив у IT, то всі завжди казали, що інженер повинен бути не просто кодером. І це теж вірно! Але зараз всі ці цінності помінялися на периферійні цінності. Під периферією я маю на увазі, наприклад, технології.

До цієї теми ми повернемося трохи згодом, але зараз я хотів би продовжити свою загальну думку. Коли змінюються цінності, то змінюється і вектор розвитку. Інженери зараз фокусуються не на тих речах, які дійсно потрібні для інженера. Навіть якщо брати чисто технічну експертизу, то на співбесідах все рідше можна почути питання про ООП, архітектуру, патерни, підходи. Сучасні «сеньйори» навіть не чули про книги дядюшки Боба чи Еріка Фрімена, зате вони дивляться сучасних IT-блогерів, які якраз і впливають на зміну цього вектору своїми (дуже часто сумнівними) курсами і підходами в них.

Розкриваючи далі тему бізнес-проблематики, задайте собі питання: Як ви підходите до реалізації певного завдання? Якщо перше, що вам прийшло на думку, це те, як ви будете писати код, то у мене для вас погані новини.

Уявімо такий приклад: до вас як до інженера прийшов PO чи PM і каже, що треба додати певну фічу до існуючого модуля. Ваші дії?

Ось мої дії: я буду задавати питання, а потім знову задавати питання.
— Навіщо зараз це робити? Яку проблему вирішує ця фіча?
— Це core фіча?
— Як ця фіча повинна корелюватися з іншими фічами?
— Для якої категорії користувачів ця фіча?
— Як ця фіча повинна себе поводити в специфічних ситуаціях?
— Який вигляд повинна мати помилка при невдалому виконанні фічі?

Цей список питань можна продовжувати довго, і далеко не у всіх випадках доцільно задавати всі ці питання. Проте я хотів показати, що всі ці питання важливі, і всі вони не пов’язані з конкретною імплементацією (тобто з кодом). Можу з упевненістю сказати, що на фоні всіх технологій не буває дійсно складних задач на імплементацію. Зараз складність задачі визначається якраз-таки складністю бізнес-процесів, вкладених у цю задачу.

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

Для себе я виявив одну ознаку, яка дуже добре відповідає на те, чи впоралися ви зі своєю експертизою, чи ні. Це коли ви чуєте у відповідь на свої запитання таку фразу: «Ohhh, yes, it is really good question. I must investigate this addition.» Це означає, що ви надали дійсно цінну експертизу.

На цьому моменті я буду завершувати тему бізнес-проблематики. Для мене вона є визначальною у питанні оцінювання професійності інженера.

Але далі я хотів би розкрити тему технічної експертизи інженера і не панацеї під назвою технологія. Технічна експертиза інженера, як на мене, є набагато менш важливим аспектом, ніж бізнес-проблематика, але вона все одно важлива.

Якщо подивитися на сучасні методики вивчення програмування, то ми побачимо, що вони вчать кодити, але не вчать кодити правильно. Всі забули, що таке патерни і чому їх важливо використовувати, всі забули, що таке якість, всі забули, що таке взагалі код. Кожен самопроголошений IT-вчитель ліпить якісь свої нові підходи, а потім несе це в маси. Сеньйори вже не сеньйори, а на ринку все частіше почали з’являтися позиції типу «principal engineer», щоб хоч якось підняти планку кандидатів. Компанії почали розуміти, що краще найняти трьох джунів, ніж одного сеньйора, тому що різниця в якості не буде сильно критичною.

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

Воно і не дивно, так як у нас градація інженерів визначається тим, чи знає інженер прототипи, контекст, проміси чи ні. Всі знають, що проходити співбесіду і працювати на реальному проекті — це взагалі різні речі. Але ж ця проблема не закінчується тільки на співбесідах. Інженери дійсно позабували основні концепції програмування. І як на мене, це відображається навіть на технологіях. Ви бачили, що презентують Next.js в своїх останніх версіях? Я вам дам картинку.

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

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

1. Чи потрібні прототипи в 2024?
   — В 99% випадків — ні, не потрібні.
2. Чи треба їх знати?
   — Ну, бажано було б.
3. Чи визначає це професіонала?
   — Чи визначає професійність хірурга те, що він може зробити операцію з закритими очима?
   — Ну, мабуть, що він професіонал, але це дійсно та професійність, яка вам потрібна?
   — Ви збираєтесь пропалити цьому хірургу очі і поставити за операційний стіл?
   — Якщо ні, то це не визначальний фактор.

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

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

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