Универсальный vs узкопрофильный программист

0
338
views

Юрий Юрченко, Leader of Global People Development в DataArt, в своей статье на DOU.UA попробовал разобраться с понятием универсальности в разрезе профессии разработчика. Предлагаем ознакомиться с мнением автора и, если имеете собственную точку зрения на этот вопрос, — поделиться в комментариях.

Photo by Headway on Unsplash

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

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

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

Универсальность как вечная ценность

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

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

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

Если посмотреть на историю IT, вначале языки программирования были похожи на ту самую палку первобытного человека. С помощью машинных кодов и Ассемблера можно было показать все, на что способна ЭВМ. Правда, работать с их помощью приходилось долго, и для разработчика это было совсем неудобно. Поэтому довольно быстро возникли языки высокого уровня типа PL, REXX или Фортран. При этом следует помнить, что язык программирования — такой же язык общения, как и любой другой. Просто он позволяет нам коммуницировать не только друг с другом (для этого он тоже годится), но и с машинами. Т. е. расширяет круг наших контактов, делая способность к общению более универсальной.

Есть программисты с большим опытом, которые вписались в проекты, рассчитанные на много лет, скажем, в банковской сфере. Там существуют программы, которые могут подолгу оставаться без изменений, поскольку устраивают всех, кто с ними непосредственно соприкасается. В такой нише можно относительно спокойно кодить вплоть до заслуженного отдыха. Но, с одной стороны, количество таких мест ограничено. С другой — хотели бы вы оказаться на одном из них? Даже если вас не пугает скука и очень привлекают деньги, которыми обычно и мотивируют заниматься немодными технологиями, готовы ли вы пойти на такой риск? Ведь если до пенсии вам не год и не два, велики шансы, что работу искать еще придется. А программист с большим опытом и маленьким набором возможностей — самая противоречивая фигура на рынке труда. Она может вызывать удивление, но вот желание познакомиться ближе в рамках рабочего проекта — очень изредка.

Все остальные программисты существуют в совсем других условиях: любой, кто обратился к современным технологиям, будет вынужден постоянно учиться. Либо углубляя знания по выбранной изначально специализации, инструменты которой будут кардинально меняться (вспомните С, С++, С#, Golang), либо внимательно глядя по сторонам. Лучше, конечно, делать и то и другое.

Когда понимаешь, как работает программа с момента, когда пользователь нажал Enter, и до сохранения информации в базе данных, намного проще обнаружить ошибки кода. Когда понимаешь, как устроен бизнес клиента и для чего мы, собственно, разрабатываем новую систему, намного проще обнаружить логические нестыковки. И подсказать путь усовершенствования продукта на выходе. Люди, способные к этому, будут самыми востребованными в любом проекте, тем более, использующем передовые инструменты.

Сами технологии сейчас развиваются именно в направлении синкретизма, плотного пересечения и даже частичного слияния самых разных направлений. Возьмем, к примеру, MLOps — объединение технологий машинного обучения и подходов к внедрению разработанных моделей в бизнес-процессы. Очень важно, что новая специфическая область потребовала и нового способа организации сотрудничества между представителями бизнеса, математиками, ML-специалистами и IT-инженерами. Это не было бы возможным, если бы все они не говорили на одном языке — т. е. не осваивали смежные со своей основной специализацией дисциплины. Хотя бы трех (допустим, четвертая — та, из которой человек пришел в проект, им уже освоена), причем на уровне как терминологии, так и образа мышления. Интересно ли работать в MLOps-проекте? Думаю, мало кто откажется. Возьмут ли туда человека, не готового расширять сферы компетенций? Вряд ли, даже если в своей узкой нише он давно стал блестящим профессионалом.

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

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

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

Я не утверждаю, что каждый IT-специалист обязан разбираться в бизнесе. Но это очень полезно для работы, общения с коллегами и понимания происходящего на разных уровнях. Вообще, серьезная специализация началась с выделения администраторов баз данных. Тогда впервые понадобились люди, которые бы глубоко знали специфику написания скриптов и конфигурирования СУБД различных производителей. Но в итоге такая специализация сработала плохо. Как только появились DBA, многие разработчики решили, что писать код можно как угодно — придет администратор и все оптимизирует. Но отвечать на вопрос «Почему так медленно работает SQL-запрос?» всем быстро надоело. Кому интересно разбираться, у разработчика ли кривые руки или DBA не умеет настроить сервер? Сути проблемы это не меняет.

Эту странную ситуацию разрешили волевым решением: теперь бэкенд-разработчик должен понимать все основные особенности базы данных, для которой он пишет SQL-запросы. Подходить к DBA стало приличным только с тонкими проблемами, часто требующими отдельного исследования, на которое просто нет времени. Администраторы баз данных стали возвращаться с конкретным решением частной проблемы, которая могла касаться, например, конфигурирования на уровне файловой системы либо построения кластерных индексов. Но чтобы это заработало, разработчикам пришлось выучить особенности диалекта конкретного языка, на котором разговаривали DBA.

Примерно то же произошло при разделении фронтенд- и бэкенд-разработки. Специализация всегда позволяет глубже проникнуть в тему, но платить за слишком плотное погружение приходится сужением кругозора и затрудненной коммуникацией с коллегами других специализаций. Конечно, одно из наиболее очевидных проявлений универсальности — фулстек. Если человек хочет лучше понимать, как работает архитектура в целом, или, наоборот, разобраться, как пользователь взаимодействует с системой, — это наверняка позволит ему обходиться в межцеховой коммуникации без дорогих и неудобных переводчиков. Даже если в основном он продолжит работать именно как фронтенд- или бэкенд-разработчик. Здесь-то мы подходим к главному: писать код, который работает оптимально — намного круче, чем просто писать код. Поэтому тебе не должно быть все равно.

Кого можно назвать универсальным

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

Например, у нас в DataArt есть направление изучения искусственного интеллекта. Это открытая группа, куда приходят люди из разных индустриальных практик и с разным профессиональным бэкграундом, чтобы обсудить, как ИИ можно было бы применить там, где они работают. Даже если прямо сейчас с искусственным интеллектом их направление дела не имеет. Но такое расширение знаний позволяет в перспективе «think out of the box».

Если человек выбрал направление и попал в большой проект, где собирается провести достаточно долгое время, прежде всего имеет смысл смотреть на технологии, которые могли бы пригодиться в этом проекте. Но любой проект рано или поздно заканчивается, и задавать себе вопрос «Чем бы я хотел заниматься после него?» очень полезно.

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

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

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

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

Проверить себя

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

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

Широкий кругозор, узкий профиль

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

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

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

Именно мастера, а не ремесленники, способствовали развитию человечества во всех сферах деятельности во все времена.

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


Верите ли в универсальность вы? Или лучше иметь хорошее и стабильное ремесло? Возможно, кто-то открыл для себя третий путь?

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here