Я много думал на эту тему.

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

Конечно, это преувеличение, но такое было направление мысли.

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

И это абсолютно нормально.

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

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

❓Так в чем же все-таки их отличие?

Синьор разработчик оперирует гораздо большим контекстом.

Приведу пример: нужно добавить зависимость от нового признака - другими словами, просто еще один if, не больше, ни меньше.

Мышление не синьора:

  • где написать код
  • проверить работоспособность
  • написать юнит-тест на новую логику (в лучшем случае)
  • обновить документацию (в идеальном случае)

💪 Мышление синьора:

  • за что отвечает новый if: в какие продуктовые метрики целимся
  • насколько это важный функционал, нужно ли предусматривать graceful degradation в нештатных ситуациях
  • правильно ли это делать на уровне потенциально рассматриваемого сервиса
  • уведомлены ли владельцы сервиса или домена, где происходят изменения, о новом функционале (если нет - сначала согласовать)
  • увеличится ли нагрузка на сервис или связанные с ним системы (если да - сначала согласовать)
  • какие есть ограничения мобильных клиентов (есть ли завязка на версию приложения и пр.)
  • какими техническими метриками нужно покрыть код
  • какие логи нужно собирать
  • нужна ли аналитика
  • (. . .)
  • и только затем 4 пункта: где написать код и т.д.

Конечно, по факту решение может быть абсолютно таким же (код в каких-то местах может быть даже хуже).

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

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

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

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

Читайте оригинальный пост и присоединяйтесь к обсуждению в Телеграм: @time2code