Чому з’являються вакансії $7500 і вище — три причини
В мене є товариш, який не вірить в те, що толковий сеньйор реально може заробляти більше 3k на руки. Кажу, подивись, на Джині не встигають додавати фільтри по зарплаті, а тут і на DOU вийшла стаття про найм в $15 000.
І для свого друга, і для вас хочу поділитись своїм баченням, чому так сильно зростає верхня планка на девелоперів.
По-перше, звісно, великий вплив стався завдяки чому? Правильно.
1. Пост-ковідний попит
Є таке поняття — «чорний лебідь». Це поняття, яке ввів фінансист-нонконформіст Нассім Талеб в однойменній книзі, означає важкопрогнозовані та рідкісні події, котрі мають значні наслідки (як, наприклад, розвал Радянського союзу або атака 11 вересня).
Рік 2020 був багатий на такі події — там і чорний лебідь, і чорна щука, і чорний рак. Цей рік був настільки прибацаний, що про нього зняли окремий фільм «2020, тобі кінець!» (раджу подивитись).
І ось, коли у лютому
І що показав ковід? Ковід показав, що виживання світового бізнесу — це функція, яка залежить від діджиталізації бізнесу, тобто наскільки в ньому процеси піддаються автоматизації. Якщо компанія існує тільки за рахунок офлайн-процесів, то їй швидко настає кінець (наприклад, туризм, концерти та ресторани — прощавай, моя улюблена Libraria у Львові). А якщо компанія змогла хоча б частину процесів перевести на онлайн + доставку, то в неї був шанс залишитися на плаву.
Це перший аспект — зріс попит на автоматизацію.
Другий аспект — відкладений попит компаній-замовників: так, вони поставили проекти на паузу під час ковіду, побоюючись ризиків, але необхідність реалізації проєктів не зникла.
Знайомий британський Delivery Manager коментує: «У вас різко виросла географія найму: якщо всі ремоут, то немає сенсу обмежувати себе країною/ штатом. Це стосується України, тому що ви отримали додатковий прямий попит з інших локацій». І це третій аспект.
Попит на реалізацію проектів та загальну діджиталізацію привів до того, що як тільки ситуація з ковідом стабілізувалась та шок пройшов, замовники кинулись замовляти, а IT-компанії знову почали швидко наймати девелоперів — і почалось змагання за таланти.
Десь з травня
В серпні
Я вважаю, так виглядає битва за мізки — компанії намагаються найняти досвідчених топ-перфомерів, а оскільки їх кількість обмежена, це стало змаганням з постійним підвищенням ЗП.
Але є ще дві причини, чому зараз ЗП поступово піднімаються — я вважаю, це тому, що стрімко зростає складність коду.
Ні, я маю на увазі НЕ цикломатичну складніть алгоритмів (умовно, це скільки у вас IF в коді — тобто, скільки шляхів логіки є у вашого юніту коду — чи це проста лінійна програма, чи розгалужена складна логіка). Проблема не в цьому.
Я маю на увазі комплекс двох причин в цілому в світовій індустрії розробки ПЗ: накопичення легасі та розростання зоопарку технологій.
2. Накопичення легасі
Легасі — це застарілий код. Індустрія розвивається, і постійно накопичується код, якій був побудований на ідеях, революційних для свого часу. А потім з’явилась нова революційна ідея, і ось у вас вже кілька прошарків коду з різних часів — один з мезозою, інший з кайнозою.
Код різної якості це не нова річ, технічний борг завжди існує. Нова річ — це скільки на середньо-статистичному проєкті за останні роки накопичилось такого коду. Технічний борг поступово став багатошаровим.
KPI цього рівня не змінився за десятиріччя — це кількість WTF в хвилину під час роботи з кодом.
Що саме цікаве, легасі буває 2 видів: технологічне та бізнесове.
Технологічне легасі — це коли у вас застаріла технологія. Приклад: двіжок проєкту все ще на РНР4 — тобто, до появи в мові нормального ООП, і ось у вас замість public-private всюди var, немає інтерфейсів та ексепшенів. Або почали на модній MongoDB, але зараз треба мати реляіції, а перестрибнути на MySQL або RDS швидко не виходить. Руки не доходять переписати.
А бізнесове легасі це коли у вас застаріле розуміння. Це коли бізнес зрозумів щось нове про свій домен (предметну галузь), але відобразити в коді це не встигли.
Приклад бізнес-легасі: бізнес думав, що в проєкті по оренді житла є тільки одна важлива дата — start_lease_date
(дата початку аренди), але потім зрозуміли, що є ще start_billing_date
(дата початку оплати за аренду). Логіка коду була така, що в ідеалі для рефакторінгу треба було start_lease_date
всюду переіменувати на start_billing_date
(щоб значення залишились) і ввести нове поле start_lease_date
з новою логікою. Але програмісти вирішили, що це занадто складно, тому старий start_lease_date
залишили, а новий start_lease_date
просто додали як нове поле REAL_start_lease_date
. Ачівка: +1 wtf.
Більшість проєктів, з якими я стикався в останні роки, мали схожі ознаки — достатньо висока ЗП для девелоперів, але настільки страшне легасі, що девелопери не залишались надовго, і планка ЗП знову трішечки зростала — не було бажаючих довго розбиратись в прошарках старих рішень, стикувати їх між собою та будувати нові фічі на їхній базі.
В нашій професії має місце профільна деформація — наприклад, коли вам фізично боляче, якщо ви в чат-повідомленні не закрили дужку або лапки (тому що ви звикли, що код такого не пробачить). Але, можливо, ще треба ввести поняття «проєктна деформація» — це коли девелопер звикає вигинати свій розум відповідно до костилів та дьорті-хаків проєкту, і потім це приводить до вигорання та звільнення. І ось саме необхідність проєктно деформуватись приводить до того, що девелопери не хочуть йти на проєкт за невеликі гроші.
Можете самі почитати відгуки девелоперів в недавній статті тут на ДОУ «Гемблінг, порно та тайм-трекери. За які гроші українські айтівці готові з ними працювати» — легасі там йде номером першим.
3. Розростання зоопарку технологій
Друга проблема, яка постійно збільшує ціну на девелоперів — це те, скільки всього зараз треба знати, щоб працювати девелопером на проєкті.
Фронтенд став окремим стеком з іншою філософією. Робота девопсів зараз взагалі цілий окремий світ. Десятки різних баз даних та шин даних. Білд-системи та деплой. Плюс штучний інтеллект, дата-сайнс і біг-дата. Плюс, все це йде в різних смаках — React або Angular, AWS або Azure, спочатку виберіть дві букви з трьох в абревіатурі «CAP» і тільки тоді можна вибрати базу даних.
Це не проблема само собою — вибір це добре.
Проблема в тому, що зараз стало дуже багато способів прострелити собі ногу — часто девелопери хочуть (або мусять) використовувати якусь модну технологію, але не завжди вміють її готувати.
KPI цього рівня — це площа діаграми архітектури проєкту (в піскелях), або час, за який девелопер піднімає Local Env зранку.
Фронтенд-приклад: я бачив проєкт, де девелопери хотіли зробити one page application на Реакті, але щось пішло не так, тому на виході це була РНР-аплікація з нормальними переходами по HTML-посиланнях, і потім на кожній сторінці підвантажувався bundle-файл і в ньому окрема логіка маршрутізації обирала потрібну view. Передача даних із РНР всередину Реакту була окремим болем. Це випадок, коли модний React більше заважав, ніж допомагав.
Ще один аспект — через те, що швидко розвивається напрямок віртуалізації, за рахунок Docker стало дуже легко підняти будь-яку технологію, тому часто і додається все підряд, а потім коли запускається команда підняти проєкт — можна сміливо йти на перекур на 10 хвилин.
Вам же, правда, на проєкті потрібні одночасно mysql, redis, mongo, elastic, memcached, kafka та cassandra?
І якщо зі змаганням за таланти нічого не зробиш, то останні дві причини піддаються стабілізації.
Це варто робити, тому що складність збільшує ціну володінням проєктом.
Якщо поставити собі за задачу зменшення складності коду, то відбувається магія, яку я неодноразово бачив: код можна привести в такий стан, що замість команди виключно дорогих сеньйорів, у яких вся ця каша ще якось поміщається в голові, буде команда відносно недорогих мідлів, яким навіть не доводиться гадати, як зробити нову фічу за реалістичний термін. (Якщо вам потрібна така допомога на проєкті, напишіть, познайомлю вас з потрібними людьми).
Скляна стеля посулунась вверх. Але аналітики кажуть, що восени нас очікує нова світова криза — цікаво, чи буде у цієї логіки новий виток.
Найкращі коментарі пропустити