«Программисты, которые умеют писать алгоритмы, — нишевая профессия»

«Программисты, которые умеют писать алгоритмы, — нишевая профессия»

Мнение работодателя Коли Митина.

«Программисты, которые умеют писать алгоритмы, — нишевая профессия»

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

После этой статьи у нас прошёл разговор с человеком, который профессионально занимается разработкой и нанимает людей — Колей Митиным из компании «Кортекс». И у него есть мнение, которым мы хотим поделиться с вами.

👉 Будет полезно всем, кто готовится стать продуктовым разработчиком и профессионально создавать софт. 

Вот мысль: 

«Есть философская тема, просто подискутировать.

Я наконец-то наладил работу в «Кортексе» и нанимаю разрабов. Вот у меня такие штуки в текущей разработке вызывают сомнения. Потому что сейчас умение писать код становится всё менее востребованным.

То есть, поставив задачу перед разработчиком, я бы ожидал, что человек скорее принесёт мне код:

pip install highlight-text

highlight_text(text, ['словоформы', 'для', 'подсветки'])

(То есть нашёл бы готовое решение среди существующих библиотек и применил бы его в проекте за пять минут, а не городил бы целый алгоритм с нуля. — Прим. ред.)

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

Смысл в том, что когда ты в проекте написал свой код, его надо обслуживать и тестировать. А если ты взял нормальную библиотеку, то её обслуживает сообщество. 

В итоге писать свой код становится очень дорого.»

Развернём эту мысль по мотивам дальнейшей беседы с Колей.

Что не так с «олимпиадным программированием»

Есть такой взгляд на программирование, что для решения задачи нужно создать новый файл и с нуля придумать решение (как это сделали мы в своём проекте). Чтобы это решение работало, нужно придумать какие-то алгоритмы: циклы, логику, проверки и т. д. Обычно такие задачи дают на олимпиадах по программированию, отсюда и название. 

У таких алгоритмов есть сильная сторона: если мы пишем алгоритм под конкретную задачу, скорее всего, он получится быстрым, оптимизированным, учитывающим все текущие нюансы. 

Но есть и проблемы: 

❌ Алгоритм — это ещё не продукт. Чтобы от алгоритма перейти к продукту, нужно написать интерфейс, подготовить серверную инфраструктуру, подготовить все вспомогательные модули. Представьте, сколько всего должно работать в интернет-магазине: авторизация, восстановление пароля, добавление товара в базу, возврат товара, рекомендации товаров и т. д. Если вы написали пусть даже гениальный алгоритм рекомендаций товара, это только 5% разработки вашего интернет-магазина. 

❌ Разработать мало. Нужно поддерживать. Продукт, который мы напишем сегодня, нужно будет поддерживать несколько лет. За это время могут смениться разработчики и технологии. В какой-то момент наш оптимизированный авторский алгоритм может оказаться несовместимым с новыми технологиями. 

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

Коля Митин:

«Иметь свой код сейчас очень дорого.

Поэтому мы даже свой код пишем «по учебнику». То есть берём известный фреймворк и всё по бест-практисес. 

У нас вообще в проектах никаких тайных знаний, всё либо в конфигах Докерфайлов или Анзиблов или написано по хендбуку фреймворка.

Даже если нужно просто перекатать данные из одной базы в другую, то мы делаем модели, дописываем сервисы и всё вот это вот. Потому что это не так долго и страшно, если умеешь, а прочитать и понять код сможет любой, кто знаком с несущим фреймворком.»

А как тогда делать?

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

Что это даёт: 

✅ Большие продукты создаются быстро. Теперь разработка сводится не к тому, чтобы сочинить алгоритм. Вместо этого ты находишь нужные библиотеки, склеиваешь их и тестируешь. Это гораздо быстрее. 

✅ Документация на всё. Публично доступные фреймворки и библиотеки тщательно задокументированы, к ним есть учебники, справочники, правила и best practices. Если у вас ушёл один разработчик и пришёл другой, который не разбирается в вашей технологии, — он легко обучится по общедоступным справочникам. 

✅ Поддержка — у сообщества. У открытых библиотек и фреймворков есть люди, которые их поддерживают. Другие люди предлагают улучшения и исправляют баги. Третьи исследуют безопасность этих решений. Если на библиотеку критически посмотрело сто разработчиков, это явно более надёжная библиотека, чем если её написал один программист в вашем офисе. 

А что делать с тем, что каждый квартал появляется новый фреймворк?

Коля Митин, Кортекс:

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

К тому же чтобы взять новый модный фреймворк в продакшн, его версия как минимум должна начинаться с 2, а лучше с 3. Тогда понятно, что он прошёл проверку временем.

И это хорошо работает, потому что версии 1 обычно используют всякие early adopters в частных проектах. Там они ловят все проблемы первой версии (и исправляют).

Алгоритмы ещё нужны, но не всем

Это не значит, что писать алгоритмы с нуля больше не нужно. Просто теперь это не всё программирование, а лишь его часть, причём не самая большая. 

Вот примеры, где алгоритмы всё ещё нужны и полезны:

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

Что нужно, чтобы быть востребованным продуктовым разработчиком

Процитируем пост Коли из его канала «Коля Митин говорит»:

Очевидно, что разработчики сейчас пишут кучу одинакового кода каждую секунду по всему миру.

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

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

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

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

Вы работодатель? Вам слово

Если вы нанимаете разработчиков, менеджеров или аналитиков в ИТ-командах и у вас есть взгляд на состояние рынка — велком: maxim.ilyahov@yandex.ru

Будем рады опубликовать ваш взгляд или рассказ. Покажите начинающим разработчикам, что реально нужно на рынке.

Получите ИТ-профессию
В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства и компенсация, если вы пойдёте работать в «Яндекс».
Начать карьеру в ИТ
Получите ИТ-профессию Получите ИТ-профессию Получите ИТ-профессию Получите ИТ-профессию
Еще по теме
Делаем неубиваемый сайт: статика и динамика
Делаем неубиваемый сайт: статика и динамика

Немного об устройстве сайтов.

Как подготовить резюме для крупной компании?

Инструкция новичкам от разработчика из Яндекс.Практикума.

Как биг-дата управляет миром: на примере магазинов

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

Почему процессоры Apple M1 такие быстрые
Почему процессоры Apple M1 такие быстрые

И правда ли они такие быстрые? И на что это влияет?

Никаких оправданий и «не могу»
Никаких оправданий и «не могу»

Анна Леонова: из китаиста в программисты.

Зачем вам jQuery
Зачем вам jQuery

Каждый год говорят о том, что jQuery уже не тот, но продолжают его использовать. Почему? Вот почему.

Биотех-стартапы: что они делают и что в них интересного
Биотех-стартапы: что они делают и что в них интересного

Краткий конспект подкаста

Как работает шифрование в мессенджерах
Как работает шифрование в мессенджерах

Секретная переписка.

Языку C уже почти 50 лет, но он всё равно крут
Языку C уже почти 50 лет, но он всё равно крут

Почему на нём программируют до сих пор.

Невзламываемый шифр Вернама
Невзламываемый шифр Вернама

Его нельзя взломать даже теоретически.

Двоичный калькулятор из бусин и палок
Двоичный калькулятор из бусин и палок

Выглядит странно, но при этом всё работает

Как устроена и зачем нужна двухфакторная аутентификация
Как устроена и зачем нужна двухфакторная аутентификация

Когда нужно ещё что-то кроме пароля.

Чем занимаются бэкенд-разработчики
Чем занимаются бэкенд-разработчики

Никто не видит, но все пользуются.

easy