Звісно аутсорс — дякую, тоді це був самий початок )

Дякую за питання! Якщо чесно, я просто дуже уважний слухач. На певному етапі кар’єри ти починаєш слухати не просто розумних людей, а тих, хто реально рухає індустрію — CTO, директорів з інновацій, творців мов і фреймворків. Наприклад, мій перший наставник з програмування (я був в універі тоді) написав свій SQL на Prolog, і це, м’яко кажучи, сформувало моє бачення архітектури. Другий важливий момент — це постійний аналіз існуючих систем, навіть легасі. Це як археологія: копаєш, знаходиш стародавні артефакти, робиш висновки — що працює, а що треба було спалити ще на етапі задуму. Взагалі, як Шекспір і його предшественники придумали всі класичні сюжети, так і патерни архітектури вже були винайдені мислителями минулого століття. Залишається тільки правильно їх використовувати та не винаходити велосипед з квадратними колесами. Ну і, якщо вже говорити про сучасні інструменти розвитку, зараз важливо вміти правильно використовувати AI-асистентів, навіть для особистісного зростання, не побоюся цього слова — спробуйте це неімовірний досвід.

Дякую за цікаві запитання!

1️⃣ Скільки разів змінювали роботу?
Я не з тих, хто часто змінює роботу заради змін. По суті, я переходив між проектами всередині однієї компанії, а пізніше вона стала частиною Intellias, і я був у групі, яка допомагала вирівнювати процеси між компаніями. Уже після переїзду в США отримав запрошення в нову компанію. Тому якщо рахувати «зміни роботи» — то 2,5 рази. А якщо говорити про проєкти — то я завжди шукав такі, які давали можливість прокачати як софт-, так і хард-скіли відповідно до поточних пріоритетів.

2️⃣ Чим моя позиція відрізняється від Senior?
Ключова різниця — точка огляду та зона відповідальності. Я дивлюся на весь фронтенд у масштабах компанії, налаштовую глобальні процеси та ухвалюю архітектурні рішення, які впливають на всі команди. Наприклад:

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

3️⃣ Як Senior може вирости до архітектора?
Кілька ключових напрямків, у яких можна розвиватися:

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

Я вже три роки part of Architecture Panel поряд із бекенд-архітекторами та VP архітектури, і, знаєте що? Фронтенд теж має архітектуру. Просто вона складніша, бо ще й красивою має бути! 😄

Дякую вам за коментар! Ваші запитання наштовхнули мене на думку, що варто написати кілька статей на Medium — принаймні, частина тем у мене вже в планах.

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

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

Що у фронтенді є складним?
Ніщо не застаріває так швидко, як фронтенд, хіба що тренди у дизайні. Основний виклик — розробляти фронтенд гнучко, ефективно й недорого, зберігаючи якість, у реаліях, коли фреймворк може застаріти за рік. Помилкові архітектурні рішення можуть призвести до величезних витрат для бізнесу.

Дякую за цікаві запитання! Можливо, я детальніше розкрию ці теми в наступних статтях.

Той самий момент, коли ми отримали неймовірний досвід у cowboy-driven development! 😆

Дякую тобі! Це була неймовірна атмосфера і справді фантастична команда. Такі моменти запам’ятовуються назавжди! 😊

Звичайно, 20 років досвіду в іншому стеку — це важливий фактор, але головне було змінити підхід і почати швидко зростати. Я отримав увесь можливий досвід у 1С за 3 роки, а потім надовго застяг на місці.
Перехід від сеньйора до архітектора — це великий крок, так само як від архітектора до VP. Але головне тут — не боятися змін. Страхи тільки стримують розвиток, а справжній прогрес починається, коли виходиш із зони комфорту.

Дуже приємно зустріти тебе тут! Ти був неймовірно здібним і швидко розвивався—працюючи з тобою, я сам краще зрозумів деякі концепції фронтенду. 😊

Так, 6 місяців — це небагато для глибокої практики, але варто враховувати, що я постійно приймав виклики, мав досвід створення складних систем на 1С і безпосередньо спілкувався з продуктовими власниками. До того ж, через обмежений час у мене була висока мотивація швидко освоїти нові підходи та застосовувати їх на практиці.
Мої перші два проекти — Enterprise React-застосунок із GraphQL та TypeScript, а другий — MVP-платформа на основі мікросервісів NodeJS з AI. Це значно прискорило процес навчання.

Я працював розробником 1С і будував корпоративні системи 19 років, також створював десктопні застосунки. Але я не використовував сучасні підходи, тож коли почав працювати у веб-розробці, я був готовий до швидких змін і зміг швидко адаптуватися.

О так! Кардинальна зміна, але без цього було б нецікаво. Дякую! 😊

Значить, не я один вирішив змінити курс після 40 😃 Які враження ?

Якщо чесно, то порада стосувалася смарт-контрактів в IBM Blockchain, і основною мовою для цього був саме JavaScript. Але розумію, чому це могло викликати плутанину.