Top.Mail.Ru

Что важнее: знать язык программирования или уметь решать бизнес-задачу?

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

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

С точки зрения бизнеса совершенно не важно, на каком языке будет решена их задача. Бизнес не думает, а возможно, даже не знает о java, go, ruby и других языках и технологиях. Для разработчиков здорово, конечно, когда масштабный и интересный проект начинается с нуля и технологический стек выбирается командой. Но в реальном мире гораздо чаще происходит не так. Обычно в компании уже есть экспертиза в определенном стеке, от которой ИТ-руководству не хочется отказываться. Причины могут быть совершенно разные, от запрета на “зоопарк технологий” до личных предпочтений лиц принимающих решений. Встречаются и дополнительные факторы вроде потребности в интересных технологиях для команд, ради привлечения и удержания квалифицированных кадров.

Разработчики со своей стороны зачастую высказывают желание развиваться в определенном технологическом стеке. Подкрепляет это намерение большая разница между зарплатами для некоторых языков. Так и появляются люди, которые упорно живут, например, в рамках Java или Python (Go, Kotlin, Scala… список можно продолжать чуть ли не бесконечно) и даже Delphi, не пытаясь посмотреть, а что есть еще.

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

Моя точка зрения состоит в том, что конкретный язык программирования вторичен. Первичны общее понимание принципов разработки и умение решать проблемы бизнеса — знание подходов и паттернов, которые помогают систематизировать общую работу, опыт применения различных техник, в том числе командных. С таким багажом еще один язык, который нужен в данном конкретном проекте, освоить несложно. У меня перед глазами полно примеров того, как люди переквалифицируются на другие стеки в течении месяца — двух интенсивного обучения. Конечно, сложнее переключаться между языками с разными парадигмами, например с функциональных на объектно-ориентированные, но и здесь нет ничего невозможного, если человек не противится такому переключению “на уровне веры”.

Зная несколько языков, под каждую конкретную бизнес-задачу можно выбирать свой подход к решению — тот, что не просто подойдет, но будет оптимален в данном конкретном случае. И чем больше в арсенале разработчика база этих подходов (языков), тем получается шире взгляд на проблему и мотивированнее выбранный стек. Бизнесу, собственно, это и нужно — получать наиболее подходящее решение для своих задач.

А вот с глубоким знанием одного языка, но без способности решать бизнес-задачи специалист принесет пользу далеко не любой команде. Безусловно, в отдельных проектах глубокие знания “фишек” языка помогают команде в целом добиться большего перформанса. Но чаще член команды, знающий один язык, но не умеющий слушать бизнес, будет лишь тормозить коллег. И кстати, такой “ходячий справочник неочевидных возможностей” зачастую если и нужен в конкретной команде, то только один (делаем выводы о востребованности таких узких специалистов на рынке труда).

Умение решать бизнес-задачи — это на самом деле часть более глобальной сущности — всестороннего опыта работы. Получить его можно как с работодателем, так и в рамках домашних проектов. Правда, на мой взгляд, только бизнес-проекты (где есть заказчики, бюджеты, сроки) могут дать столь необходимую в подобных ситуациях обратную связь, оценивающую качество решения. А именно это определяет глубину полученного опыта. С домашними проектами такой обратной связи получить просто не от кого: ты сам что-то делаешь и в определенный момент решаешь для себя, что сделал хорошо. На этом все заканчивается. Но когда проект реализуется для бизнеса, недостаточно проработанное решение будет отправлено на доработку,
потом еще и еще раз, если это необходимо. И по ходу этих итераций ты неизбежно изучишь несколько подходов к задаче — получишь понимание более высокого уровня.

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

Лучше понять бизнес помогает погружение в какую-то отрасль. Когда ты не просто делаешь абстрактный модуль, принимающий, обрабатывающий и отправляющий неизвестному адресату пакеты данных, а реализуешь, допустим, часть сложного биллинга или банковской системы, где есть разные типы пользователей, стандарты и прочие особенности. Знание этих деталей очень ценно. Такое погружение учит интересоваться тем, что происходит вокруг твоей части задачи. Это помогает искать оптимальное решение. Я знаю специалистов, которые никогда не пойдут работать на задачу, которая нужна непонятно для чего. А в некоторых направлениях развития бизнеса для разработчиков предусмотрено обязательное внутреннее обучение, потому что без погружения в принципе не получится эффективной работы.

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

Я не говорю, что заботиться о бизнес-задачах должен каждый разработчик. Джун только входит в этот круг, на начальном этапе у него уходит слишком много времени на коммуникации с коллегами и изучение того, как решить конкретную проблему. Тут не до расширения кругозора. Но вот начиная с миддла предыдущий опыт формирует понимание, с какой стороны подходить к задачам определенного типа. На этом этапе уже не возникает вопросов по экосистеме разработки — когда и какие статусы выставлять, как реагировать на код-ревью и т.п. Специалист начинает быстрее справляться даже с незнакомыми задачами — здесь-то самое время “подтянуть” бизнес-составляющую. Фактически сениор от миддла и отличается этим пониманием подходов к решению распространенных проблем бизнеса. И стремление к такому пониманию помогает быстрее перейти на следующий уровень.

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

А что вы думаете по этому поводу?

Автор статьи: Сергей Марина

Наши статьи по теме:

Все статьи

Связаться с нами

Мы свяжемся с вами в течение 24 часов.