Коли ти усвідомив, що робота в галузі технологій ніколи не принесе виходу?

Цей матеріал #BCGame @bcgame ексклюзивна підтримка

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

Тому ми шалено змагаємося. Вивчаємо Java, Go, Rust, читаємо вихідний код, вчимо алгоритми, займаємося мікросервісами, працюємо з хмарною нативністю. Сьогодні ще возимося з Spring Cloud, завтра потрібно вивчити Service Mesh, післязавтра AI великі моделі — і знову потрібно швидко освоїти Prompt Engineering.

Ми вважаємо це прагненням до розвитку, але насправді це — киберлабораторна шліфовка.

Ви думаєте, що будуєте технічний бар’єр, але насправді ви допомагаєте керівнику перевірити життєздатність нових технологій.

У індустрії інтернету швидкість зношування технологій швидша за падіння цін на купівлю житла. Ви наполегливо вивчали три роки один фреймворк, а Google або Facebook випускають нову версію або змінюють архітектурну концепцію — і ваші горді навички, мов «завоювання дракона», миттєво перетворюються на папір.

Але це не означає, що навчання безглузде, а швидше — що ви обрали неправильний напрямок. Замість того, щоб ганятися за застарілими трирічними фреймворками, краще зосередитися на вивченні тих фундаментальних логік, які не змінюються десятиліттями. Наприклад, коли ви ще сперечаєтеся між Spring Cloud і K8s, справжні гіганти думки вже розмірковують про консистентність даних у розподілених системах. Якщо хочете вийти з кола фреймворків, рекомендуємо взятися за книгу, яку вважають біблією бекенду — «Дизайн систем з великими даними» (DDIA з читанням). Вона розповідає про суть розподілених систем, баз даних і системного дизайну. Зрозумівши це, ви зможете миттєво розпізнати будь-який новий фреймворк, незалежно від того, що стане популярним завтра.

Пам’ятаєте тих братків, що займалися Flash? А тих гуру, що писали для Symbian?

Чи вони не старалися? Чи не були вони розумними?

Коли час вас відкидає, навіть прощання не скажете.

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

Бо ти швидко навчаєшся — значить, ти дешевий.

Колись старий китайський лікар ставав ціннішим із віком, бо досвід не можна скопіювати. А тепер? 35-річний програміст, який отримує високу зарплату, — це низька цінність. 23-річний випускник університету, отримавши пару посібників і скопіювавши код на GitHub, за місяць вже може працювати.

Тоді ти скажеш: «У мене є досвід, я можу уникнути пасток».

Та не смішися. У більшості бізнес-сценаріїв CRUD-операцій не потрібно такої глибокої техніки. Що поганого у тому, що код трохи поганий? Додай ще пару серверів — і все. Що з витоками пам’яті? Перезавантажуй сервер щоночі — і все.

Для керівника головне — щоб система працювала.

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

Ось і працює закон劣币驅逐良币.

Коли ти зрозумієш, що за півмісяця досліджень низькорівневого коду ти не просунувся так швидко, як той PPT-інженер із сусідньої команди, що постійно кричить «засвоєння», «захоплення», «зворотній зв’язок», «гранулярність», — саме тоді потрібно прокинутися.

Найбільша біда технаря — це те, що ми завжди дуже далеко від грошей.

Ми — виробництво, але не керівники виробничих відносин.

Ви написали крутий алгоритм рекомендацій, підвищили утримання користувачів. Чия це заслуга? Операційної команди, продукту, навіть тієї бізнес-людини, що домовлялася про співпрацю.

Чому?

Бо у бізнес-логіці технології — всього лише інструмент.

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

Крім того, технології часто — це той, хто отримує «какашку».

Якщо система зламалася — ти винен. Якщо запустили пізніше — ти винен. Якщо багато багів — ти винен.

Але якщо бізнес не запустився?

Менеджер продукту скаже: «Я теж хочу зробити добре, але техніка не підтримує, цей функціонал зробити неможливо, терміни затягнулися».