489 чтения
489 чтения

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

к Maksim Zhelezniakov10m2025/03/12
Read on Terminal Reader
Read this story w/o Javascript

Слишком долго; Читать

Повысьте свою производительность как инженера-программиста с помощью семи практических советов, включая эффективное управление задачами, четкую коммуникацию и проактивное сотрудничество.
featured image - Вот 7 советов по повышению производительности, которые используют профессиональные инженеры-программисты, чтобы оставаться впереди
Maksim Zhelezniakov HackerNoon profile picture

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


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

1. Сохраняйте внутренний задел

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


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


  1. Возьмите задачи спринта из вашей любимой Jira, посмотрите на них и расставьте приоритеты. Какая задача должна быть вашей основной? Подсказка: обычно это что-то, связанное с бизнесом, может быть, новая функция, которую ваша команда ожидает выполнить к концу спринта. Какие задачи можно безопасно отложить на потом и выполнить, если у вас останется время? Всегда полезно прояснить ситуацию и поделиться своим пониманием с менеджером или специалистом по продукту. Это можно сделать во время планирования спринта, если они у вас есть.
  2. Разбейте свои задачи по дням, выделите больше времени и усилий на основные из них и оставьте меньше места для тех, которые вы считаете не столь важными.
  3. Добавьте в свой список встречи команды и другие мероприятия. Например, я считаю хорошей практикой иметь выделенный временной интервал для обзоров кода каждый день. Таким образом, вам не нужно торопиться с комментариями, и есть больше шансов внести лучший вклад. Я опубликовал отдельную статью о том, как извлечь максимальную пользу из ваших обзоров PR здесь .
  4. Добавьте в свой список некоторые другие задачи, которые не включены в ваш спринт. Например, «спросить Тома об изменении, которое мы сделали на прошлой неделе, чтобы узнать, нужно ли мне что-то сделать в следующий раз».
  5. Корпоративные обязанности также должны быть в списке. Например: «обновить мои цели», «ответить на запрос опроса компании» и т. д.
  6. Наконец, отслеживайте все эти вещи в начале дня.


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


2. Будьте активны на собраниях команды.

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


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

3. Общайтесь ясно

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


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


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


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


Обратите внимание, как вторая версия исключает технические термины и фокусируется на результатах, которые совершенно понятны всем? Чтобы попрактиковаться в этом более простом типе общения, попробуйте задать себе следующие вопросы:


  • Что они на самом деле хотят знать?
  • Что я на самом деле пытаюсь сказать?


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


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

4. Постройте мост со своим руководителем

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


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

5. Сосредоточенная работа вместо постоянной многозадачности

Давайте поговорим о самой рутине кодирования. Допустим, у вас есть задача, которую нужно выполнить из нашего первого совета. Как вы к ней подходите? Вокруг вас повсюду есть «шумовые» факторы: встречи, постоянные сообщения в Slack и т. д. Я считаю, что эффективнее оградить себя от внешних неважных вещей и позволить себе быть в контексте своей задачи, желательно без ненужных отвлекающих факторов. Избавьтесь от этих необязательных встреч, если это возможно, и не спешите сразу отвечать на каждое сообщение в Slack. Конечно, это не значит, что вы должны игнорировать DM все время, но лучше избегать сбоев вашего «мыслительного цикла». Что я имею в виду?


Вот пример того, как это можно сделать:

  • У вас есть важный баг, который нужно решить. Есть пара теорий, которые вы хотите попробовать.

  • Вы работаете над первым. Вы применили исправление и готовы проверить, работает ли оно.

  • Затем вы получаете сообщение в Slack. Просматривая уведомление (буквально секунду вашего времени), вы понимаете, что оно может подождать.

  • Вы заканчиваете проверять теорию. Она не срабатывает, поэтому вы пробуете вторую.

  • Затем вы делаете перерыв и отвечаете на это сообщение.

  • Вернувшись к ошибке, вы готовы работать над следующей теорией.


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


Такой подход не означает, что можно игнорировать коллег. Нет, но во многих случаях никто не ожидает, что вы ответите немедленно. Определенно есть некий льготный период вежливости, поэтому постарайтесь не переусердствовать. Иногда, если они просят меня что-то проверить, и это занимает время, а моя задача в данный момент важнее, я бы дал им знать, что проверю это и вернусь примерно через час:


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


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

6. Покажите свою работу

Я знал очень талантливых инженеров с разнообразным техническим опытом, которые оказали мне огромную помощь. Было приятно учиться у этих знающих людей. Но добились ли они успеха в своей карьере, продвигаясь по лестнице? Может быть, получили повышение, больше обязанностей и большую зарплату? Удивительно, но не все из них. Одна из причин, по которой это произошло, заключается в том, что почти никто не знал об их работе, кроме людей в их небольших командах разработчиков.


Честно говоря, если вы работаете в приличной компании без микроменеджмента, никто не будет следить за вашими pull-реквестами под микроскопом 24/7. И это небольшое изменение, которое может сэкономить компании значительную сумму денег, может легко остаться незамеченным, если вы не сообщите о нем должным образом заинтересованным лицам. Довольно часто эти люди — менеджеры, владельцы продуктов или руководители отделов... Это означает, что они ни в малейшей степени не технические специалисты. Поэтому я советую вам не просто показывать свой золотой PR, но и представлять его таким образом, чтобы все в компании за пределами вашего «технологического пузыря» поняли его значение и, что еще важнее, ценность компании. Презентация, красивые графики, реальные цифры — все это. Что возвращает нас к третьему пункту о гибких навыках и коммуникации.


Есть и другая сторона этого момента, которую я иногда слышу в жалобах коллег-инженеров. Как тот человек в вашей компании, который хорош в саморекламе и делает все гораздо более важным, чем оно есть на самом деле. Возможно, их больше хвалили руководители только из-за их демонстрируемых навыков. И только из-за этого на них можно смотреть свысока. Но, эй, будет полезно перенять у них еще и пару маркетинговых трюков. Да, «продажа» своей работы тоже важна.


Если ваши навыки презентации недостаточны, подумайте, как вы можете их улучшить. Я бы сделал это одной из личных целей с четким набором пунктов действий. Посмотрите, может ли ваш менеджер помочь вам в этом. Подмигиваю 4-му совету там 😉

7. Цените свое время

И последнее, но не менее важное: не работайте сверхурочно. Не перерабатывайте. Точка.


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


Раньше, в ранние годы работы инженером, я работал сверхурочно. Однажды нам сказали выпустить огромную и сложную функцию в фиксированное время. Крайний срок изначально был нереалистичным. Мы все об этом знали, но по какой-то причине, которую я уже не помню, команде пришлось с этим смириться. Мы работали в течение нескольких выходных, работая по ночам. Можете ли вы угадать, что из этого вышло? Естественно, мы не смогли этого сделать. В конце концов, никто ничего с этим не сделал, но мне понадобился месяц безработных выходных после этого, чтобы прийти в себя. Как любезно сказал мне наш руководитель группы: «Эта компания отнимет у вас столько времени, сколько вы ей позволите».


После этого инцидента и многих подобных случаев до него я установил свои собственные границы того, где и когда работа, за которую мне платят, начинается и заканчивается. Помните, если вы официально работаете 5/7, у вас есть определенное количество часов, за которые вам платят. Даже если вы работаете фрилансером, это по сути одно и то же. Всегда есть отношение «деньги в час». Если вы работаете сверхурочно без дополнительной оплаты, в большинстве случаев вы оказываете себе медвежью услугу. Поверьте мне, все это может легко привести к выгоранию в какой-то момент, из которого будет трудно выйти.


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

Заключение

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

Trending Topics

blockchaincryptocurrencyhackernoon-top-storyprogrammingsoftware-developmenttechnologystartuphackernoon-booksBitcoinbooks