Как я стал стопроцентным разработчиком — будучи младшим
4 января 2023 г.Представление о том, что 10-кратный разработчик или разработчик-звезда лучше любого другого разработчика во всем, является мифом.
Вместо этого вы должны стремиться быть 100-кратным разработчиком в очень конкретных ситуациях, 10-кратным разработчиком в некоторых и 1-кратным разработчиком во всех возможных. Важно знать, в каких областях вы преуспеваете, и в каких областях вам, возможно, придется поработать.
Если вы не работаете в крупной технологической компании, скорее всего, вы будете носить несколько шляп. Ежедневно вам нужно будет иметь возможность переключаться между интерфейсом, сервером и разработкой для конкретного языка, например Java или TypeScript. Это связано с постоянно меняющимся характером нашей отрасли и огромным количеством способов решения одних и тех же задач — например, напечатать «Hello World» на более чем 400 различных языках программирования.
Невозможно быть хорошим во всем, но можно быть лучшим в чем-то.
Для уточнения я хотел бы поделиться историей более чем десятилетней давности, которая стала моментом, изменившим мою жизнь и оказавшим огромное влияние на мою карьеру.
Как я стал 100-кратным разработчиком — будучи младшим
Я работал с крупной ТНК и был частью команды, которая изо всех сил старалась не отставать от спроса.
Они создали специальное веб-приложение Java, которым ежедневно пользуются тысячи сотрудников, но по мере увеличения количества входящих и исходящих записей на серверах SQL. Дела замедлялись. Они уже обновили сервер SQL до предела своих возможностей и нуждались в новых решениях. Очевидным было использование memcache для кэширования некоторых результатов.
К сожалению, memcache был запрещен из-за некоторых инцидентов безопасности в прошлом и отсутствия HA. Менеджеры пытались получить одобрение для memcache больше года, но безуспешно. Тем временем разработчики вели тяжелую битву, поскольку каждое улучшение на 10 % сводилось на нет удвоением роста числа пользователей.
Здесь я пришел и присоединился.
Я понятия не имел об их прошедшем годе борьбы, и меня пригласили в качестве младшего разработчика, чтобы помочь внести небольшие улучшения в пользовательский интерфейс, в то время как старшие сосредоточились на производительности.
Однако из-за того, что меня очень раздражала низкая производительность сервера разработки. И я играл с Hazelcast — совершенно новой библиотекой для кластеризации и кэширования серверов на основе Java.
Я использовал его как альтернативу memcache. И смог запустить его в приложении, у которого не было особых ограничений или особых требований к утверждению, что убило все предыдущие решения.
И рабочий прототип с демоверсией был готов в течение той же недели. Для одной страницы на платформе вызовы API сократились с более чем 10 секунд до менее секунды. Это изменило правила игры.
Вся команда присоединилась к нам, и в течение месяца у нас было «решение для кластеризации, которое определенно не является кэшем памяти» в производственной среде.
Когда мой менеджер команды и его босс угощали всех банкетом, мой менеджер сказал мне, что, когда он взял меня на борт в качестве умного ребенка, он никогда не ожидал, что я стану программистом в 10 или 100 раз, который может решить их проблемы за одну ночь.
И это утверждение сильно поразило меня.
Потому что я был самозванцем — просто удачливым самозванцем.
Счастливчик-самозванец — разработчик со скоростью 0,1x
Технически я не был 1-кратным или даже 10-кратным разработчиком. Я знал меньше, чем мои товарищи по команде, и учился на работе.
Мои коллеги могли делать внешний интерфейс лучше меня, и команда знала, как оптимизировать SQL (и научила меня, спасибо!). Моя самая большая заслуга заключалась в том, что я смог сделать эквивалент «чуда установки npm» и прочитать его руководство о том, как его настроить.
Оглядываясь назад, можно сказать, что мне повезло избежать многих проблем.
* Политика (которая в первую очередь заблокировала memcache) * Вариант использования (у нас не было защиты от конфликтов при записи, то есть, если 2 редактирования происходят в одной и той же мс, кеш будет обновлен плохо. К счастью, это редко когда-либо случается) * Стабильность (v1 hazelcast аварийно завершает работу, к счастью, сервер API был разработан для развертывания в режиме HA, так что в худшем случае это раздражало команду инфраструктуры) * Безопасность (иметь открытый порт для всех данных на сервере API в кластере было плохой идеей с моей стороны и очень младшей ошибкой, пока другой старший, к счастью, не прочитал документы о том, как его защитить) * Языковой стек (если бы сервер был на Python, .NET, C# или Ruby, я бы понятия не имел, как включить даже локальный кеш кластера)
Мне повезло, что у меня было несколько пони с одним трюком, которые делали меня в 100 раз сильнее в нужных ситуациях. Это стало возможным только благодаря фундаментальной работе, проделанной остальной командой.
Мне также повезло, что мои менеджеры и начальники позволили мне выбрать проблемы, которые я хотел решить, поскольку они быстро отследили меня и бросили меня в несколько команд, чтобы «решить их проблемы». При этом позволяя мне максимизировать соотношение удачи к результативности и повторять «чудеса».
С опытом я также понял обратное — я медлителен во фронтенд-разработке. Это было то, чем я изначально должен был заниматься до того, как стал 10-кратным инженером, и это заставило меня много размышлять на протяжении многих лет. Поскольку это мог быть путь, на котором я бы застрял.
Меня также поразило это задним числом, когда я «освоил» hazelcast и различные другие технологии. Насколько это было бы провалом для других команд, даже в той же организации, если бы не уникальная ситуация и меры предосторожности, которые должны были быть зачислены на счет остальной команды.
В юниорском возрасте мне повезло, во всяком случае.
https://twitter.com/CenturiiC/status/1566060367825883136?embedable=true
Вот почему старшие разработчики, как правило, в 10 раз больше младших разработчиков
Если выйти за рамки инженерных обобщений, становится ясно, что у каждого есть свои навыки, которые могут варьироваться от 100x до 0,1x.
С годами, когда я сменил множество команд и проектов, я в конце концов стал «старшим» разработчиком. За это время я понял, что у пожилых людей обычно больше навыков, и они знают, в чем они хороши, а в чем плохи. Они могут заблаговременно информировать своих менеджеров и соответствующим образом расставлять приоритеты задач. Это не значит, что они знают, как делать все, но они знают, чего делать нельзя.
Юниоры, с другой стороны, борются с этим, поскольку им не хватает опыта, чтобы понять, в чем они хороши, а в чем плохи. Нет простого способа выяснить это, кроме как просто «попробовать».
Как только это осознается, становится очевидным, что все дело в максимизации количества вещей, которые, как вы знаете, вы можете делать надежно и хорошо. Это также о том, чтобы максимизировать ваш фактор удачи, когда дело доходит до назначения задач, и следить за тем, чтобы вы не застряли на вещах, в которых вы плохи.
В каком-то смысле для юниоров их прогресс будет сильно зависеть от их удачи и набора навыков. Пожилые люди имели больший (но не полный) контроль над тем, как управлять своим прогрессом.
В данном случае: Удача не бинарна. Вы можете увеличить количество ситуаций, которые вам подходят.
Как увеличить удачу в ситуации в 100 и 10 раз
Для всех, но особенно для юниоров и тех, кто только начинает, лучше всего продолжать пробовать новые технологии и исследования. Это поможет вам понять, в чем вы хороши, а в чем нет.
Для тех, кто лучше понимает, в чем они хороши, следующий шаг — увеличить количество ситуаций, в которых они могут проявить себя наилучшим образом. Это включает в себя некоторую практику и исследование технологий, смежных с теми, которые они уже знают. Как только вы станете мастером в чем-то, убедитесь, что вы владеете этим, чтобы ваши менеджеры и начальники знали, что это то, что они должны вам дать. Это повысит шансы на попадание в эти 10- или 100-кратные ситуации чаще.
Найдите хотя бы одну вещь, в которой вы хороши, даже если это очень маленькая и узкая вещь. Стройте оттуда. (Некоторые известные примеры включают регулярное выражение и настройку веб-пакета.)
Для пожилых людей, если вы еще этого не сделали, начните смотреть дальше технических аспектов разработки. Это не означает, что вы должны перейти в управление. Но с вашими уникальными техническими знаниями вы можете играть более активную роль в понимании пользовательского или бизнес-варианта использования. Это позволит вам оптимизировать работу с вашими менеджерами, чтобы обеспечить 10-кратный или 100-кратный успех для вас и вашей команды.
Для тех, кто ищет работу: если вы знаете, что хороши в чем-то, даже если это в 10 раз больше, проведите небольшое исследование и углубитесь в поиск работы. Попробуйте найти хорошо финансируемый стартап или транснациональную корпорацию, которая сталкивается с трудностями именно в том, в чем вы хороши. Хотя это может быть трудно осуществить и требует определенных связей, если вы окажетесь в нужном месте и в нужное время, это максимизирует влияние как для вас, так и для вовлеченной компании.
Это все вещи, которые вы можете делать медленно с течением времени, чтобы улучшить фактор удачи. И доставляйте 10-кратный опыт более последовательно.
<цитата>Приглашаем прочитать статью swyx о том, как привлечь удачу: swyx.io/create-luck
Сегодня, как технический директор и руководитель группы, это по-прежнему актуально: 10-кратное увеличение — это миф, у всех есть и 100-кратное, и 0,1-кратное
Некоторые могут подумать, что технический директор инструмента тестирования пользовательского интерфейса, такого как Uilicious.com, будет хорошо работать с интерфейсными технологиями. Однако это далеко от истины. Наш средний новый сотрудник или джуниор в компании, как правило, быстрее, чем я, технический директор, когда дело доходит до написания интерфейсных компонентов с помощью современных интерфейсных фреймворков, таких как Vue.js или React.
Это изменило мою точку зрения как лидера/менеджера команды. Это показало мне, насколько ядовит и вреден миф о 10-кратном инженере. Это чрезмерное упрощение ярлыков и обобщение очень уникальных ситуаций. Это ядовитое заблуждение, которое необходимо исправить.
При более глубоком рассмотрении почти в каждом мифе о 10-кратном инженере стартапа оказывается, что человек с уникальными знаниями находится в нужном месте и в нужное время. И смог избежать задач, в которых они были 0,1x.
В моем случае это было сосредоточено на инфраструктуре, а не на разработке интерфейса. Вместо этого у меня есть другие члены команды, которые в 1000 раз лучше разрабатывают интерфейс.
Это важное осознание для менеджера, потому что для каждого человека, выполняющего одну задачу в 100 раз, есть задача, которая увеличивает его в 0,1 раз, поскольку он застревает в стоке времени. Речь идет о понимании и распознавании того, в чем каждый человек в 100 раз больше, а в чем он в 0,1 раза.
Хотя это звучит очень просто, на практике это значительно сложнее.
Есть много вещей, о которых руководитель группы или разработчик не узнает, пока не попробует это сделать раньше. Или им предоставляется время и возможность отточить и освоить наборы навыков, связанных с этими конкретными ситуациями. Есть также много вещей, особенно новые технологии, в которых никто не разбирается, и все они основаны на риске и шансах.
Задача руководителя группы — организовать задачи таким образом, чтобы они наилучшим образом соответствовали потребностям каждого. И если это невозможно, важно также понять, что даже если кто-то не может быть в 100 раз больше в вашей ситуации сейчас, он потенциально может быть где-то еще в других командах.
И каждый отдельный разработчик должен выяснить, в чем он хорош, а в чем плох, и соответствующим образом сообщить об этом своей команде.
Итак, к черту миф о 10-кратном инженере, да здравствует 100-кратный инженер в определенных ситуациях
PS: Если вы еще не приняли никаких новогодних решений. Возможно, это поможет увеличить площадь вашей поверхности удачи!
~ 🖖 живите долго и процветайте
Юджин Чеа: технический директор uilicious.com
Первоначально опубликовано на: https://substack. tech-talk-cto.com/p/dev-to-cto-how-do-i-become-a-10x
Изображения предоставлены
- Остин Нил — изображение рок-звезды: unsplash.com/photos/sxxnM-tRlVg
- XKCD — комикс о стандартах: xkcd.com/927
- CenturiiC – комикс об опытных инженерах: twitter.com/CenturiiC/status/15660603678258..
- Лукас Сантос – изображение с игрой в кости: unsplash.com/photos/XIIsv6AshJY
- Влад Хилитану - Фигурки Lego: unsplash.com/photos/1FI2QAYPa-Y
Оригинал