Что отличает сеньора от джуниора? 15 вещей, которые я хотел бы узнать раньше

Перевод статьи «What is the difference between a junior and a senior software developer? 15 things I wish I had known sooner».

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

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

Все это я узнал в Amazon, в рамках учебной сессии по дальнейшему продвижению. От сеньоров ожидается, что они могут сами разобраться, как решить задачу, в то время как джуниорам нужно указывать направление. Это не значит, что сеньоры все знают. Но они точно знают, когда и как задавать вопросы, а чтобы этому научиться, нужен опыт. Сеньоры берутся за задачи, которыми никто другой не хочет заниматься и которые нельзя решить простым поиском в Google.

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

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

15 вещей, которые я хотел бы узнать раньше

Как работать более эффективно

1. Для каждой задачи, над которой работаете, нужно иметь четкое определение конечного результата

Это помогает планировать работу, фокусироваться на том, что следует сделать, а также облегчает составление документации. Даже если у вас какая-то сложная и неоднозначная задача, у нее все равно должна быть понятная цель (например, выбор между технологиями А и В).

2. Определяйте масштаб работ

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

3. Оценка временных затрат — трудная задача

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

  • проектирование и выбор решения,
  • изменение или добавление новых тестов,
  • ожидание, пока коллеги одобрят мой пул-реквест.

4. Правильный подход

Взгляните на принципы лидерства Amazon. Они представляют правильный подход к продвижению на сеньорский уровень. Особо стоит отметить:

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

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

Как оптимизировать работу

5. Автоматизируйте

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

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

6. Работайте инкрементально

Не нужно писать тысячу строк кода и лишь затем запускать тесты. Работайте и проверяйте свои изменения инкрементально. Проверяйте, компилируется ли ваш код или вы забыли импортировать нужную библиотеку. Куда проще делать все правильно сразу, а не переделывать небрежную работу. Пишите читаемый код и модульные тесты, вносите небольшие улучшения и т. п.

7. Преждевременная оптимизация — корень всех зол

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

8. Купите себе резиновую уточку

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

9. Пересматривайте свои предположения

Когда что-то идет не так, проверяйте свои допущения и предположения. Мне случалось просиживать долгие часы за отладкой, когда проблема была в:

  • чтении не того конфигурационного файла,
  • использовании устаревшей информации из внутренней wiki-страницы,
  • чужом коде,
  • неаккуратном копипасте.

10. Читайте документацию

Я тоже ленился читать документацию. Если документация в вашей команде непонятная или неполная, улучшайте ее.

11. Остерегайтесь комментариев

«Код никогда не врет, а вот комментарии, бывает, врут», — Рон Джеффриз.

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

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

12. Учитесь коммуницировать с людьми

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

Считайте умение четко и ясно коммуницировать частью своих должностных обязанностей.

Как подходить к сложным задачам, не имеющим однозначного ответа

13. Задавайте вопросы

Очень важно прояснить суть проблемы, прежде чем начинать ее решать. Вот несколько вопросов, которые помогут вам в деле сбора требований:

  • Какие входящие данные ожидает ваша система?
  • Какой input считается неправильным, и что будет, если таковой поступит?
  • Какой output нужно произвести?
  • Сколько пользователей у нас ожидается?
  • Сколько запросов в секунду?
  • Нужно ли нам заботиться об интернационализации?
  • Какой уровень согласованности запросов к базе данных нам подойдет? Нужна строгая согласованность или будет достаточно итоговой?

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

14. Проектируйте сперва на бумаге

Сделайте набросок решения, прежде чем начать кодить. Используйте для этого карандаш и бумагу или белую доску. За исключением случаев, когда перед вами совершенно тривиальная задача, старайтесь подобрать альтернативные варианты решений. После этого попытайтесь сломать свой проект. Спросите себя:

  • Где эта система может сломаться?
  • Где ее узкие места?
  • Зависим ли мы от третьей стороны? Что будет, если у этой третьей стороны что-то пойдет не по плану?
  • Можем ли мы использовать кэш для улучшения производительности?
  • Как мы можем вести логи и мониторить работу системы?

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

Дополнительный совет

Мне кажется, я вычитал это где-то на внутренней wiki-странице, но это помогло мне увидеть недостатки в моих действиях.

15. Развивайтесь всесторонне

Если вы умеете делать только что-то одно, скорее всего у вас существенные пробелы в остальных областях знаний. Изучайте другие языки программирования. Создавайте какие-нибудь прототипы машинного обучения, даже если вы Android-разработчик. Если вы фронтенд-разработчик, изучайте бэкенд или погрузитесь в глубины Linux.

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

Вы можете изучить пару технологий из областей, смежных с вашей специализацией, и применить их в своей работе. А можете изучить нечто, с чем раньше вообще не сталкивались, и полностью сменить карьеру!

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх