Шлях програміста

1. Карʼєрні сходи

Програмісти також мають градації залежно від кваліфікації. Колись уживали такі поняття, як «кодер», «програміст» і «хакер», але нині майже всюди перейшли на англомовні назви з американської ІТ-сфери.

Для розробника є шість основних градацій:

• Intern Software Engineer
• Junior Software Engineer
• Middle Software Engineer
• Senior Software Engineer
• TechLead
• Principal Software Engineer

Від країни до країни й навіть від компанії до компанії критерії можуть різнитися. Утім загалом картина приблизно така:

Intern Software Engineer — це стажери. Вони перебувають у процесі вивчення програмування й не мають ані комерційного досвіду, ані досвіду участі у великих проєктах. Зазвичай вони працюють під наглядом більш досвідчених колег. Їхнє основне завдання — вивчати кодову базу та основи розроблення ПЗ, виконуючи прості завдання з кодування й беручи участь у тестуванні.

Junior Software Engineer — це вже програмісти, але без суттєвого комерційного досвіду або з досвідом менше року. Вони працюють під керівництвом більш досвідчених розробників, реалізують частини проєктів і беруть участь у циклах код-ревʼю. На цьому етапі карʼєри основний фокус — поглиблення технічних навичок і краще розуміння проєктних завдань.

Middle Software Engineer (або просто Software Engineer): мають більше самостійності в ухваленні технічних рішень, відповідають за важливі ділянки проєкту, починають наставництво над менш досвідченими колегами та активніше долучаються до обговорення архітектури. Зазвичай мають 2–5 років практичного досвіду.

Senior Software Engineer: відповідають за проєктування та реалізацію складних систем, забезпечують наставництво й лідерство в команді, беруть участь у стратегічному плануванні проєктів і часто представляють команду у спілкуванні з клієнтами та іншими зацікавленими сторонами. Зазвичай мають 5–10 років досвіду.

TechLead: несе відповідальність за кінцевий технічний результат проєкту, керує розробленням, розвʼязує найскладніші завдання, забезпечує дотримання технічних стандартів і координує роботу розробників.

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

Це цікаво. У великих компаніях можуть бути додаткові ролі й підролі. Наприклад, у Google є такі ролі:

• Staff Software Engineer (L6): має значний вплив на технічну політику свого відділу.
• Senior Staff Software Engineer (L7): працює над масштабними та складними проєктами, визначає стратегічний напрям технологічного розвитку в компанії.

2. LEGO-продукти

Колись давно (у 1975 році) Ніклаус Вірт, творець мови Pascal, написав книжку «Алгоритми + Структури даних = Програми». Відтоді багато що змінилося. Сучасний програмний продукт — це вже не те, чим він був 10 років тому, і тим паче не те, що було 20 років тому. А про 1975 рік годі й говорити: відтоді минуло 50 років.

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

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

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

За останні 20 років програмісти створили дуже багато бібліотек, фреймворків і відкритих репозиторіїв. Їх справді мільйони. І тепер писати весь код з нуля вважається поганим тоном. Натомість програму збирають із якісних і перевірених рішень — бібліотек, фреймворків, пакетів і модулів.

Але й такий підхід поступово застаріває. Тенденція останніх 10 років — перехід у хмару, у великі дата-центри, які надають вашим програмам усе потрібне. Хочете базу даних? Будь ласка: у вас сотні варіантів на вибір. Потрібен рідкісний, унікальний вебсервер — є й такі. Усе, що забажаєте, — за ваші гроші.

3. «Я — інженер» © Ілон Маск

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

Від цього робота стала лише цікавішою. Тепер ви можете у 10 разів швидше додавати нову функціональність у продукт. 30 років тому, якщо вам був потрібен вебсервер, ви писали його з нуля. 20 років тому — купували, встановлювали й налаштовували. А нині — просто заходите в хмарний портал Azure або AWS і вмикаєте потрібний сервіс.

Це, до речі, одна з причин популярності мови Kotlin. Вона чудово підходить не лише для розроблення великих корпоративних рішень, а й для «склеювання» різних компонентів. Завдяки багатій екосистемі JVM є інтеграції майже з чим завгодно: базами даних, мікросервісами, REST API, системами обміну повідомленнями, хмарними сервісами, аналітичними платформами.

Відповідно, і професія Kotlin Software Engineer давно трансформувалася в Fullstack Kotlin Developer. Сучасному розробнику важливо розуміти, як працює база даних (PostgreSQL, MySQL/MariaDB, MongoDB та ін.), щоб грамотно будувати взаємодію. Також варто розуміти, як улаштований frontend (HTML, CSS, JavaScript/TypeScript, React, Angular), щоб налаштовувати обмін із backend-частиною на Kotlin (Spring Boot, Micronaut, Quarkus). І, звісно, без Docker нині нікуди — це вже стандарт галузі.

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