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

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

    image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
    Maxilect
    Умные решения для вашего бизнеса

    Комментарии 24

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

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

      В современных приложениях, перед тем как будет найдено «что программировать» и «куда программировать» должно пройти множество этапов согласований, дизайна, архитектуры, подбора библиотек, методов тестирования. Уметь делать это быстро, задача всей команды.
        +4
        Может быть решать бизнес-задачи и важнее, но когда ищешь работу — тебе задают вопросы по поводу языков программирования.
          +2
          Так может это и есть «red flag»? Конечно зависит от контекста, но если тебя гоняют только по задачам из серии «А что выведет данный код?» это повод задуматься, минимум о квалификации.
          Но если это проходные задачи, а потом идут вопросы на тему «Какую бы вы сделали декомпозицию в такой-то задаче?», это уже совсем другое дело.
            +2
            Со временем почему то всё больше становится важно сколько тебе за это платят…
            0
            Эх, если бы эти вопросы ещё были бы адекватными, а то нередко бывает и такое:
            1. как используется опция языка Х в случае У (притом малоизвестная фишка или же попросту опасная которая запрещена к использованию в отраслевых стандартах и сам ею не пользуешься)
            2. что будет если число во флоате привести к инт16 вычесть Х, а потом сохранить эти бинарные данные побитово дабл заполнив оставшееся нулями, чему станет равен дабл?
            3. как реализовать перемножение миллион битных чисел в реалтайме по мере получения бит из двух потоков?

            Да и почему то прокатывает такое:
            1. я, как инженер, обязан открыть стандарт ааа, а так же проверить ббб, т.к. использование ааа явно не стандартное.
            2. я такой опасный код не пишу, и насколько помню язык ввв в совокупности с IEEE 754 запрещает такое
            3. я не понимаю зачем это нужно, реализация может сильно отличаться поэтому пожалуйста ответьте на вопросы…
            т.е. ответы по существу не даёшь вообще, а в итоге порой и оффер присылают…
            вопрос: зачем этот цирк нужен был?

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

            В итоге я сам, и некоторые мои коллеги уровнем выше мидла, не получали работу по обычному пути из собеседований. Часто проще найти прозрачную и открытую к диалогу фирму, профиль которой совпадает с твоими навыками, видишь что ты можешь помочь тем то и тем то, связываешься с ними, докладываешь им об этом с доказательствами в виде уже выполненных публичных проектов.
            Берут и с з/п в разы выше чем офферы по обычным собеседованиям где спрашивают про язык.
            +3
            Художнику, когда он рисует пейзаж, надо спуститься в долину, чтобы охватить взглядом холмы и горы, и подняться в гору, чтобы охватить взглядом долину
            — Государь, Н. Макиавелли
              +1
              Умение решать бизнес-задачи — это на самом деле часть более глобальной сущности — всестороннего опыта работы.


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

                Слова не мальчика, но менеджера. Привели одну крайность и опустились в другую.
                Есть бизнес, в котором можно на чем угодно состряпать решение. Есть бизнес, который строится на конкретной технологии и 100% погружением технарей в нее: Highload компоненты, ААА геймдев, ИИ — если вы думаете что там язык вторичен и как говорит inmater "Новый язык освоить не сложно" — то вы явно решаете бизнес-проблемы первого случая, где не важно — go, rust, рефакторинги, оптимизации — всё одно.

                  +1
                  Я думаю, не стоит воспринимать автора слово в слово. Общая идея такова, что вы можете выбирать из множества инструментов, решающих вашу задачу, а не зацикливаться на каком-то одном, а не про то, что нет существенной разницы между направлениями в ИТ. Существует очень мало задач, для которых выбор инструмента однозначен, и даже в Highload или ИИ.
                  Кроме того, становясь специалистом одной платформы, вы сразу искусственно ограничиваете круг доступных вам проектов, и попадаете в зависимость от её жизненного цикла. Почему бы специалисту по геймдеву не владеть и Unity, и CryEngine, и Unreal Engine?
                    +1

                    Я навидался «универсалов». И людей, которые думают что могут овладеть любой технологией за 21 день. Не бывает таких, человек может и должен знать другие стеки и языки для кругохора, но делать работу как полноценный сениор сможет максимум в одном, двух. В других — только как джун/мид.

                      +2
                      Я видел и хорошие, и плохие примеры. Но в общем случае, если человек профессионал и понимает предметную область, на другой технологический стек он достаточно легко переходит при необходимости. Да и, собственно говоря, платформы все равно отмирают. Я за 20 лет их пять штук сменил. И знаете, подняться до уровня сеньора сложно только в первый раз. Даже если новая платформа и отличается, все равно, знание бэкграунда очень помогает.
                      0
                      Почему бы специалисту по геймдеву не владеть и Unity, и CryEngine, и Unreal Engine?

                      А на обеде по фану левой рукой на салфетке крафтить ai на основе нейронок, а правой моделькам текстуры запекать, запивая чайком.
                      Это вам не JS фреймворки чтобы можно было вот так взять и с легкой руки овладеть сразу тремя.

                        0
                        Вот так и с легкой руки — нет. Но поработать какое-то время и изучить на достаточном для профессиональной работы уровне, почему бы и нет?
                          0

                          Если считать профессиональным уровнем "всего понемногу и ничего хорошо", то да. На клепание типовых игрушек хватит.

                            0
                            Ну а серьезно, что там вообще есть в этих движках такого, что не поместится в голову одного человека?
                              0

                              Архитектура классов разнится, принципы построения взаимодействия в ECS отличается, объявление/регистрация классов, отличия в составе относительно встроенных классов/api, подходы к рендеринг-пайплайну, управление ассетами отличается и накладывают свои специфичные ограничения. Всякие нюансы скриптования, API, сетевой модели и т.д. и т.п. Плюс разницу C# и C++ добавьте. Ну и учитывать что простенькие хэллоуорлды минут по 15 могут компилиться преспокойно. То бишь за условный рабочий день 32 раза скомпилировать — не густо.
                              То есть со стороны кажется это довольно просто взять и выучить их всех, на деле же чтобы выучить на сколько-нибудь приличном уровне и понимать каким образом с этим работать на нормальном уровне необходимо довольно немало времени.

                    +2

                    С одной стороны, очевидно, грамотному специалисту нужно уметь и то, и другое.


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


                    По сути это разделение на только разработчиков и только архитекторов. Но далеко не всегда такое разделение в конкретной компании а) существует и б) оправдано.

                      +1
                      "… Там спикеры делятся опытом, как они решили бизнес-проблему с помощью ИТ-технологий.." — я чаще всего наблюдал как спикеры рекламировали технологии/платформы/языки/инструменты, после чего часто спорил с коллегами, которые видели только одно решение задачи. К примеру был у нас один Пешо, который хоть тресни хотел бизнес правила записать в WWF. В итоге как-то убедил начальство перейти на WWF, перейти то перешли, но ненадолго, оказалось что это решение неудобное, Пешо ушел с работы, а мы переписали WWF на T-SQL.
                        0
                        С домашними проектами такой обратной связи получить просто не от кого: ты сам что-то делаешь и в определенный момент решаешь для себя, что сделал хорошо.
                        Почему? И от домашнего проекта можно получить обратную связь. Выложить в инет, кто-то попользуется и будет обратная связь.
                          +2
                          а давайте поставим вопрос иначе: что важнее, умение просто решать бизнес задачи, или умение решать бизнес задачи так, чтобы потом не приходилось доделывать/переделывать/рефакторить полгода? Для второго владение инструментарием таки понадобится
                            0
                            для бизнеса технологии — лишь инструмент для решения своих задач
                            Это очень популярное утверждение, но хотелось бы немного поспорить и поговорить о точности формулировок. Как мне кажется, во время мысленного переноса разработки ПО на привычные сферы и методы работы слово «инструмент» приобрело не совсем изначальное значение, что может достаточно сильно путать людей. Изначально оно достаточно часто вызывает ассоциации с тем, что это только средство обработки какого-то материала, его можно заменить (хотя часто замена инструмента требует денег, времени и подготовки специалистов). При этом «материал» — это то, что предоставляют мастеру, затем он обрабатывает материал и отдает его заказчику в виде продукта.

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

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

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

                              0
                              И в этом ключевое отличие инструмента от материала и продукта: различный инструмент при адекватном выборе и использовании позволяет достигнуть практически одинакового результата

                              Ну так и различный материал тоже, это от конкретного кейса зависит. Разница между инструментом и материалом в том, что материал становится частью продукта, а инструмент — нет. У вас сосновый брус не подходит для построения печки, но зато можно выбирать из глиняного кирпича, из силикатного кирпича и т.д., и во всех случаях результат будет одинаковый, по крайней мере, не отличаться по нужным вам потребительским свойствам. С другой стороны, дайте в качестве инструмента печнику не мастерок и киянку, а плоскогубцы, и тоже не получите разумного.
                              Становятся ли софтверные компоненты частью продукта в ИТ? Нет, т.к. вы одну и ту же СУБД, один и тот же язык или один и тот же гипервизор можете использовать для создания массы продуктов. Поэтому это инструменты, а не материалы.
                              С другой стороны, вопрос этой формулировки — это такая ерунда, которая не стоит времени, потраченного и вами, и мной на спор :)
                              0
                              Я согласна главное уникальная бизнесс идея и правильное движнени к цели. Хотя потом могут быть проблемы с поддержкой этих древних технологий. К примеру огоромные сервисы мастадонты на джаве
                                0
                                Правильный работодатель ищет специалистов, способных решать поставленные задачи. И решать их качественно, и за адекватное время. На каком языке программирования и с привлечением каких программных каркасов будет решена задача дело вторичное ( если полученный результат удовлетворяет всем критериям ).

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

                                Самое читаемое