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

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

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

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

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

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

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

Вот мысль: 

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

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

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

pip install highlight-text

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

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

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

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

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

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

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

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

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

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

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

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

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

Коля Митин:

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

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

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

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

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

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

Что это даёт: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

easy
Вас догонят. Как реклама ловит нас в интернете
Вас догонят. Как реклама ловит нас в интернете

Конспект подкаста «Запуск завтра»

easy
Зачем нужна командная строка в современных компьютерах

Разбираемся на Маках и Винде.

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

Скорость решает.

easy
119 тысяч рублей за то, чтобы делать приложухи — это справедливо?

Краткий гид по работе мобильного разработчика

easy
Что такое AJAX
Что такое AJAX

Как добавить что-то новое на страницу без перезагрузки

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

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

easy
Как работает BitTorrent и почему пиратские торренты так сложно заблокировать
Как работает BitTorrent и почему пиратские торренты так сложно заблокировать

Конспект подкаста «Запуск завтра»

easy
Как количество просмотров или лайков под роликом может уменьшиться у вас на глазах
Как количество просмотров или лайков под роликом может уменьшиться у вас на глазах

Во всём виноваты базы данных

easy
Что такое Kotlin?
Что такое Kotlin

И зачем он андроид-разработчику.

easy
Что такое UNIX и зачем он нужен
Что такое UNIX и зачем он нужен

Операционная система, которая изменила мир, хотя в ней почти никто не работал

medium
easy