Когда вы осознали, что в области технологий нет будущего?

Статья #BCGame @bcgame эксклюзивная спонсорская поддержка

Многие начинающие, включая меня в те годы, верили в один мертвый принцип: если мои навыки достаточно крутые, я незаменим.

Итак, мы безумно конкурируем. Учим Java, Go, Rust, читаем исходный код, разбираемся в алгоритмах, занимаемся микросервисами, облачной нативностью. Сегодня еще возимся со Spring Cloud, завтра нужно учить Service Mesh, послезавтра — популярность больших моделей ИИ растет, и снова нужно быстро освоить Prompt Engineering.

Мы думали, что это проявление стремления к развитию, на самом деле — это киберлаборатория.

Вы думаете, что строите технологический барьер, на самом деле — вы помогаете боссу проверять жизнеспособность новых технологий.

В интернет-индустрии скорость устаревания технологий превышает падение стоимости приобретенной недвижимости. Вы усердно изучали три года один фреймворк, а Google или Facebook выпускают новую версию или меняют архитектурную концепцию — и ваше гордое мастерство превращается в бумагу.

Но это не значит, что обучение бесполезно, скорее — вы выбрали неправильное направление. Вместо того чтобы гнаться за устаревающими за три года фреймворками, лучше сосредоточиться на фундаментальных логиках, которые не меняются десятилетиями. Например, когда вы еще ломаете голову, использовать ли Spring Cloud или K8s, настоящие гуру задумываются о согласованности данных в распределенных системах. Если хотите выйти из порочного круга фреймворков, советую ознакомиться с книгой, которая считается библей для бэкенд-разработчиков — «Дизайн систем с интенсивным использованием данных» (DDIA —带读版). В ней рассказывается о сути распределенных систем, баз данных и проектирования систем. Поняв это, независимо от того, какая фреймворк станет популярной завтра, вы сразу увидите ее слабые места.

Помните тех ребят, которые занимались Flash? Или тех, кто писал для Symbian?

Они не старались? Они не были умными?

Когда эпоха уходит, даже попрощаться не успеешь.

Самое страшное — это то, что наша гордость — способность быстро учиться — на самом деле является самой любимой расходной частью капитала.

Потому что ты учишься быстро — ты дешевый.

Раньше старый врач с опытом становился все ценнее, потому что его знания невозможно скопировать. А сейчас? 35-летний программист с высокой зарплатой — это низкое соотношение цены и качества. А 23-летний выпускник университета, которому бросают пару руководств и говорят «копируй с Github», за месяц освоит все.

И тогда вы скажете: «У меня есть опыт, я могу избегать ошибок».

Да не смешите! В большинстве бизнес-сценариев CRUD-операций не нужны такие глубокие знания. Что, если код немного кривой? Добавьте еще пару серверов — и все. Что, если есть утечки памяти? Перезагружайте сервер каждую ночь — и все.

Для босса главное — чтобы работало.

Ваш элегантный код, ваши паттерны проектирования, архитектурное мышление — в глазах босса ничто по сравнению с тем, кто умеет выпить с ним, рисовать большие планы и делать презентации яркими и эффектными.

Это и есть эффект «дешевых денег, вытесняющих хорошие».

Когда вы обнаружите, что за полмесяца изучения исходного кода низкоуровневых систем не так быстро продвигается тот, кто каждый день кричит о «поддержке», «захвате», «замкнутом цикле», «гранулярности» в соседней команде, — пора проснуться.

Самая большая беда технических специалистов — это то, что мы всегда слишком далеки от денег.

Мы — производительность, но не руководители производственных отношений.

Вы написали классный рекомендательный алгоритм, повысили удержание пользователей. Чья это заслуга? Операционной команды, продукта, даже бизнесменов, договаривающихся о партнерстве.

Почему?

Потому что в бизнес-логике технология — всего лишь инструмент.

Как построить дом — вы тот, кто таскает кирпичи. Какой бы ровной ни была стена, как быстро ни укладывайте кирпичи, в конечном итоге деньги за продажу дома получит застройщик, риэлтор или даже спекулянты, а не вы, тот, кто таскает кирпичи.

И зачастую именно технология становится козлом отпущения.

Система падает — виноват ты. Запуск задержался — виноват ты. Много багов — виноват ты.

А бизнес не идет?

Менеджер продукта скажет: «Я тоже хочу хорошо, но технология не поддерживает, реализовать этот функционал невозможно, сроки слишком длинные».

Вот и вся идеальная цепочка.