С тех пор, как я начал работать на себя, заключая контракты, меня постоянно тяготило то, что, будучи разработчиком-универсалом, на рынке труда мне приходится позиционировать себя как узкого специалиста. Я уже много лет хотел написать об этом и даже делал кое-какие заметки. Решающим же толчком послужила встреченная мной недавно статья Бена Коллинса-Сассмана, хоть она и затрагивает эту тему лишь косвенно.
Ниже я опишу сложности, с которыми мне приходилось сталкиваться. Надеюсь, эта информация окажется полезной для других вольных авантюристов. Прошу учесть, что статья отражает преимущественно мой личный опыт, так что делайте на это скидку.
▍ Необходимость позиционировать себя как специалиста
Очень точно мою идею передаёт следующее высказывание одного из пользователей Hacker News: «В теории все компании предпочитают гибких сотрудников, способных адаптироваться. На практике же я вижу, что в большинстве объявлений о вакансиях предпочтение отдаётся специалистам». То есть, даже если вы универсал, при поиске работы вам может потребоваться преподнести себя как специалиста.
Принять этот факт мне удалось не сразу. С тех пор, как я начал возиться с компьютерами, у меня никогда не возникало потребности представлять свои навыки в рамках некой конкретной категории. Я считал себя хакером в широком смысле слова, и для меня этого было достаточно. Мне даже посчастливилось начать свою карьеру программиста в компании, которая разделяла это видение и активно нанимала любознательных универсалов. Вот были времена!
Однако, когда я стал работать по контракту, подход с позиционированием себя как универсального разработчика утратил эффективность. Потенциальные клиенты хотели слышать что-то, вписывающееся в знакомые им понятия, а не туманные заявления в стиле «Я компьютерный эксперт». Они задавали вопросы вроде: «А вы бэкенд или фронтенд-инженер?», «Вы программируете на .NET или Python?», «Вы специализируетесь на AWS или Azure?» И так далее.
И я их не виню. Думаю, непросто в должной степени оценить перспективу найма универсала, когда вам требуется (или вы думаете, что требуется) знаток конкретного стека технологий. И хотя я смог найти нескольких клиентов, которые оценили меня как универсального разработчика, мне пришлось изменить свою стратегию переговоров.
▍ Говори людям то, что они хотят слышать
К концу 2022 года я начал позиционировать себя как специалиста: профессиональный разработчик на Rust с акцентом на программировании систем и опенсорсных проектах. Стало это везением или результатом гениального решения, но сработало сразу, и клиенты обращались ко мне весь 2023 год!
Выбор именно такого профессионального образа был обусловлен множеством факторов:
- Я состою в сообществе Rust с 2014 года. Пусть я и не завоевал в нём широкую известность, но могу с уверенностью сказать, что знаю этот язык хорошо.
- Благодаря участию в жизни сообщества, я получил прекрасный опыт работы в опенсорс-проектах, чем поистине наслаждался. Так что поиск профессиональной занятости в этой сфере выглядел для меня естественным.
- Мне нравится разрабатывать, как я это называю, «фундаментальное ПО» (создавать строительные кирпичики вместо склеивания API), а Rust типично используется для этой цели (если же вы создаёте CRUD (функциональность Create, Read, Update, Delete), то ИМХО лучше использовать другой язык и экосистему).
- Я искренне люблю Rust, несмотря на его несовершенство.
- За последнее десятилетие популярность Rust в индустрии стабильно растёт, так что ставка на этот язык внушала уверенность.
▍ Выходит… я всё же стал специалистом?
Так может показаться со стороны, но если смотреть изнутри, то я всё равно скрытно остаюсь универсалом.
Во-первых, каждый взятый мной проект Rust требовал использования широкого набора навыков и хакера. Мне приходилось переключаться на совершенно новые предметные области и базы кода, когда единственным общим знаменателем оставалась реализация проектов на Rust.
- Расширение Quinn, созданная сообществом реализация протокола QUIC: я создавал в ней дополнительную функциональность1 и написал документ RFC.
- Разработка пакетного менеджера для экосистемы Python / Conda: я создал механизм разрешения зависимостей, который в итоге стал библиотекой resolvo. Это был первый раз за всю мою карьеру, когда мне платили за чтение научных работ. Я будто снова вернулся в университет… Было здорово!
- Создание бенчмарка производительности для rustls, популярной реализации протокола TLS на Rust: в качестве образца я использовал систему анализа производительности из компилятора Rust и после глубокого изучения вопроса реализовал аналогичную систему для rustls.
И даже после множества различных проектов Rust у меня всё равно есть повод продолжать считать себя универсалом, поскольку я также работаю над совершенно не связанными между собой вещами. Вот, к примеру, несколько из моих профессиональных проектов:
- Разработка и обслуживание пакета десктопного ПО для нетехнической команды химиков (C# / .NET).
- Разработка и обслуживание веб-приложения, помогающего вести бухгалтерию некоммерческим организациям (C# / .NET).
- Один день в неделю руководство2 стартапом (построен на Python, но программированием я почти не занимаюсь).
▍ Мои выводы
Парадоксально, но, выходит, нужно позиционировать себя как специалиста, чтобы в итоге работать над разносторонними проектами! Как так?
Начнём с проектов, не относящихся к Rust, которые я отметил последними. Ко всем трём меня привлекли люди, которых я знал лично, и которые искали «проверенного компьютерного эксперта». Этих людей не интересовало, как я представлен в интернете. Им просто нужно было что-нибудь реализовать, неважно на какой технологии. В этом смысле я бы сказал, что позиционирование себя как специалиста никак не повлияло. Для этих заказчиков было важно лишь то, что мы доверяли друг другу, и то, что я имею высокую квалификацию как разработчик.
А вот в случае проектов Rust самопрезентация играла ощутимую роль. Клиенты ещё меня не знали и хотели получить некое подтверждение моих возможностей. Похоже, что здесь источником доверия выступала моя репутация в сообществе Rust. Они видели, что мейнтейнеры опенсорса ценят мой вклад в проекты, что однажды я написал RFC для этого языка, а также получал рекомендации от авторитетных участников экосистемы и так далее.
Исходя из всего этого, я делаю вывод, что акцент на опыте в конкретной технологии и участие в конкретном сообществе позволяет заслужить доверие среди людей, которые плохо тебя знают. И по мере роста доверия возникает всё больше возможностей для проявления скрытых разносторонних навыков.
▍ Призыв к дискуссии
Сталкивались ли вы с проблемами, обозначенными в этой статье? Мне очень интересно услышать о вашем опыте на тему поиска клиентов, подхода к самопрезентации, страха случайно стать специалистом и прочем.
Пишите мне на почту или присоединяйтесь к дискуссии на Hacker News.
▍ P.S. Как мой подход менялся со временем
Если вы откроете историю Git страницы «Hire Me» моего блога, то увидите, что содержание этой страницы периодически видоизменялось. Это изменение отражает эволюцию моего понимания того, как лучше представлять свои услуги миру.
Всю свою историю эта страница начиналась со списка «Things I can do for you». Но со временем этот список сильно изменился. Его изначальная версия включала очень много услуг, в том числе «причудливые идеи вроде ведения семинаров на тему Plato and Programming» (это реальная цитата, можете ознакомиться подробнее, если вам интересен её контекст). На момент же написания этой статьи список содержит всего 3 пункта и является намного более акцентированным.
И даже после всех этих изменений я всё ещё недостаточно удовлетворён результатом. Думаю, это необходимое ограничение – втискивать свою душу во всего несколько пунктов. Обхожу я это ограничение за счёт написания статей, которые дают людям возможность лучше узнать меня (при условии, что у них есть время и интерес). Порой это даже ведёт к заключению контрактов, чему я всегда рад!
▍ Примечания
1. Это функциональность DPLPMTUD, позволяющая реализации QUIC определять MTU (maximum transmission unit, максимальный размер полезного блока данных одного пакета), поддерживаемый сетевым путём. Она описана в RFC 9000. ↩︎
2. Я не уверен, как лучше назвать себя в этой руководящей роли. Некоторые в таких случаях используют термин Fractional CTO (что-то вроде «технический директор на полставки»), но наша команда состоит из всего 4 человек, так что это будет преувеличением. ↩︎
Автор: Дмитрий Брайт
