Ниже приведен список хороших характеристик/отношений к работе, которыми должен обладать старший разработчик. Эти «заслуги» исходят из моего реального ежедневного опыта, когда я был индивидуальным автором в течение последних 5 лет. Я могу получить их из книги или разговора с другими, или здесь или там. Я действительно впитал их и смог следовать этим «достоинствам» в своей повседневной офисной жизни. Несмотря на то, что я утверждаю, что они для старших разработчиков, некоторые из этих пунктов все еще работают для меня, поскольку я меняю свою роль на менеджера и директора.

Эти «заслуги» для коллег-разработчиков

Будьте связующим звеном в своей команде. Не будьте единственной звездой в своей команде.

Попробуйте помочь другим стать звездами, тогда вы будете наставником звезд :)

Будь слугой своей команды, а не начальником своей команды.

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

Найдите хорошие инициативы и реализуйте их

Это просто означает самоуправление.

Общение всегда важно

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

Будьте сторонником своей работы

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

Будьте авторитетом для своих коллег и вашего босса

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

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

Вы владеете продуктом, который создаете

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

Быть наполовину продакт-менеджером в своей команде

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