Давным давно мы разработали высокоуровневую платформу для разработки бизнес-приложений lsFusion. Оставалось дело за малым: найти того, кто будет на ней писать. Было решено разместить на сайтах по поиску работу соответствующую вакансию. Но возник вопрос: что указывать в качестве должности или профессии.
По уровню сложности язык платформы не сильно отличался от SQL, который изначально создавался не для программистов, а для бизнес пользователей. Поэтому мы также решили указать в качестве должности “Бизнес аналитик”.
Соискателям мы предлагали решить относительно несложное тестовое задание, в котором нужно было немного доработать простой пример. Некоторые люди справились, но от многих пришли гневные письма с возмущением вроде: “Вы ищите программиста или бизнес аналитика ?”.
В итоге мы нашли нужных нам людей, но анализируя этот опыт, я невольно задавался вопросом: где заканчивается бизнес анализ и начинается программирование?
Когда я только закончил университет, у меня был знакомый, который уже работал программистом в крупной аутсорсинговой компании. В ней было все по взрослому — помимо программистов там были и бизнес аналитики, и тестировщики. Тогда мне было очень интересно, как у них там все построено, в частности, что делают бизнес аналитики. На вопрос о том, как он с ними взаимодействуют был получен приблизительно следующий ответ: “Они там мне какие-то диаграммы шлют, документы всякие. Я их все равно не читаю и сразу удаляю”. Понятно, что он немного лукавил, и что-то он смотрел.
Сейчас, читая большое количество различных технических заданий и спецификаций, я понимаю главную проблему такого “бизнес анализа”: бумага все стерпит. В этом и есть ключевое отличие анализа и программирования. На бумаге можно написать абсолютно противоречивые условия, указать абсолютно абстрактные требования вроде “хочу, чтобы было хорошо”, красиво их оформить, и считать, что работа сделана. В программировании такой трюк не проходит — все должно быть четко. По этой причине разработчик может часто отбиться от реализации любого функционала от заказчика, просто постоянно указывая на противоречия и требуя уточнения требований. И сделать заказчик сможет только, если он, по сути, выполнит работу программиста.
Программисты вроде как должны писать программы. Что можно считать программой? Одним из формализмов используемых в теории является Машина Тьюринга. Это простейшая вычислительная машина, при помощи которой можно описывать алгоритмы. Это, в свою очередь, предполагает, что одним из свойств программы является императивность. У программы есть состояние и процесс выполнения. Одной из основных особенностей SQL являлась его декларативность. Предполагалось, что им будут пользоваться обычные люди, так как им не придется писать “программу”, а описывать на SQL то, что они хотят получить.
В детстве мне довелось заниматься шахматами. Сейчас я понимаю, что абсолютно не понимал основных принципов позиционной игры. Однако, у меня получалось хорошо просчитывать позицию на много ходов вперед. Я всегда стремился “открывать” игру и дальше выигрывал просто за счет различных комбинаций, где соперник считал хуже меня. По сути, у меня просто в голове работал дебаггер, который мог делать ходы, и представлять в watches текущую позицию на доске. В реальности я играл как простенький компьютер. Тем не менее, мне удалось в первый же год занятий выполнить первый взрослый разряд и попасть в тройку на чемпионате Беларуси в своем возрасте. Забавно, но в шахматах используются похожие навыки, что и в программировании. Позиционная игра — это проектирование архитектуры. Тактическая игра — отладка программы.
Обучая людей программированию на lsFusion, я пришел к выводу, что императивная логика сложнее воспринимается обычным человеком, чем декларативная. Просчитывание ситуации на много ходов вперед не является базовым навыком, используемым человеком в повседневной жизни. Ему приходится держать в голове состояние и уметь изменять его на каждом шаге. В то же время каждому человеку приходится регулярно формулировать то, что он хочет, что и является своего рода “декларативным программированием”.
Декларативность присутствует и в других инструментах. Например, в Excel можно строить определенную логику, используя формулы. Мне доводилось видеть чуть ли не целые информационные системы, написанные в виде формул Excel, слегка приправленные императивным кодом на Visual Basic. Являются ли эти люди программистами, или они — продвинутые бизнес аналитики?
Если рассмотреть стек языков и технологий, которые сейчас используется в разработке, то его можно разделить на несколько уровней (точно также, как и стек сетевых протоколов). На каждом из них добавлялось что-то новое:
- Ассемблер. Машинно-ориентированный язык.
- C. Процедурный язык.
- C++. Объектно-ориентированное программирование..
- Java/C#/Python и прочие. Виртуальные машины и управляемая память.
- 1С / Access / SAP NetWeaver и т.д. Тут из хлопот разработчика убраны управление памятью, диском, сетью и прочими деталями. Нужно думать исключительно о бизнес-логике. Именно где-то на этом уровне и находится lsFusion как платформа.
Каждая следующая технология написана на базе технологии более низкого уровня. Теоретически, из этого следует, что те, кто пишут на более низком уровне смогут писать на более высоком уровне. Это, конечно, не значит, что они будут это делать максимально эффективно. Инженеры, которые создают легковые автомобили, не будут лучшими в мире гонщиками, но каким-то образом на них ездить должны уметь. В обратную сторону это не работает.
Во многом по этой причине, как правило, разработчики всегда уважают тех, кто использует более низкоуровневые технологии, и презирают тех, кто пишет на более высокоуровневых. Я не настолько стар, чтобы застать те времена, когда разработчики на ассемблере ненавидели сишников. Но помню еще сишников, которые считали, что C++ — это от лукавого. Java-разработчиков до сих пор некоторые девелоперы на C++ считают недопрограммистами, так как они не умеют по-настоящему управлять памятью, и программы на Java из-за этого требуют кучу лишней памяти. Ну и все разработчики первых четырех уровней конечно же презирают 1С-программистов, что лучше всего отражено в бородатом анекдоте:
Однако, это может быть связано с тем, что технологии пятого уровня, в отличие от первых четырех и lsFusion, являются закрытыми и платными. Они используются в кровавом enterprise, где это в порядке вещей. Соответственно, не любят всю экосистему, а заодно и разработчиков в ней.
Стоит заметить, что именно на пятом уровне находятся такие высокоуровневые и декларативные языки как SQL и HTML+CSS. К SQL разработчикам, кстати, отношение остальных значительно более лояльное. Скорее всего, из-за того, что они работают с ними в связке, решая отдельный блок задач, в отличие от тех же 1С-программистов, которые занимаются и базой данных, и бэкендом, и фронтендом одновременно.
Справедливости ради, похожая ситуация существует не только в программировании. Например, есть ряд людей, которые ездят исключительно на механической коробке передач, крайне негативно относясь к автоматической. Они считают, что автомат переключает передачи не эффективно, и вручную они могут лучше (что в общем-то правда). Другое дело, что большинство все-таки готовы пожертвовать эффективностью, надежностью и повышенным расходом топлива ради банального удобства. И также как в программировании есть люди, которые вообще не могут ездить на механике, так как у них недостаточно координации, чтобы быстро переключать передачи и жать нужные педали.
Стоит правда отметить, что у водителя с автоматической коробкой передач есть возможность переключиться на ручной режим. Точно также в C можно вставлять ассемблерный код, или в lsFusion можно спускаться на уровень ниже, и писать Java код.
Чем выше уровень технологии, тем больше в ней декларативности и меньше императивности. Можно рассмотреть эти уровни как шкалу, где внизу будет “машина”, а сверху — “пользователь” или “бизнес”. По мере продвижения снизу вверх считается, что программирования становится все меньше и меньше. И, возможно, где-то на этой линии есть точка, когда программирование становится бизнес анализом.
Почему мы не искали уже состоявшихся программистов? На это есть, как минимум, несколько причин.
Во-первых, у них уже есть какой-то стек технологий, с которым они работают. Несмотря на относительно инновационную отрасль, большинство программистов — консерваторы (хотя конечно, далеко не все). Они не будут изучать неизвестную технологию без хайпа, на которую нету спроса (даже если временно). Когда любой человек меняет сферу, в которой работает, он автоматически “теряет в цене”. Поэтому психологически сложно бросить то, что знаешь и начать изучать что-то новое.
Во-вторых, разработка на платформе lsFusion, как и разработка на 1С, действительно ближе к бизнес-анализу, чем разработка на более низкоуровневых платформах вроде Java, .Net и Python. Тут другие задачи, проблемы и подходы.
Но одна из основных причин — экономическая. В Беларуси, в отличие от России, люди не стремятся стать чиновниками и силовиками. Тут вы не сможете, работая каким-нибудь министром, возить собачек на личном самолете на всякие выставки, или ездить пьяным по встречке. Показуха далеко не приветствуется, да и многих чиновников время от времени сажают, а потом выпускают руководить колхозами. Компаний, жирующих за счет природных ресурсов, у нас тоже нет, поэтому мечтам стать нефтяником также не суждено сбыться. Практически любой рынок достаточно мал и уже, как правило, поделен. Поэтому места для новоявленных бизнесменов тоже немного.
На всем этом фоне особняком стоит сфера IT. Лучше всего это заметно на следующей картинке:
Если исключить весьма малочисленные сферы пилотов и неких финансовых консультантов, то получится, что в среднем программисты зарабатывают в три с половиной раза больше, чем работники других самых высокооплачиваемых сфер. Если же сравнить с бюджетниками, то разница будет в семь раз.
Еще одним плюсом в работе программиста в Беларуси является стабильность. Так как местный рынок очень мал, то большинство компаний работает на западный рынок. Поэтому, как правило, все зарплаты программистов номинированы в валюте. Именно поэтому за июнь идет падение по сравнению с полугодием — укрепился курс рубля. В стране, в которой постоянно идет девальвация местной валюты относительно мировых, зарплата в долларах и евро считается залогом стабильности и спокойствия. Айтишники в стране многими считаются «хозяевами жизни». Они являются основными потребителями дорогого сегмента на большинстве рынков. Многие родители отдают детей в кружки по программированию, а на соответствующие факультеты наивысший конкурс.
Неудивительно, что в Беларуси процветает тренд “Войти в АйТи”. Мы решили воспользоваться этим и попробовать нанять людей других профессий, научив их разрабатывать на lsFusion. К слову, сейчас у нас разработчиками на lsFusion работают бывшие менеджеры по продажам, системные администраторы, экономисты, консультанты ERP-систем и так далее.
Разместили оплачиваемое объявление на главной странице крупнейшего информационного ресурса Беларуси. В нем учли ошибку с сайта вакансий и указали, что мы ищем не бизнес-аналитика, а разработчика без опыта работы. Для лучшей мотивации в явную указали потенциальную вилку зарплат, соответствующую ИТ-отрасли.
Так как нам требовалось совсем небольшое количество человек, а желающих будет много, то мы понимали, что кандидатов нужно будет как-то отсеивать. Выбрали самую простую схему: нужно взять пример Турнирная таблица и доработать его таким образом, чтобы для матча счет определялся не вручную, а на основе забитых голов, которые должен вводить пользователь. Чтобы не возиться с каждым кандидатом в отдельности и не тратить их время, мы указали прямо в объявлении, что требуется решение этой задачи.
Для решения задачи требовалось скачать и установить платформу (на сайте был installer), подключить туда код из примера и исправить его в IDE. У любого нашего lsFusion разработчика на это уйдет минут 15. У обычного программиста, чтобы разобраться в примере, скачать, запустить и решить ушло бы максимум 3 часа, так как в решении не требуется дополнительных знаний по платформе. Там все делалось по аналогии с уже существующей логикой.
По статистике объявление открыло и прочитало несколько десятков тысяч человек. Само тестовое задание (оно было по отдельной ссылке) прочитало несколько тысяч. Скачало платформу около 400 человек (а тогда это было одним файлов размером 1.5ГБ, в который входили и IDEA, и Java и PostgreSQL). Что-то прислали человек сорок. Из них адекватное решение было у человек десяти. Из этих людей мы и выбирали уже тех, кого возьмем на работу.
Чего я так и не смог понять в этой истории, так это чего не хватало людям: мотивации или способностей. Ведь если кто-то работает на низкооплачиваемой работе, которая не приносит ему удовольствия, то что ему мешает потратить даже несколько часов, чтобы разобраться в задаче и решить ее. Мы уже со старта предлагали высокую зарплату, которую платят далеко не всем junior разработчикам на других языках. Возможно, многие люди действуют по принципу “я б в программисты пошел, пусть меня научат”. Собственно у нас в стране уже есть множество всяких платных курсов, на которые идут много людей, не понимая насколько важно в программировании самообразование.
Но возможно, проблема именно в способностях. Для того, чтобы начать программировать нужен один основной навык: аналитическое . Под ним я подразумеваю умение выделять из частного общее (индукция) и наоборот (дидукция). Эта способность развита у относительно небольшого количества людей, но без нее хорошим программистом, увы, не стать. Более того, если каким-то образом измерить аналитическое и построить график зависимости относительно количества людей с таким навыком, то получится гипербола. То есть, чем ниже порог вхождения в технологию, тем значительно больше людей могут его преодолеть.
Проблема аналитического в том, что ему нельзя научиться. Оно формируется где-то в раннем возрасте, и взрослый человек уже не в состоянии что-то изменить. У нас проходил испытательный срок кандидат технических наук. При этом он не мог реализовать простенькую доменную логику. Человек старался, работал дома по вечерам, но каждый раз, когда ему давали задачу, в которой нужно было просто сделать по аналогии, он не мог с ней справиться. Как он при этом смог защитить кандидатскую, непонятно. Впрочем, это скорее показывает, что аналитическое не является обязательным в повседневной жизни. И существует ряд профессий, в которых этот навык не особо требуется.
Когда меня спрашивают, с какой технологии начать путь в программирование, то я отвечаю: начните с SQL. Его знание в любом случае не помешает, а изучить базовый функционал (SELECT / JOIN / UNION) требует не более одного дня. Дальше нужно пробовать решать задачи из интернета. Не получается — значит не стоит начинать с программированием вообще. Если что-то удается решать, то, как минимум, 1С или lsFusion программистом можно стать. А дальше, уже как получится.
Заключение
Конечно, вопрос из заголовка статьи — риторический. Понятие программирования — субъективно, и зависит от взглядов конкретного человека. Все люди в той или иной степени занимаются программированием. Например, когда просто устанавливают настройки в терморегуляторе теплого пола, или создают таблицы с формулами в Google Docs. Однако, у технологий разных уровней отличается порог вхождения. Чем более высокий уровень у технологии, тем больше людей могу программировать на ней. Правда программирования в этом процессе действительно становится меньше. Хотелось только, чтобы это не становилось предметом презрения одних разработчиков другими.
Автор: dlsf
