Drive your career as React Developer with Symphony Solutions!
×Закрыть

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

Я уже 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 использовать слово «дообучение». При этом никто не мешает углублять знания, прежде всего, по основной специальности: особенно круто выглядят коллеги, признанные экспертами в своей области, которые при этом легко могут говорить со специалистами смежных специальностей и немало знают об их работе. Пусть и не так глубоко погружены в предмет, как в случае с собственной основной специализацией.

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

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

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

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

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

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

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

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

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


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

LinkedIn

Лучшие комментарии пропустить

Эта статья оскорбляет чувства Senior Angular V10.1.0 Developers )

Очень люблю компанию DevArt за их продукт DBForge и поддержку сообщества специалистов по работе с данными.
К сожалению, о чём пытался сказать Юрий, после прочтения статьи я не понял. Что хорошо, что плохо?
Лично я всегда сравнивал ИТ-специалистов с врачами. Умеешь всё понемногу как фельдшер или терапевт? Молодец, но много никогда зарабатывать не будешь, хотя всегда будешь в цене и нужен. Кардио или нейрохируг? Несмотря на узкую специализацию тебя все ценят, уважают и ты купаешься в деньгах.
Мне кажется всё просто — чем выше твоя экспертиза в конкретной области тем выше твоя востребованость и заработная плата. Причём смежные знания и понимание предметной области — это не плюс, это необходимая составляющая роста, без которой стекляный потолок не пробить.
Тот же упомянутый выше ДБА далеко не уйдёт без хотя бы базового понимания работы сетей, хранилищ данных и операционной системы. А системный архитектор — это тот же фул-стек разработчик который понимает как строится информационная система на всех уровнях, будь это небольшое мобильное приложение или очередной энтерпрайзный ЕРП-комбайн.
Поэтому общий посыл прост — постоянный рост. Смотрим на раковую опухоль и берём пример.
Если же отбросить шутки в сторону, то радует, что в DataArt есть подразделение Global People Development. Как я уже не раз повторял, с компаниями, которые инвестируют в своих сотрудников — нам очень даже по пути. Главное, не пытаться сделать из людей затычку на каждую бочку. Выгоднее научиться дорого продавать своих элитных узкоспециализированных бойцов.

Вважаю, що на початку професійного росту потрібна широта кругозору. Спробувати і те, і се, і п’яте, і десяте. Тим більше, що без серйозного досвіду на серйозний проект потрапити важко. Спочатку поскакати по дрібних проектах, де потрібен «девопс» на всі руки. Просто, щоби стало зрозуміло, що гріє, а що не гріє.

При цьому початковий досвід широкого профілю дуже стане у нагоді, коли є бодай найменше уявлення, що там робиться у суміжників. Як мінімум тому, що буде розуміння, чому так довго валандаються сисадміни з підняттям інстансу, чому в прогерів «тривіальний» тікет другий місяць не закритий, чому БД не відновлюється миттєво і так далі.

А на такій базі вже можна грунтовно вгризатися в якийсь напрямок.

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

Моё мнение: точка зрения Юрия определяется точкой сидения. Ему как менеджеру важно, чтобы были эдакие универсальные солдаты: сегодня одна технология, завтра- другая. Очень удобно для оутсорсера: можно всех заменить всеми. Но вот беда, зряплата таких универсальных не превышает четырёх штук, ну пяти если человек буквально каждой бочке затычка + работает как проклятый.
В то же время имея экспертизу в редких нишевых технологиях с высоким порогом входа можно получать и выше не слишком при этом напрягаясь. Да, не будет тысячи вакансий как сейчас на жаба — синьора в Киеве, ну так мне и не надо тысяча — надо одна, где будут платить много. И искать такое нужно за пределами манямирка украинского оутсорсинга, но это как раз и хорошо.

82 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

у мене не так багато досвіду в ІТ, та й впринципі прожив я тільки 20 років. Може я й не знаю всього, що знають інші в коментарях. Але я згоден і підтримую такий хід думок.
Універсальність дось тренує мозок, дось не дає знудитись, дось відкриває часто неочікувані горизонти, дось це як розкласти яйця в різні корзини, так спокійніше за завтра, дось універсальність має на увазі добре розумітись в чомусь одному і бути знайомим в усьому іншому, а не все однаково незнати.

👍

Классический T-shape. Автор «топит» за то что «лучше знать понемногу обо всем» чем «быть профи с 20 летним стажем в конкретной специализации». Имха, немного спорное утверждение, "люди разные нужны, люди разные важны"©.

«Лучше знать понемногу обо всё» — это больше про «специалист широкого профиля», а T-shape — это как раз «разбирается во многих областях и является экспертом в одной (нескольких) из них».

T-shape используется в качестве иллюстрации что если перекладина буквы Т широкая — то специались широкого профиля, а если высота вертикальной палки большая — то крупный специалист в одной отрасли.
А следующий шаг — это как раз быть экспертом в нескольких отраслях, когда от широкой перекладины «растут» еще вертикальные палки вниз и человек становится m-shape :)

Тут следует понимать о какой универсальности идет речь. Если универсальность в одной предметной области то это очень даже хорошо (как пример JS разработчик знающий как писать FE, BE, Native и т.д). Если говорим об общей универсальности то это губительно (как пример разработчик знающий как использовать С, С++, Java, JS, SQL, Магию :-), и многое многое другое). Я считаю что нужно быть просто гением чтоб держать в голове всевозможные подходы во всех языках программирования и инструментах, которые ты когда либо использовал, и предпочитаю воспринимать человеческий мозг как коробку с ограниченным размером (не отрицая что у каждого свой размер этой коробки) в которую невозможно все запихнуть.
Я являюсь, как мне кажется, Senior JavaScript разработчиком. По своему опыту, могу сказать что, я сейчас часто сталкиваюсь с проблемой того, что на JS проекты начинают писать BE разратотчики с Java, C# и т.д. И когда проект начинает разростаться на уроветь чуть больше концепта, он уже начинает захлебываться от обилия плохих практик. И клиент в таком случае всегда ищет квалифицированного узкопрофильного специалиста чтоб все исправить.
Мое личное мнение, что широкопрофильный специалист по определению НЕ может быть мастером в своем деле, а может быть только ремесленником (очень часто посредственным).
Он может шедеврально делать одно узкоспециализированное дело, или может посредственно делать много разных дел.

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

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

А у меня скорее вопрос к автору: как соотносятся мастер и ремесленник с широким/узким специалистом? Обязательно ли мастер универсален, а ремесленник — узкопрофилен?

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

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

какой реальный процент мастеров по отношению к ремесленникам на наших широтах?

Адекватный ответ вы не получите, по очень простой причине — контекст и значение слов «мастер» и «ремесленник» определены некорректно и неоднозначно, причина тому изначальная подмена понятия «творец» понятием «мастер» (и привязка этих понятий к «универсальности специалиста»).

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

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

Спасибо за ответ, но не пойму как он поможет с моим вопросом. Потом я спрашивал мнения автора как человека c опытом. Мнение не требует быть истинным.

но не пойму как он поможет с моим вопросом.

Я думал, это очевидно, но попробуем совсем просто пояснить:
Вы и автор говорите на разных языках (вкладываете в одни и те же слова разный смысл).
Поэтому, чтобы узнать мнение автора вам нужно определится со значениями слов, а уже потом задавать вопрос.

Нужно ли объяснять что произойдет если вы не договоритесь о значении слов?

Пожалуй, нужно объяснить чем вы нам поможете и какая ваша конструктивная мысль по данному вопросу?

О проценте мастеров я широкомасштабных исследований не проводил. Можно исходить из опыта работы в предыдущих организациях — это было всегда в районе 20-30-40%. Для организаций, предоставляющих сервисные услуги всегда процент больше. В организациях, где есть своё локальное небольшое подразделение IT (например, мелкие банки) тоже высокий процент.

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

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

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

Вот тут у меня для вас плохие новости.
Практически все клиенты, с которыми я общался, хотели от меня приложение для Андроид с набором нужного функционала. Причём, именно нативное.

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

В моём случае клиент приходит с задачей сделать приложение под Андроид, вот дизайны, вот ТЗ, вот бэкенд. Это не решение, это именно задача. Какое решение я могу ему подсказать?:)
Проконсультировать клиента в вопросах его бизнес-логики? Я как представил, как бы я консультировал голландца — владельца туристической фирмы с 20-летним стажем, как ему с клиентами работать...
Даже в плане UI. Он наймёт профессионального UI/UX дизайнера, который проконсультирует его, какой стиль, цвета и композицию экранов подобрать.
Я могу только проконсультировать его по трудозатратам и стоимости того функционала, который он хочет. И всё.

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

Продать кастомеру мобильное приложение — задача сейлзов, а не разработчиков

Я бы сказал, что специализация должна быть и в области и в технологиях. Вопрос только в том, что реальность другая. У меня есть preferable platform и domain knowledge, с которыми я достаточно времени работал и смогу сделать задачу быстрее любого универсального солдата. В то же время приходиться поддерживать чужой код, дописывать чужие проекты, иногда переписывать их с другого языка, поэтому твои желания часто не совпадают с реальностью. А с третьей стороны, знание многих технологий, языков помогает рассширить «технический кругозор» и иметь background, который позволяет новые технологии осваивать намного быстрее, потому что последнее время ничего особо нового не появляется. Вмысле всякие новые технологии это старые академические идеи, вокруг которых строят новую технологию просто взглянув на проблему под другим углом.

Например, тот же C#, ASP.NET, NHibernate, Dependency Injection in PHP, и многие другие примеры — это обычные копи пасты того, что было сделано в Java под соусом разных framework-ков. Или же Non SQL DBs это по сути наследник расспределенного persistent cache + язык запросов на базе SQL для доступа к нему. Вроде как это новое, а по сути старое, просто сделано лучше и запаковано в продукт.

C#, ASP.NET, NHibernate

Ну C#1 допустим была слябзена с Java,
NHibernate — это по сути порт (на то и N в начале)
Но ASP.NET — эта хрень уникальна

Но ASP.NET — эта хрень уникальна

Чем она уникальна? Это аналог технологии JSF, которой уже 100 лет. Обычная компонентная модель построения UI + MVC. На view ты пишишь asp file с компонентами, на controller обрабатываешь event на server side. Ничего уникального в asp.net нет, таких аналогичных подходов было миллион до выхода его на свет. А еще до JSF был JSP + JSTL...

Я не отрицаю, что asp.net ушел далеко, но изначально это копи паста.

JSF-посмотрел, интересная штука, она вышла правда через 2 года после ASP.NET.

Да и сходство, довольно далёкое.

Просто Microsoft известна copycat-ами, я не думаю, что ASP и ASP.NET изначально была ихнея идея. Но первые версии JSP ~ ASP ~ PHP (скажем похожи). PHP раньше ASP, вышло в 1995 году. Из того, что нашел, ASP появился в 1996.

А по поводу схожести, они реально схожи и там основная идея одна и та же. Я писал на ASP, ASP.NET 2.0 немного и знаю, что по сути это одна и таже идея с JSF. ASP.NET 2.0 больше компонетов, они лучше, но идея как я сказал выше — dynamic web pages + component based UI + MVC.

Вот вытяжка из блога за 2005 год:
ASP.NET is a member of the .NET platform owned by Microsoft and is a successor to Microsoft’s ASP (Active Server Pages) technology that became popular in the 1990s. JavaServer Faces is a member of the J2EE (Java 2 Enterprise Edition) family. JSF can be thought of as the successor to pure JSP (JavaServer Pages) web applications, though JSP is still a supported standard. JavaServer Faces, commonly referred to simply as JSF, is a technology with the backing of software vendors such as Sun, Oracle, and IBM, all of whom have made strong commitments to J2EE.

Together, JSF and ASP.NET share a common goal: bring the same component-oriented, event-driven approach to web development that made programming languages such as Visual Basic so popular. As these two frameworks have evolved, they have become surprisingly similar in many ways

Эта статья оскорбляет чувства Senior Angular V10.1.0 Developers )

Angular з 2 до 10 версій на 99% однаковий. Щоб про щось жартувати потрібно спочатку розбиратися в темі, ІМХО

Те що ви так відповіли ще раз підтверджує тезу про почуття ангулар девелопера версіЇ х.х.х :)

Це якраз нічого не підтверджує. Є фреймворк Ангуляр, в якого невеличкі зміни 2 на рік помпезно перезентуються Гуглом, як щось абсолютно нове і революційне, а народ який не в темі ведеться на це і складає невдалі жарти. Ну буде версія 5 чи 105 один хрін все те саме. Це як ВАЗ 2101 і 2107 — багато там змін? А як би ви сприйняли жарт про механіка СТО саме для ВАЗ 2107 правда ж звучало б доволі тупо? Бо шо то Жигулі, шо то Жигулі. От так само і Ангуляр.

Похер вообще. Подъёб Сергея в том, что не могут быть никакие «Синьор <имя-фреймворка> Девелопер». Ангуляр здесь как пример.

Вважаю, що на початку професійного росту потрібна широта кругозору. Спробувати і те, і се, і п’яте, і десяте. Тим більше, що без серйозного досвіду на серйозний проект потрапити важко. Спочатку поскакати по дрібних проектах, де потрібен «девопс» на всі руки. Просто, щоби стало зрозуміло, що гріє, а що не гріє.

При цьому початковий досвід широкого профілю дуже стане у нагоді, коли є бодай найменше уявлення, що там робиться у суміжників. Як мінімум тому, що буде розуміння, чому так довго валандаються сисадміни з підняттям інстансу, чому в прогерів «тривіальний» тікет другий місяць не закритий, чому БД не відновлюється миттєво і так далі.

А на такій базі вже можна грунтовно вгризатися в якийсь напрямок.

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

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

Мне, как менеджеру, всегда комфортнее работать со вторыми.

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

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

Вы некорректно смешиваете продукт и внедрение или, возможно, подменяете стартап на ранних стадиях словом продукт. Продукт собраный «из говна и палок» будет тратить очень много на саппорт и еще рискует штрафами по СЛА.

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

Как всегда мой дежурный вопрос: если всё так розово, почему Ваша компания ищет людей под конкретные технологии?) Где в вакансиях фразы а-ля «опыт столько-то лет с ООП языком напр. 1, 2 или 3» (которые, кстати, часто звучат в вакансиях Западных компаний, которые в реальности следуют этому принципу, а не на словах)? Все реальные желания декларантов очень хорошо видны на этапе найма.

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

опыт столько-то лет с ООП языком напр. 1, 2 или 3

Вот сегодня видел вакансию в Facebook удалённо, вот реально написано такое

8+ years coding experience in C, C++, Java and/or C#
4+ years coding experience in Perl, PHP, Hack or Python

Страшно подаваться на такое

Тоже видел, в рассылке с remoteok.io пришла).

А чому страшно? Знаючи синтакс С/С++ вивчити Java чи C# не займе багато часу. Писати код, який компілюється, зможете з першого дня. Best practices для конкретної мови швидко підтягнете. А базові принципи чистого коду універсальні.

Трохи знаючи python, дуже легко розібратися із наступною скриптовою мовою. Бажано ще б трохи знати javascript (дуже простий синтакс, якщо знаєте мови із сімейства С і легко зрозуміти динамічні типи, якщо знаєте python), важлива мова для інтернет-компаній.

Я з червня працюю на проекті, повністю написаному на TypeScript. До цього не мав жодного індустрійного досвіду навіть із javascript. І нічого, проект вже зарелізили та ще й виклали на GitHub. Звісно, середній junior із 2 роками typescript зміг би використовувати мову швидше і краще за мене, але задачі змінюються, тому краще мати команду, яка зможе зробити все, ніж шукати спеціалістів під кожну задачу.

Знаючи синтакс С/С++ вивчити Java чи C# не займе багато часу.

Кто знает, я так понимаю в AWS это вполне практикуют.
Про скриптовые языки в целом проще.
Но переходы в стиле «C# -> C++» или «С# -> Java» за неделю или даже пару unreal.
Совершенно другие тулы, либы, дебаг подходы, код стайлы (если в open source).
Я еще понимаю писать «одноразовый» код или мелкие сервисы консоли.
Либо разве-что делая пару строчные фиксы существующего кода.

Із мого досвіду, коли приходиш на новий проект навіть на свою мову, то переважно дають перші таски щось пофіксити і порозбиратися з кодом. Так само і з іншою мовою: вчишся білдити, потім фіксиш якісь баги, додаєш невелику фічу. Особливо корисно писати юніт-тести, там переважно нічого складного, якраз можна вивчити синтакс і відчути мову. Якщо проект довгий, то буде час копнути глибше.

Траплялися мені і одноразові задачі, щось додати в Lua і, навіть, MaxScript — скриптова мова для 3dsMax. З такими задачами не хочеться витрачати багато часу, а тому знання декількох мов дуже корисне, тому що всі вони схожі.

Я з червня працюю на проекті, повністю написаному на TypeScript. До цього не мав жодного індустрійного досвіду навіть із javascript. І нічого, проект вже зарелізили та ще й виклали на GitHub. Звісно, середній junior із 2 роками typescript зміг би використовувати мову швидше і краще за мене, але задачі змінюються, тому краще мати команду, яка зможе зробити все, ніж шукати спеціалістів під кожну задачу.

Опять же, полностью поддерживаю, но украинские реалии другие, потому что диктуются аутсорсом и аутстаффом.

Вузька спеціалізація потрібна там, де потрібний високий рівень кваліфікації.

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

Як тільки проект переростає дендрофекальну фазу MVP — там заводяться окремі архітектори, кодери, тестувальники, дібіеї, сисадміни і так далі. Ну, або не заводяться, і дендрофекальщина росте, цвіте і пахне.

Широкая специализация финансово не выгодна в Украине, понял это когда мигрировал с php+js на java

дополню: php+js (4 года опыта)+java(1.5 год опыта) меньше по деньгам выходило чем senior php или strong middle java, но это было очень давно, до войны. Рекомендую адаптировать резюме под один яп и избегать «многостаночности».

Я за узкую специализацию.

Мені стаття сподобалося. У обох напрямів є свої плюси і застосування. Особисто я прихильник широкого профілю, тут головне знайти компанію, де наймають людину, яка буде вирішувати різні задачі в залежності від проекту, а не вузького спеціаліста на один проект (або на декілька дуже схожих проектів).

Очень люблю компанию DevArt за их продукт DBForge и поддержку сообщества специалистов по работе с данными.
К сожалению, о чём пытался сказать Юрий, после прочтения статьи я не понял. Что хорошо, что плохо?
Лично я всегда сравнивал ИТ-специалистов с врачами. Умеешь всё понемногу как фельдшер или терапевт? Молодец, но много никогда зарабатывать не будешь, хотя всегда будешь в цене и нужен. Кардио или нейрохируг? Несмотря на узкую специализацию тебя все ценят, уважают и ты купаешься в деньгах.
Мне кажется всё просто — чем выше твоя экспертиза в конкретной области тем выше твоя востребованость и заработная плата. Причём смежные знания и понимание предметной области — это не плюс, это необходимая составляющая роста, без которой стекляный потолок не пробить.
Тот же упомянутый выше ДБА далеко не уйдёт без хотя бы базового понимания работы сетей, хранилищ данных и операционной системы. А системный архитектор — это тот же фул-стек разработчик который понимает как строится информационная система на всех уровнях, будь это небольшое мобильное приложение или очередной энтерпрайзный ЕРП-комбайн.
Поэтому общий посыл прост — постоянный рост. Смотрим на раковую опухоль и берём пример.
Если же отбросить шутки в сторону, то радует, что в DataArt есть подразделение Global People Development. Как я уже не раз повторял, с компаниями, которые инвестируют в своих сотрудников — нам очень даже по пути. Главное, не пытаться сделать из людей затычку на каждую бочку. Выгоднее научиться дорого продавать своих элитных узкоспециализированных бойцов.

А мне очень нравится компания JetBrains и их продукт Rider. Очень не хватает NCrunch, так как он, к сожалению, разрабатывался только под VS и плагин под Rider даже не планируется. Статью, кстати, не читал.

JetBrains вообще молодцы. Нужно будет глянуть этот Rider, спасибо

Моё мнение: точка зрения Юрия определяется точкой сидения. Ему как менеджеру важно, чтобы были эдакие универсальные солдаты: сегодня одна технология, завтра- другая. Очень удобно для оутсорсера: можно всех заменить всеми. Но вот беда, зряплата таких универсальных не превышает четырёх штук, ну пяти если человек буквально каждой бочке затычка + работает как проклятый.
В то же время имея экспертизу в редких нишевых технологиях с высоким порогом входа можно получать и выше не слишком при этом напрягаясь. Да, не будет тысячи вакансий как сейчас на жаба — синьора в Киеве, ну так мне и не надо тысяча — надо одна, где будут платить много. И искать такое нужно за пределами манямирка украинского оутсорсинга, но это как раз и хорошо.

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

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

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

Взаимозаменяемость — это важный фактор снижения рисков в проекте, от которого выигрывают как заказчики так и исполнители.

В чем выигрыш исполнителя?
Давайте определимся что «исполнитель» — это специалист, который работает на проекте, а не компания, которая получила заказ и наняла для его реализации специалиста.

Универсальность выгодна лично, если потом строишь свой бизнес. Статью, не читал)

Наприклад, коли вам потрібно взяти відпустку, то вам її без проблем дадуть, тому що ваші завдання можна завжди делегувати комусь іншому. І коли є ціла команда із широкою специфікацію, то легше розподілити навантаження.

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

Наприклад, коли вам потрібно взяти відпустку, то вам її без проблем дадуть, тому що ваші завдання можна завжди делегувати комусь іншому.

Заезженный пример и при этом он совсем не отвечает на заданный вопрос.
Пользуясь логикой вашего ответа:
Лучше меть узкую специализацию, потому что тогда вас не смогут уволить или не переедет грузовик :)
Фактически ваш пример, это ответ на вопрос «зачем менеджеру/компании нужны заменяемые люди». Зачем это «исполнителю» все еще не понятно.
А еще можете подумать что сделает уважающий себя человек, если его «не отпустят в отпуск, потому что в компания не смогла организовать замену для его роли».

І коли є ціла команда із широкою специфікацію, то легше розподілити навантаження.

Это снова же проблема менеджера, а не исполнителя.

Зачем это «исполнителю» все еще не понятно.

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

А при чём тут Делфисты, они были как раз «универсальными» десктопщиками для бизнеса.
Потребность в целом уменьшилась в таких приложениях.
Или как уничтожили насильно Flash/Silverlight.

Да, тоже и про Silverlight хотел сказать, но с него было проще перейти на другие фреймворки, наверное, ведь язык тот же.

то до того момента, пока на рынке достаточный спрос на скил. Достаточно помотреть на сколько востребованы дельфисты сегодня

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

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

Как человек который был для своего проекта «взаимозаменяемым» могу сказать что основной выигрыш — это визибилити для бизнеса/менеджеров, но при этом узконаправленный специалист так же может этого достичь без особых проблем, потому что это больше про инициативность чем про навыки.

как исполнитель выигрывает от того что он взаимозаменяемый в рамках определенного проекта?

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

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

Ой, а я вот малозаменимый и я не таскаю с собой ноут. В отпуске не отвечаю на сообщения просто. Не нравится? Не мои проблемы! Мы договаривались о отпуске заранее

Ты же DSL пишешь. Это немного отличается от того, что клиенты/пользователи не могут получить доступ к системе или к данным в случае outage-а.

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

Это вся та же проблема менеджмента, а не исполнителя.
Фактически выигрыш будет за счет

это больше про инициативность чем про навыки.

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

как исполнитель выигрывает от того что он взаимозаменяемый в рамках определенного проекта?
Мы о чем дискутируем? В своем предыдущем посте я отвечал на вопрос

как исполнитель выигрывает от того что он взаимозаменяемый в рамках определенного проекта?

Ок, вся эта дискуссия была в контексте «универсальности» исполнителя, о которой идет речь в статье.
О том что не нужно замыкать на себе — тут все понятно и вопросов нет.

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

а в студии вообще один может записать партии 3х инструментов)

Соло гітарист зможе зіграти на басу, а от навпаки вже наврядчи.

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

та чего извиняться)) погугли мемы про басистов :D
на самом деле действительно хороший басист ценнее гитариста.

Фулстэк басист. Играть в нашем коллективе большая честь!

Взаимозаменяемость

Це ок, але ніколи Девопс не замінить Фронтендера чи Бекенд не замінить Аналітика, рівно як і Qa не зможе замінити Ембедед девелопера, рівно як і Ембеддер не замінить Мобайл розробника.

Само собою, що на одному проекті один фронтенд розробник замінить іншого фронтендера чи бекен розробник іншого бекендера, навіть якщо вони працюють трохи з іншими фреймворками чи з різними модулями однієї ентерпрайз системи, хоча теж можуть бути нюанси.

Володимир і решта коментаторів тут говорять про те, що повної універсальності досягти в принципі майже не можливо або така людина володітиме всіма компетенціями на рівні середнього мідла, максимум.

Якщо ви в статті мали на увазі змогу замінити спеціалістів в рамках напряму(девопс, Qa, Front, Embedded, mobile), то це так, з цим ніхто не сперечається, сініор розробник повинен мати змогу розібратись в новому фреймворку чи новому модулі по дефолту.

Спеціаліст у вузькому напрямку звісно буде переважати спеціаліста із широкою спеціалізацією саме в цьому напрямку. Але не у всіх компаніях є окремі посади DevOps і QA.

Це ок, але ніколи Девопс не замінить Фронтендера чи Бекенд не замінить Аналітика, рівно як і Qa

Тому я б не казав ніколи, тому що це не рідкість, коли один розробник виконує всі ці функції і такий підхід теж працює.

Спеціаліст у вузькому напрямку звісно буде переважати спеціаліста із широкою спеціалізацією саме в цьому напрямку.
Тому я б не казав ніколи, тому що це не рідкість, коли один розробник виконує всі ці функції і такий підхід теж працює.

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

Какая у тебя специализация, если не секрет?

Парсеры, компиляторы, трансляторы, плагины под идею и иклипс

Подписаться на комментарии