Гипер-специализация
В этой заметке есть щепотка зауми. Формат изложения можно коротко описать как: типичный бухтёж про “раньше было лучше и трава зеленее”. В последнее время я всё чаще встречаюсь с ситуацией, когда мне отказывают даже в собеседовании если у меня нет коммерческого опыта N лет в технологии X. И это меня раздражает. Теперь резко перейдём к философии. Детали моего личного опыта будут в конце заметки.
Идея разделения труда
Идея разделения труда в общем смысле полезна. Эффективность рабочих процессов в случае, когда один человек занимается ограниченным набором задач на конвеере, не подвергается с моей точки зрения сомнению. Это легко доказать и самостоятельно, в быту, без обращения к классикам. Частое переключение контекста задач вызывает большую (дополнительную, излишнюю) когнитивную нагрузку и мешает эффективности.
Проблемы начинаются тогда, когда парадигму разделения труда на конвеере начинают распространять в виде требований при найме работников. Я, как программист, не претендую на позиции химика или физика-теоретика. Но в сфере ИТ я не вижу преград пользоваться разными ЯП, стеками, средами разработки и т.д.
Гипер-специализация
Но, что интересно, мы сейчас по уши находимся в мире гипер-специализации. Я слышал и термин супер-специализация, но слово гипер, по личным ощущениям, лучше описывает те тотальные проблемы, с которыми многие сталкиваются каждый день.
Гипер-специализация подразумевает обязательное разделение на работников по инструменту в рамках специализации. Т.е. ты не просто “программист”, а уже “программист C++” или “программист Java”. А может, “программист Python”. Это названия реальных вакансий. Звучат они как “рабочий с молотком” или “рабочий с отвёрткой”. Какой смысл в такой постановке? А ведь здесь есть масса проблем.
Самая основная из проблем для общества – проблема гибкости рынка труда. Не работавший с каким-либо инструментом человек отсеивается ещё на этапе подбора кандидатов. Страшно и то, что подбором теперь занимаются, в первую очередь, не сами разработчики, а HR-специалисты, которые, в силу их рабочей специализации, не могут, даже близко, оценить общую компетентность работника. HR’ы, естественно, будут пользоваться списком инструментов из вашего резюме. Конечно же, не ожидайте, что HR поймёт разницу между Java и JavaScript.
Я уже достаточно пожил, чтобы помнить, как ещё в начале 2010-х годов мои собеседования происходили сразу с будущими коллегами и руководителями. Разница тогда была кардинальная. Прыгать между инструментами разработки можно было даже в рамках компании, что мне приходилось делать. Один день пишешь на Groovy, через месяц уже на C++ и вот, у тебя уже .NET! Сейчас же ты привязан к тому инструменту и ЯП, с которым ты уже работал, согласно твоему резюме…
Инструмент = идентичность?
В таком мире, когда тебя отбирают по твоему основному инструменту, ты неизбежно принимаешь частичку идентичности, связанной с ним. Большое количество Java привязало меня к типизации времени компиляции, и я к такому привык. Но я не стал мыслить шаблонами, как это бывает в приколах про pattern overuse в Java.
Кроме Java я поработал много и с Kotlin, Си, C++, JavaScript, TypeScript, Python, Haskell, Clojure и многими другими ЯП. Опустим мириады сопутствующих технологий как БД, фреймворки, библиотеки и всевозможных API для интеграции.
И от использования каждого инструмента я тоже научился чему-то, обогатил картину своего мировоззрения, понял схожести и различия. Понял сильные и слабые стороны. Скажу вам так: не нужно делать ставку на один инструмент для всего. Понятно, что когда в руках молоток, то всё может казаться гвоздём. Но это не так. Необходимо понимать, что закручивать саморезы надо чем-то другим. Иначе выйдет чепуха.
Чтобы сформировать правильное мировоззрение, которое поможет определить, что и когда стоит использовать, и нужно иметь опыт во многих смежных областях, а также с большим количеством инструментов, подходов и практик. В общем смысле слова, надо качать философию как профессиональный навык, наблюдая за миром.
Единственный верный вывод, который я вижу для себя – не связывать полностью свою идентичность с инструментом, который помогает мне решать рабочие задачи.
Личный опыт
У меня нет розовых очков, я понимаю, что для каких-то задач действительно нужно много опыта с определёнными подходами и подтягивать новенького до приемлемого уровня может быть дольше, чем найти специалиста. Пример – разработка БД. Но в таких задачах куда более важно понимание фундаментальной базы и знание основ предметной области, а далеко не умение работать с языком программирования Y.
Казус в следующем. Последний отказ от уже назначенного командой разработки собеседования я получил от “руководителя проекта”. По фидбеку HR, он посчитал, что в меня надо “вкладываться”, т.к. я – не практикующий питонист. Да-да, нет у меня Python, Карл! Особо отмечу, что команда была довольна резюме и уже успела назначить собеседование, которое было отменено на следующий день. Вот дела!
Компьютерами, программированием и технологиями я горю с раннего детства. И с Python я, конечно же, пересекался. Да, я не пользуюсь Python day-to-day и он никогда не был основой проектов, в которых я работал. Но этот бложик собирается с помощью того же Python. Большая часть open-source, с которым я взаимодействую на ежедневной основе – на Python. И в этом софте часто надо покопаться…
Это уже не первый раз, когда мне отказывают в собеседовании из-за отсутствия 5-и лет опыта работы с ЯП. Но неужели кто-то действительно считает, что разработчик, который посвятил только по бумагам больше 10 лет своей жизни разработке и сопровождению ПО, не осилит написать код на Python? Б-Е-З-У-М-И-Е.