День 2235. #Карьера
Ежедневная Практика Лучше Учёбы по Выходным
В мире разработки ПО постоянно появляются новые фреймворки, языки и инструменты, и велик соблазн изучить новинку за выходные или на курсе, чтобы поддерживать знания актуальными. Но секрет освоения разработки ПО не в марафонских учебных сессиях. Всё гораздо проще: дело в постоянстве.
Обучение по выходным или марафоны кодирования могут показаться продуктивными в данный момент, но они часто приводят к снижению отдачи. Вот причины:
1. Когнитивная перегрузка: попытка усвоить слишком много информации за короткий промежуток времени перегружает мозг, затрудняя эффективное сохранение и применение знаний.
2. Недостаток подкрепления: без постоянной практики концепции, которые вы изучаете за выходные, быстро забываются. Периодическое повторение гораздо эффективнее для долгосрочного запоминания.
3. Риск выгорания: интенсивные сеансы обучения могут привести к усталости, снижая мотивацию продолжать обучение в последующие дни или недели.
Напротив, ежедневная практика — даже всего 30 минут — создаёт устойчивую привычку и накопление знаний.
Правило 1% улучшения
Концепция, популяризированная Джеймсом Клиром в его книге «Атомные привычки». Небольшие, постепенные улучшения накапливаются со временем. Если вы улучшаетесь всего на 1% каждый день, то к концу года вы станете в 37 раз лучше.
Применительно к разработке это означает:
- Написание небольшого фрагмента кода каждый день.
- Решение одной проблемы кодирования ежедневно.
- Обзор новой концепции или отладка небольшой проблемы.
Почему это работает
1. Развивается «мышечная память» для кодирования
Как спортсменам, программным инженерам нужна регулярная практика, чтобы отточить свои навыки. Ежедневное написание кода помогает усвоить синтаксис, шаблоны и лучшие практики, делая вас быстрее и эффективнее.
2. Улучшаются навыки решения проблем
Решение проблем лежит в основе разработки ПО. Ежедневная практика подвергает вас различным испытаниям, помогая разработать набор стратегий и методов. Со временем вы обнаружите, что легче справляетесь со сложными проблемами.
3. Поощряется непрерывное обучение
Индустрия развивается быстро, и постоянное обучение гарантирует, что вы останетесь в тренде. Ежедневно выделяя время на изучение новых технологий или совершенствование имеющихся навыков, вы создаёте привычку к постоянному совершенствованию.
4. Уменьшается прокрастинация
Когда обучение кажется огромной задачей, его хочется отложить. Но выделить всего 15–30 минут в день проще. Это помогает преодолеть прокрастинацию и выработать дисциплину.
Как применять правило 1%
1. Установите ежедневную цель кодирования
Написать небольшой фрагмент кода, решить один алгоритм или отладить одну проблему в день. Используйте такие платформы, как LeetCode, HackerRank или Codewars, чтобы находить небольшие задачи.
2. Работа над сторонними проектами
Это отличный способ применить полученные знания в реальном контексте. Уделяйте немного времени каждый день созданию или улучшению проекта.
3. Обзор и рефакторинг кода
Уделяйте несколько минут каждый день обзору собственного кода или проектов с открытым кодом. Ищите способы улучшить читаемость, эффективность или структуру.
4. Изучайте небольшими порциями
Вместо того, чтобы пытаться освоить весь фреймворк за один присест, разбейте его на более мелкие темы.
5. Отслеживайте прогресс
Используйте журнал или приложение для отслеживания своей ежедневной деятельности по кодированию. Размышления о своём прогрессе укрепляют привычку и поддерживают мотивацию.
Последовательность в разработке ПО подобна сложным процентам. Сначала улучшения могут казаться незначительными, но со временем они накапливаются и выливаются в большой результат.
Источник: https://dev.to/jps27cse/the-role-of-consistency-in-software-engineering-why-daily-practice-beats-weekend-learning-36b9
Ежедневная Практика Лучше Учёбы по Выходным
В мире разработки ПО постоянно появляются новые фреймворки, языки и инструменты, и велик соблазн изучить новинку за выходные или на курсе, чтобы поддерживать знания актуальными. Но секрет освоения разработки ПО не в марафонских учебных сессиях. Всё гораздо проще: дело в постоянстве.
Обучение по выходным или марафоны кодирования могут показаться продуктивными в данный момент, но они часто приводят к снижению отдачи. Вот причины:
1. Когнитивная перегрузка: попытка усвоить слишком много информации за короткий промежуток времени перегружает мозг, затрудняя эффективное сохранение и применение знаний.
2. Недостаток подкрепления: без постоянной практики концепции, которые вы изучаете за выходные, быстро забываются. Периодическое повторение гораздо эффективнее для долгосрочного запоминания.
3. Риск выгорания: интенсивные сеансы обучения могут привести к усталости, снижая мотивацию продолжать обучение в последующие дни или недели.
Напротив, ежедневная практика — даже всего 30 минут — создаёт устойчивую привычку и накопление знаний.
Правило 1% улучшения
Концепция, популяризированная Джеймсом Клиром в его книге «Атомные привычки». Небольшие, постепенные улучшения накапливаются со временем. Если вы улучшаетесь всего на 1% каждый день, то к концу года вы станете в 37 раз лучше.
Применительно к разработке это означает:
- Написание небольшого фрагмента кода каждый день.
- Решение одной проблемы кодирования ежедневно.
- Обзор новой концепции или отладка небольшой проблемы.
Почему это работает
1. Развивается «мышечная память» для кодирования
Как спортсменам, программным инженерам нужна регулярная практика, чтобы отточить свои навыки. Ежедневное написание кода помогает усвоить синтаксис, шаблоны и лучшие практики, делая вас быстрее и эффективнее.
2. Улучшаются навыки решения проблем
Решение проблем лежит в основе разработки ПО. Ежедневная практика подвергает вас различным испытаниям, помогая разработать набор стратегий и методов. Со временем вы обнаружите, что легче справляетесь со сложными проблемами.
3. Поощряется непрерывное обучение
Индустрия развивается быстро, и постоянное обучение гарантирует, что вы останетесь в тренде. Ежедневно выделяя время на изучение новых технологий или совершенствование имеющихся навыков, вы создаёте привычку к постоянному совершенствованию.
4. Уменьшается прокрастинация
Когда обучение кажется огромной задачей, его хочется отложить. Но выделить всего 15–30 минут в день проще. Это помогает преодолеть прокрастинацию и выработать дисциплину.
Как применять правило 1%
1. Установите ежедневную цель кодирования
Написать небольшой фрагмент кода, решить один алгоритм или отладить одну проблему в день. Используйте такие платформы, как LeetCode, HackerRank или Codewars, чтобы находить небольшие задачи.
2. Работа над сторонними проектами
Это отличный способ применить полученные знания в реальном контексте. Уделяйте немного времени каждый день созданию или улучшению проекта.
3. Обзор и рефакторинг кода
Уделяйте несколько минут каждый день обзору собственного кода или проектов с открытым кодом. Ищите способы улучшить читаемость, эффективность или структуру.
4. Изучайте небольшими порциями
Вместо того, чтобы пытаться освоить весь фреймворк за один присест, разбейте его на более мелкие темы.
5. Отслеживайте прогресс
Используйте журнал или приложение для отслеживания своей ежедневной деятельности по кодированию. Размышления о своём прогрессе укрепляют привычку и поддерживают мотивацию.
Последовательность в разработке ПО подобна сложным процентам. Сначала улучшения могут казаться незначительными, но со временем они накапливаются и выливаются в большой результат.
Источник: https://dev.to/jps27cse/the-role-of-consistency-in-software-engineering-why-daily-practice-beats-weekend-learning-36b9
👍32
День 2242. #Карьера
Собеседования и Рынок .NET в РФ
Походил я тут ради интереса в последнее время по собеседованиям. Уже выкладывал задачу на код ревью от Озона. Сегодня хочу порассуждать о собеседованиях и в принципе о состоянии найма в ИТ.
В предыдущий раз я собеседовался аж в 2021 году. Хочу отметить, что если тогда все по классике спрашивали Рихтера, async-await и ленивое выполнение в LINQ, то сейчас этого очень мало. Почти везде (а я был на 4х техсобесах в разных компаниях), жёстко гоняют по «кабанчику». Распределённые системы, очереди сообщений, репликации и точки отказа. Надо, конечно, как советуют многие, ходить для профилактики на собеседования хотя бы раз в полгода-год, а то упускаешь, что сегодня в тренде. «Кабанчика» пришлось перечитать, т.к. многое оттуда забыл.
Ещё хотелось бы отметить довольно странную работу HR отделов компаний (исключая крупные, вроде Т-банка, Озона или Контура). 60% на присланное резюме просто не реагируют никак (хотя оно отправлялось напрямую по указанному в вакансии контакту), либо ограничиваются «я передам резюме руководству и вернусь с обратной связью». Дальше, как в меме: «С обратной связью, конечно, никто возвращаться не собирался». Они просто пропадают. Неужели сложно коротко ответить, типа «Вы нам не подходите». Не понимаю.
Из остальных 40% интересно, что некоторые HR умудряются так пропадать даже после созвона. Остальные всё-таки отвечают, и удавалось продолжить диалог и получить либо отказ, либо согласие общаться дальше. В большинстве случаев проходит 3 этапа собеседований:
- знакомство с HR (30 минут – час),
- техническое собеседование (1,5-2,5 часа),
- общение с командой/техлидом об условиях работы (1,5-2 часа).
В этом плане хотел бы отметить работу отдела найма в Контуре. После того, как я отправил резюме, HR довольно быстро ответила и прислала список вопросов для первого знакомства: почему ищу работу? какие ожидания по ЗП? чего жду от нового места? какой есть опыт с тем и с этим? был ли опыт управления командой? и т.п.
Я ответил на вопросы, и буквально в течение 10 минут HR вернулась с фидбеком. Для сравнения, иногда диалоги с HR других компаний шли по 1 сообщению в 1-2 дня. Приходилось перечитывать переписку, чтоб вспомнить, кто это и из какой компании. В общем, HR Контура ответила, что ЗП определят по итогам тех. интервью. Но, т.к. у меня не было такого и такого опыта, спросила, соглашусь ли я на ЗП на 10% меньше? Но сразу же упомянула, что в компании до двух раз в год пересматривают зарплаты, и в случае удачного старта можно выйти на желаемый уровень довольно быстро. А также перечислила другие преимущества работы в компании. Т.е. не просто отказала из-за завышенных требований, не заявила, что «можем дать только столько-то», а дала мотивированное объяснение. По-моему, прекрасный ответ.
Далее был созвон с HR (другой), поболтали о компании и о моём опыте. Кстати, совет. Будьте готовы ответить на вопросы типа «Что вы считаете своими большими достижениями в карьере?» и «Какие у вас были провалы?». Понятно, что и то, и другое, случается у каждого, но, чтоб не было неожиданностью, и чтоб не ляпнуть от волнения что-нибудь ненужное, стоит подготовить ответы заранее.
Техническое интервью тоже вполне достойное. Сначала дали код на обзор. Но тут, в отличие от Озона, не было очевидных ляпов в коде. Упор сделали на алгоритмы, оценку сложности и возможные улучшения. Разбирали, кстати, самописную реализацию StringBuilder. А после тоже погоняли по моему опыту, по «кабанчику» и попросили нарисовать и объяснить архитектуру небольшого сервиса: куда поместить сервис, какой будет API, где и как хранить данные, что, когда, куда будет передаваться. После этого также вернулись с подробным фидбеком: в чём были сильные стороны, где есть «зоны роста», причём с перечнем литературы, которую надо почитать (да, «кабанчик» там тоже был).
В общем, Контур оставил прекрасное впечатление в плане работы с кандидатами. Всем бы так.
Пишите в комментарии ваши истории о поиске работы.
Автору лучшей истории пришлю книгу по Kubernetes (мне из "Питера" случайно вторую прислали, разрешили подарить).
Собеседования и Рынок .NET в РФ
Походил я тут ради интереса в последнее время по собеседованиям. Уже выкладывал задачу на код ревью от Озона. Сегодня хочу порассуждать о собеседованиях и в принципе о состоянии найма в ИТ.
В предыдущий раз я собеседовался аж в 2021 году. Хочу отметить, что если тогда все по классике спрашивали Рихтера, async-await и ленивое выполнение в LINQ, то сейчас этого очень мало. Почти везде (а я был на 4х техсобесах в разных компаниях), жёстко гоняют по «кабанчику». Распределённые системы, очереди сообщений, репликации и точки отказа. Надо, конечно, как советуют многие, ходить для профилактики на собеседования хотя бы раз в полгода-год, а то упускаешь, что сегодня в тренде. «Кабанчика» пришлось перечитать, т.к. многое оттуда забыл.
Ещё хотелось бы отметить довольно странную работу HR отделов компаний (исключая крупные, вроде Т-банка, Озона или Контура). 60% на присланное резюме просто не реагируют никак (хотя оно отправлялось напрямую по указанному в вакансии контакту), либо ограничиваются «я передам резюме руководству и вернусь с обратной связью». Дальше, как в меме: «С обратной связью, конечно, никто возвращаться не собирался». Они просто пропадают. Неужели сложно коротко ответить, типа «Вы нам не подходите». Не понимаю.
Из остальных 40% интересно, что некоторые HR умудряются так пропадать даже после созвона. Остальные всё-таки отвечают, и удавалось продолжить диалог и получить либо отказ, либо согласие общаться дальше. В большинстве случаев проходит 3 этапа собеседований:
- знакомство с HR (30 минут – час),
- техническое собеседование (1,5-2,5 часа),
- общение с командой/техлидом об условиях работы (1,5-2 часа).
В этом плане хотел бы отметить работу отдела найма в Контуре. После того, как я отправил резюме, HR довольно быстро ответила и прислала список вопросов для первого знакомства: почему ищу работу? какие ожидания по ЗП? чего жду от нового места? какой есть опыт с тем и с этим? был ли опыт управления командой? и т.п.
Я ответил на вопросы, и буквально в течение 10 минут HR вернулась с фидбеком. Для сравнения, иногда диалоги с HR других компаний шли по 1 сообщению в 1-2 дня. Приходилось перечитывать переписку, чтоб вспомнить, кто это и из какой компании. В общем, HR Контура ответила, что ЗП определят по итогам тех. интервью. Но, т.к. у меня не было такого и такого опыта, спросила, соглашусь ли я на ЗП на 10% меньше? Но сразу же упомянула, что в компании до двух раз в год пересматривают зарплаты, и в случае удачного старта можно выйти на желаемый уровень довольно быстро. А также перечислила другие преимущества работы в компании. Т.е. не просто отказала из-за завышенных требований, не заявила, что «можем дать только столько-то», а дала мотивированное объяснение. По-моему, прекрасный ответ.
Далее был созвон с HR (другой), поболтали о компании и о моём опыте. Кстати, совет. Будьте готовы ответить на вопросы типа «Что вы считаете своими большими достижениями в карьере?» и «Какие у вас были провалы?». Понятно, что и то, и другое, случается у каждого, но, чтоб не было неожиданностью, и чтоб не ляпнуть от волнения что-нибудь ненужное, стоит подготовить ответы заранее.
Техническое интервью тоже вполне достойное. Сначала дали код на обзор. Но тут, в отличие от Озона, не было очевидных ляпов в коде. Упор сделали на алгоритмы, оценку сложности и возможные улучшения. Разбирали, кстати, самописную реализацию StringBuilder. А после тоже погоняли по моему опыту, по «кабанчику» и попросили нарисовать и объяснить архитектуру небольшого сервиса: куда поместить сервис, какой будет API, где и как хранить данные, что, когда, куда будет передаваться. После этого также вернулись с подробным фидбеком: в чём были сильные стороны, где есть «зоны роста», причём с перечнем литературы, которую надо почитать (да, «кабанчик» там тоже был).
В общем, Контур оставил прекрасное впечатление в плане работы с кандидатами. Всем бы так.
Пишите в комментарии ваши истории о поиске работы.
Автору лучшей истории пришлю книгу по Kubernetes (мне из "Питера" случайно вторую прислали, разрешили подарить).
👍52👎2
День 2270. #Карьера
Почему Синдром Самозванца - Часть Пути Каждого Разработчика?
Вы когда-нибудь чувствовали, что просто притворяетесь разработчиком? Что в любой момент кто-то может разоблачить вас и уличить в том, что вы недостаточно хороши?
Хотя это может показаться странным, почти каждый разработчик чувствует то же самое. Если вы обеспокоены тем, что гуглите так же часто, как и когда только начинали программировать, или даже чаще, жаль вас огорчать, но вы нормальны настолько, насколько это возможно.
Ежедневно забываете синтаксис, делаете ошибки так часто, как будто они входят в ваши должностные инструкции… мы все так делаем.
И как можно не делать этого?
Со всей информацией, которую мы постоянно узнаём, и бесчисленными часами, потраченными на отладку, возможно ли ожидать, что мы запомним всё?
Каждый год фреймворки развиваются, появляются новые технологии, меняются требования к проекту. Это постоянная кривая обучения, и это ощущение самозванца — всего лишь часть процесса.
Когда у вас возникают такие мысли, как «Я не знаю, имеет ли смысл то, что я делаю» или «Я чувствую, что застрял на этой проблеме» выберите практичный подход. Разбейте проблему на более мелкие.
Если вы считаете, что вам нужно стать лучше, как разработчик, спросите себя: что на самом деле означает «лучше»?
Если вы новичок:
- Выберите область, на которой вы хотите сосредоточиться (веб-разработка, мобильные приложения, игры и т. д.).
- Выберите правильный язык программирования.
- Найдите дорожную карту и придерживайтесь её.
Если вы уже работаете над чем-то и чувствуете, что недостаточно хороши.
- Выясните, что именно доставляет вам проблемы: работа с БД, развёртывание, логика, архитектура?
- Поработайте над вашими конкретными недостатками.
Это гораздо меньше обескураживает — и определённо меньше угнетает. Ставит перед вами конкретные цели и конкретные пути их достижения.
Поэтому, если вы можете писать код, совершать ошибки, гуглить решение и начинать заново — вы делаете именно то, что делаем мы все. Вы не только становитесь лучше в гуглении (что, кстати, является настоящим навыком), но, что ещё важнее, вы растёте как разработчик.
Источник: https://dev.to/web_dev-usman/why-imposter-syndrome-is-part-of-every-developers-journey-2c0p
Почему Синдром Самозванца - Часть Пути Каждого Разработчика?
Вы когда-нибудь чувствовали, что просто притворяетесь разработчиком? Что в любой момент кто-то может разоблачить вас и уличить в том, что вы недостаточно хороши?
Хотя это может показаться странным, почти каждый разработчик чувствует то же самое. Если вы обеспокоены тем, что гуглите так же часто, как и когда только начинали программировать, или даже чаще, жаль вас огорчать, но вы нормальны настолько, насколько это возможно.
Ежедневно забываете синтаксис, делаете ошибки так часто, как будто они входят в ваши должностные инструкции… мы все так делаем.
И как можно не делать этого?
Со всей информацией, которую мы постоянно узнаём, и бесчисленными часами, потраченными на отладку, возможно ли ожидать, что мы запомним всё?
Каждый год фреймворки развиваются, появляются новые технологии, меняются требования к проекту. Это постоянная кривая обучения, и это ощущение самозванца — всего лишь часть процесса.
Когда у вас возникают такие мысли, как «Я не знаю, имеет ли смысл то, что я делаю» или «Я чувствую, что застрял на этой проблеме» выберите практичный подход. Разбейте проблему на более мелкие.
Если вы считаете, что вам нужно стать лучше, как разработчик, спросите себя: что на самом деле означает «лучше»?
Если вы новичок:
- Выберите область, на которой вы хотите сосредоточиться (веб-разработка, мобильные приложения, игры и т. д.).
- Выберите правильный язык программирования.
- Найдите дорожную карту и придерживайтесь её.
Если вы уже работаете над чем-то и чувствуете, что недостаточно хороши.
- Выясните, что именно доставляет вам проблемы: работа с БД, развёртывание, логика, архитектура?
- Поработайте над вашими конкретными недостатками.
Это гораздо меньше обескураживает — и определённо меньше угнетает. Ставит перед вами конкретные цели и конкретные пути их достижения.
Поэтому, если вы можете писать код, совершать ошибки, гуглить решение и начинать заново — вы делаете именно то, что делаем мы все. Вы не только становитесь лучше в гуглении (что, кстати, является настоящим навыком), но, что ещё важнее, вы растёте как разработчик.
Источник: https://dev.to/web_dev-usman/why-imposter-syndrome-is-part-of-every-developers-journey-2c0p
👍33
День 2295. #Карьера
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Начало
У всех нас были дни, когда список задач состоял из одних «срочных» запросов. Менеджеру по продукту нужна эта функция вчера. В производстве только что появились три критических ошибки. Технический долг, который вы откладывали, наконец стал причиной проблем. И от вас ожидают, что вы будете справляться со всем этим одновременно. С правильной структурой и инструментами расстановки приоритетов вы можете прорваться через хаос и сосредоточиться на том, что действительно важно.
Почему это важно?
Эффективная расстановка приоритетов — это не только работа быстрее, но и работа умнее. Для разработчиков правильная расстановка приоритетов задач:
- Уменьшает переключение контекста, которое, как показывают исследования, может снизить производительность до 40%.
- Гарантирует устранение критических ошибок и проблем безопасности до того, как они повлияют на пользователей.
- Согласует работу по разработке с целями и сроками бизнеса.
- Снижает стресс и предотвращает выгорание.
- Создаёт возможность работы «в потоке», когда получается лучший код.
Без чёткой системы расстановки приоритетов вы обнаружите, что постоянно тушите пожары, никогда не достигая существенного прогресса в важных проектах и наблюдая, как страдает ваша производительность.
Эффективные методики определения приоритетов задач разработки
Следующие проверенные методики могут помочь вам определить, что заслуживает вашего внимания в первую очередь.
1. Матрица Эйзенхауэра: срочное и важное
Матрица Эйзенхауэра делит задачи на четыре квадранта в зависимости от их срочности и важности.
- Срочно и важно: критические ошибки, уязвимости безопасности, сбои в производстве. Делайте это немедленно.
- Важно, но не срочно: рефакторинг кода, документирование, изучение новых навыков. Запланируйте время для этого.
- Срочно, но не важно: всяческие встречи, письма, обновления статуса. Делегируйте, если возможно.
- Не срочно и не важно: прочие отвлекающие факторы. Полностью исключите это.
Для разработчиков эта методика особенно ценна, поскольку помогает различать действительно чрезвычайные ситуации (например, нарушения безопасности) и задачи, которые просто кажутся срочными, но могут подождать (например, запрос на функцию, который «абсолютно необходимо сделать на этой неделе»).
2. Метод ABCDE
Разработан Брайаном Трейси и предлагает простой подход к расстановке приоритетов:
- A: Высокоприоритетные, срочные задачи со значительными последствиями, если не будут выполнены.
- B: Важные задачи, но менее срочные, чем A, со средними последствиями.
- C: Низкоприоритетные с небольшими или нулевыми последствиями.
- D: Задачи, которые можно делегировать другим.
- E: Задачи, которые можно полностью исключить.
Всегда сначала беритесь за задачи «A», так как они требуют немедленных действий и существенно влияют на ваши долгосрочные цели и сроки.
3. Метод MoSCoW
Особенно полезный для agile команд. Классифицирует задачи следующим образом:
- Обязательно (Must have): критические требования, которые должны быть выполнены для успеха проекта.
- Хорошо бы (Should have): важные функции, которые добавляют значительную ценность, но не являются абсолютно необходимыми.
- Можно бы (Could have): функции, которые улучшат продукт, но могут быть отложены.
- Необязательно (Won’t have): функции, которые не будут реализованы в текущей итерации.
Эта структура особенно хорошо работает при расстановке приоритетов в пользовательских историях и требованиях на основе их важности для общего пользовательского опыта.
Продолжение следует…
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Начало
У всех нас были дни, когда список задач состоял из одних «срочных» запросов. Менеджеру по продукту нужна эта функция вчера. В производстве только что появились три критических ошибки. Технический долг, который вы откладывали, наконец стал причиной проблем. И от вас ожидают, что вы будете справляться со всем этим одновременно. С правильной структурой и инструментами расстановки приоритетов вы можете прорваться через хаос и сосредоточиться на том, что действительно важно.
Почему это важно?
Эффективная расстановка приоритетов — это не только работа быстрее, но и работа умнее. Для разработчиков правильная расстановка приоритетов задач:
- Уменьшает переключение контекста, которое, как показывают исследования, может снизить производительность до 40%.
- Гарантирует устранение критических ошибок и проблем безопасности до того, как они повлияют на пользователей.
- Согласует работу по разработке с целями и сроками бизнеса.
- Снижает стресс и предотвращает выгорание.
- Создаёт возможность работы «в потоке», когда получается лучший код.
Без чёткой системы расстановки приоритетов вы обнаружите, что постоянно тушите пожары, никогда не достигая существенного прогресса в важных проектах и наблюдая, как страдает ваша производительность.
Эффективные методики определения приоритетов задач разработки
Следующие проверенные методики могут помочь вам определить, что заслуживает вашего внимания в первую очередь.
1. Матрица Эйзенхауэра: срочное и важное
Матрица Эйзенхауэра делит задачи на четыре квадранта в зависимости от их срочности и важности.
- Срочно и важно: критические ошибки, уязвимости безопасности, сбои в производстве. Делайте это немедленно.
- Важно, но не срочно: рефакторинг кода, документирование, изучение новых навыков. Запланируйте время для этого.
- Срочно, но не важно: всяческие встречи, письма, обновления статуса. Делегируйте, если возможно.
- Не срочно и не важно: прочие отвлекающие факторы. Полностью исключите это.
Для разработчиков эта методика особенно ценна, поскольку помогает различать действительно чрезвычайные ситуации (например, нарушения безопасности) и задачи, которые просто кажутся срочными, но могут подождать (например, запрос на функцию, который «абсолютно необходимо сделать на этой неделе»).
2. Метод ABCDE
Разработан Брайаном Трейси и предлагает простой подход к расстановке приоритетов:
- A: Высокоприоритетные, срочные задачи со значительными последствиями, если не будут выполнены.
- B: Важные задачи, но менее срочные, чем A, со средними последствиями.
- C: Низкоприоритетные с небольшими или нулевыми последствиями.
- D: Задачи, которые можно делегировать другим.
- E: Задачи, которые можно полностью исключить.
Всегда сначала беритесь за задачи «A», так как они требуют немедленных действий и существенно влияют на ваши долгосрочные цели и сроки.
3. Метод MoSCoW
Особенно полезный для agile команд. Классифицирует задачи следующим образом:
- Обязательно (Must have): критические требования, которые должны быть выполнены для успеха проекта.
- Хорошо бы (Should have): важные функции, которые добавляют значительную ценность, но не являются абсолютно необходимыми.
- Можно бы (Could have): функции, которые улучшат продукт, но могут быть отложены.
- Необязательно (Won’t have): функции, которые не будут реализованы в текущей итерации.
Эта структура особенно хорошо работает при расстановке приоритетов в пользовательских историях и требованиях на основе их важности для общего пользовательского опыта.
Продолжение следует…
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
👍14
День 2296. #Карьера
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Продолжение
Начало
Практические шаги
1. Соберите и перечислите все задачи
Прежде чем вы сможете эффективно расставить приоритеты, необходимо иметь представление обо всём, что нужно сделать. Составьте полный список задач, включая:
- Назначенные тикеты и отчёты об ошибках;
- Запросы функций;
- Обзоры кода;
- Элементы технического долга;
- Необходимость документации;
- Встречи и административная работа.
Используйте инструмент управления проектами, чтобы централизовать эту информацию, а не держать её разбросанной по электронным письмам, сообщениям в мессенджерах и листочкам на рабочем столе.
2. Оцените истинную срочность и кажущуюся срочность
Не всё, что помечено как «срочное», на самом деле срочно. Задайте эти вопросы, чтобы определить фактическую срочность задачи:
- Что произойдет, если это не будет сделано сегодня? На этой неделе?
- Кто пострадает, если эта задача будет отложена?
- Блокирует ли это других членов команды или элементы критического пути?
- Существуют ли жёсткие сроки, обусловленные внешними факторами (например, запуск продукта)?
Часто вы обнаружите, что многие «срочные» запросы могут подождать без существенных последствий.
3. Примените методику приоритетов
Выберите одну из методик, обсуждавшихся ранее, и классифицируйте каждую задачу соответствующим образом. Будьте честны и реалистичны в отношении того, к какому классу относятся задачи — не позволяйте всему скатываться в категорию «срочно и важно».
4. Сосредоточьтесь на одной задаче за раз
Многозадачность — миф, особенно для разработчиков. Переключение контекста между задачами написания кода особенно затратно с когнитивной точки зрения. Как только вы определили самую приоритетную задачу:
- Закройте ненужные вкладки и приложения;
- Блокируйте отвлекающие факторы (email, телефон, мессенджеры и т.д.);
- Установите таймер для сосредоточенной работы («помидорный график» хорошо подходит многим разработчикам);
- Работайте над этой единственной задачей до её завершения или до тех пор, пока не достигнете логической точки остановки.
5. Сообщите приоритеты и установите ожидания
Когда вы не можете сделать всё сразу (а вы не можете), становится важным чёткое общение:
- Сообщите заинтересованным сторонам о ваших текущих приоритетах и о том, почему вы расположили задачи в определённом порядке;
- Укажите реалистичные сроки для менее приоритетных задач;
- При необходимости обсудите сроки;
- Будьте прозрачны в отношении ограничений ваших физических способностей.
Большинство разумных членов команды поймут решения по расстановке приоритетов, если вы чётко объясните свои доводы.
Инструменты
Правильные инструменты могут значительно упростить процесс.
1. Платформы управления проектами
Предоставляют централизованное рабочее пространство для визуализации, организации и расстановки приоритетов задач. Некоторые платформы, такие как Teamcamp помогают отслеживать и анализировать время. Такие инструменты помогут вам:
- Определить, какие задачи постоянно занимают больше времени, чем ожидалось;
- Распознать закономерности в вашей производительности;
- Делать более точные оценки для будущей работы;
- Обосновывать решения по расстановке приоритетов с помощью данных.
2. Инструменты автоматизации
Автоматизируя повторяющиеся задачи, вы освобождаете умственное пространство и время для важной работы:
- Настройте конвейеры CI/CD для автоматизации тестирования и развёртывания;
- Создайте скрипты для распространённых шаблонов кода;
- Используйте чат-ботов для рутинных коммуникаций;
- Внедрите автоматизированные проверки кода.
Каждая задача, которую вы автоматизируете, — это на одну задачу меньше, в конкуренции за ваше внимание.
Окончание следует…
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Продолжение
Начало
Практические шаги
1. Соберите и перечислите все задачи
Прежде чем вы сможете эффективно расставить приоритеты, необходимо иметь представление обо всём, что нужно сделать. Составьте полный список задач, включая:
- Назначенные тикеты и отчёты об ошибках;
- Запросы функций;
- Обзоры кода;
- Элементы технического долга;
- Необходимость документации;
- Встречи и административная работа.
Используйте инструмент управления проектами, чтобы централизовать эту информацию, а не держать её разбросанной по электронным письмам, сообщениям в мессенджерах и листочкам на рабочем столе.
2. Оцените истинную срочность и кажущуюся срочность
Не всё, что помечено как «срочное», на самом деле срочно. Задайте эти вопросы, чтобы определить фактическую срочность задачи:
- Что произойдет, если это не будет сделано сегодня? На этой неделе?
- Кто пострадает, если эта задача будет отложена?
- Блокирует ли это других членов команды или элементы критического пути?
- Существуют ли жёсткие сроки, обусловленные внешними факторами (например, запуск продукта)?
Часто вы обнаружите, что многие «срочные» запросы могут подождать без существенных последствий.
3. Примените методику приоритетов
Выберите одну из методик, обсуждавшихся ранее, и классифицируйте каждую задачу соответствующим образом. Будьте честны и реалистичны в отношении того, к какому классу относятся задачи — не позволяйте всему скатываться в категорию «срочно и важно».
4. Сосредоточьтесь на одной задаче за раз
Многозадачность — миф, особенно для разработчиков. Переключение контекста между задачами написания кода особенно затратно с когнитивной точки зрения. Как только вы определили самую приоритетную задачу:
- Закройте ненужные вкладки и приложения;
- Блокируйте отвлекающие факторы (email, телефон, мессенджеры и т.д.);
- Установите таймер для сосредоточенной работы («помидорный график» хорошо подходит многим разработчикам);
- Работайте над этой единственной задачей до её завершения или до тех пор, пока не достигнете логической точки остановки.
5. Сообщите приоритеты и установите ожидания
Когда вы не можете сделать всё сразу (а вы не можете), становится важным чёткое общение:
- Сообщите заинтересованным сторонам о ваших текущих приоритетах и о том, почему вы расположили задачи в определённом порядке;
- Укажите реалистичные сроки для менее приоритетных задач;
- При необходимости обсудите сроки;
- Будьте прозрачны в отношении ограничений ваших физических способностей.
Большинство разумных членов команды поймут решения по расстановке приоритетов, если вы чётко объясните свои доводы.
Инструменты
Правильные инструменты могут значительно упростить процесс.
1. Платформы управления проектами
Предоставляют централизованное рабочее пространство для визуализации, организации и расстановки приоритетов задач. Некоторые платформы, такие как Teamcamp помогают отслеживать и анализировать время. Такие инструменты помогут вам:
- Определить, какие задачи постоянно занимают больше времени, чем ожидалось;
- Распознать закономерности в вашей производительности;
- Делать более точные оценки для будущей работы;
- Обосновывать решения по расстановке приоритетов с помощью данных.
2. Инструменты автоматизации
Автоматизируя повторяющиеся задачи, вы освобождаете умственное пространство и время для важной работы:
- Настройте конвейеры CI/CD для автоматизации тестирования и развёртывания;
- Создайте скрипты для распространённых шаблонов кода;
- Используйте чат-ботов для рутинных коммуникаций;
- Внедрите автоматизированные проверки кода.
Каждая задача, которую вы автоматизируете, — это на одну задачу меньше, в конкуренции за ваше внимание.
Окончание следует…
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
👍5
День 2297. #Карьера
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Окончание
Начало
Продолжение
Стратегии приоритизации для разработчиков
1. Метод Айви Ли
- В конце каждого рабочего дня записывайте 6 самых важных задач на завтра.
- Расположите эти задачи в порядке важности.
- Когда вы начнёте работу на следующий день, сосредоточьтесь исключительно на первой задаче, пока она не будет завершена.
- Переходите к следующей задаче только после завершения предыдущей.
- Перемещайте все незавершённые задачи в список на завтра.
- Повторяйте ежедневно.
2. Блокировка времени для работы «в потоке»
Разработчикам нужно непрерывное время для сложных задач. Попробуйте этот подход:
- Определите 2–3 самые приоритетные задачи на день.
- Выделите 90–120-минутные отрезки в графике для сосредоточенной работы над этими задачами.
- Установите статус «Не беспокоить» на эти периоды.
- Сгруппируйте встречи и административную работу в другие временные блоки.
- Оставляйте буферное время между блоками для непредвиденных проблем.
3. Правило 1–3–5
Помогает поддерживать реалистичные ожидания относительно того, что вы можете сделать за день. Планируйте выполнение:
- 1 большой задачи;
- 3 средних задач;
- 5 небольших задач.
Этот подход признаёт, что не все задачи требуют одинакового количества времени или умственной энергии, что помогает вам создать более сбалансированный и достижимый ежедневный план.
4. Когда сказать «нет» (и как это сделать)
Иногда лучшая стратегия расстановки приоритетов — научиться говорить «нет» новым задачам, когда вы по уши в работе. Это может быть особенно сложно для разработчиков, но это важно для поддержания фокуса и качества.
Когда поступает новый «срочный» запрос:
- Оцените, как он соотносится с текущими приоритетами.
- Если он действительно более важен, объясните, какая текущая задача будет отложена в результате.
- Если он менее важен, объясните свои текущие приоритеты и когда вы могли бы разумно взяться за новую задачу.
- Предложите альтернативы (Может ли кто-то другой справиться с этим? Можно ли это упростить? Можно ли отодвинуть срок?)
Помните: говорить «да» каждый раз тоже невыгодно, поэтому говорить «нет» новой работе означает, что вы заботитесь о том, чтобы качественно выполнять ту работу, которая действительно важна.
Итого
Эффективная расстановка приоритетов — это не разовое упражнение, а постоянная практика. Чтобы построить устойчивую систему:
- Ежедневно пересматривайте приоритеты: тратьте 10 минут каждое утро на оценку того, что заслуживает внимания сегодня.
- Проводите еженедельное планирование: тратьте 30 минут в начале каждой недели на то, чтобы согласовать свои задачи с более широкими целями.
- Обдумывайте и корректируйте: в конце каждой недели оценивайте, что сработало, а что нет в вашем подходе к расстановке приоритетов.
Помните: вы не можете сделать всё сразу, но при правильном подходе к расстановке приоритетов вы можете быть уверены, что всегда работаете над тем, что действительно важно.
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Окончание
Начало
Продолжение
Стратегии приоритизации для разработчиков
1. Метод Айви Ли
- В конце каждого рабочего дня записывайте 6 самых важных задач на завтра.
- Расположите эти задачи в порядке важности.
- Когда вы начнёте работу на следующий день, сосредоточьтесь исключительно на первой задаче, пока она не будет завершена.
- Переходите к следующей задаче только после завершения предыдущей.
- Перемещайте все незавершённые задачи в список на завтра.
- Повторяйте ежедневно.
2. Блокировка времени для работы «в потоке»
Разработчикам нужно непрерывное время для сложных задач. Попробуйте этот подход:
- Определите 2–3 самые приоритетные задачи на день.
- Выделите 90–120-минутные отрезки в графике для сосредоточенной работы над этими задачами.
- Установите статус «Не беспокоить» на эти периоды.
- Сгруппируйте встречи и административную работу в другие временные блоки.
- Оставляйте буферное время между блоками для непредвиденных проблем.
3. Правило 1–3–5
Помогает поддерживать реалистичные ожидания относительно того, что вы можете сделать за день. Планируйте выполнение:
- 1 большой задачи;
- 3 средних задач;
- 5 небольших задач.
Этот подход признаёт, что не все задачи требуют одинакового количества времени или умственной энергии, что помогает вам создать более сбалансированный и достижимый ежедневный план.
4. Когда сказать «нет» (и как это сделать)
Иногда лучшая стратегия расстановки приоритетов — научиться говорить «нет» новым задачам, когда вы по уши в работе. Это может быть особенно сложно для разработчиков, но это важно для поддержания фокуса и качества.
Когда поступает новый «срочный» запрос:
- Оцените, как он соотносится с текущими приоритетами.
- Если он действительно более важен, объясните, какая текущая задача будет отложена в результате.
- Если он менее важен, объясните свои текущие приоритеты и когда вы могли бы разумно взяться за новую задачу.
- Предложите альтернативы (Может ли кто-то другой справиться с этим? Можно ли это упростить? Можно ли отодвинуть срок?)
Помните: говорить «да» каждый раз тоже невыгодно, поэтому говорить «нет» новой работе означает, что вы заботитесь о том, чтобы качественно выполнять ту работу, которая действительно важна.
Итого
Эффективная расстановка приоритетов — это не разовое упражнение, а постоянная практика. Чтобы построить устойчивую систему:
- Ежедневно пересматривайте приоритеты: тратьте 10 минут каждое утро на оценку того, что заслуживает внимания сегодня.
- Проводите еженедельное планирование: тратьте 30 минут в начале каждой недели на то, чтобы согласовать свои задачи с более широкими целями.
- Обдумывайте и корректируйте: в конце каждой недели оценивайте, что сработало, а что нет в вашем подходе к расстановке приоритетов.
Помните: вы не можете сделать всё сразу, но при правильном подходе к расстановке приоритетов вы можете быть уверены, что всегда работаете над тем, что действительно важно.
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
👍2👎2
День 2312. #Карьера
Советы по Эффективной Письменной Рабочей Коммуникации. Начало
Важность эффективной, чёткой коммуникации сейчас так же важна, как и когда-либо.
Разве ИИ не может сделать это за меня?
ИИ может создавать контент для вас — и вы даже можете включить некоторые из советов ниже в промпт. Но контент, который вы создаёте, исходит от ВАС, поэтому он по-прежнему отражает вашу способность создавать чёткое сообщение.
Типы коммуникаций
Список ниже, безусловно, не является исчерпывающим, но охватывает многие из форматов общений, которые создают разработчики:
- Email
- Сообщения в блогах
- Сообщения в соц. сетях
- Teams/Slack
- Официальные деловые заметки
- Резюме для руководства
- Презентации Power Point
- Страницы Wiki / Документация
- Файлы Readme
Вот несколько советов и предложений, которые позволят вашему сообщению дойти до адресата максимально эффективно и результативно.
1. Знайте свою аудиторию
Определите цель общения и подумайте, что у вас общего и различного с аудиторией. Вот несколько вопросов, которые могут помочь:
- Выполняют ли они ту же работу, что и я?
- Это в той же области бизнеса?
- У них тот же уровень опыта?
- Должен ли контент быть актуальным через год? Больше?
Ваше общение должно быть направлено не на то, чтобы показать, как много вы знаете, а на то, что вы хотите, чтобы ваша аудитория получила от него, или на действия, которые вы хотите, чтобы они предприняли. Зачастую они не знают вашу работу или ваш бизнес.
2. Используйте списки и форматирование
Чтение длинного повествования или абзаца — сложная задача. Краткое изложение ключевых моментов помогает читателям быстрее усваивать контент.
- Сделайте это лёгким
- Пусть маркеры будут простыми
- Используйте форматирование, чтобы привлечь внимание к ключевым моментам
3. Меньше значит больше
После того, как вы создали контент, перечитайте его и удалите ненужные слова и абзацы.
Вот пример потенциальных гиперссылок:
- Нажмите здесь, чтобы сделать что-то интересное
- Нажмите здесь, чтобы сделать что-то ещё
Его можно легко упростить:
- Сделайте что-то интересное
- Сделайте что-то ещё
Обратите внимание, что ссылка сама «говорит», что нужно сделать. В зависимости от реальной ситуации слова могут быть потенциально упрощены ещё больше.
4. Избегайте внутренних шуток
Чем шире ваша аудитория, тем меньше вероятность того, что все поймут юмор, который вы включаете в сообщение. Прежде чем включать сленг, юмор, шутки или подобный контент, подумайте, будет ли этот контент одинаково понятен всем, кто может его прочитать. Наличие контента, который некоторые не понимают, часто будет означать, что остальная часть вашего сообщения также будет менее понятна.
Сохранение игривого тона 😄 возможно, просто будьте осторожны с «внутрячками», которые поймут лишь немногие.
5. Минимизируйте предположения
Предположения часто могут иметь форму TLA (трехбуквенных аббревиатур), и, если вас немного сбила с толку «TLA» — это и является примером такого рода предположений, которые могут отвлечь читателей от сути сообщения.
Чёткое понимание аудитории и того, что они могут знать, а что нет, может помочь. Использование аббревиатур может быть приемлемым в случаях, когда вы уверены, что все их знают.
Окончание следует…
Источник: https://knowyourtoolset.com/2025/05/tips-for-communication/
Советы по Эффективной Письменной Рабочей Коммуникации. Начало
Важность эффективной, чёткой коммуникации сейчас так же важна, как и когда-либо.
Разве ИИ не может сделать это за меня?
ИИ может создавать контент для вас — и вы даже можете включить некоторые из советов ниже в промпт. Но контент, который вы создаёте, исходит от ВАС, поэтому он по-прежнему отражает вашу способность создавать чёткое сообщение.
Типы коммуникаций
Список ниже, безусловно, не является исчерпывающим, но охватывает многие из форматов общений, которые создают разработчики:
- Сообщения в блогах
- Сообщения в соц. сетях
- Teams/Slack
- Официальные деловые заметки
- Резюме для руководства
- Презентации Power Point
- Страницы Wiki / Документация
- Файлы Readme
Вот несколько советов и предложений, которые позволят вашему сообщению дойти до адресата максимально эффективно и результативно.
1. Знайте свою аудиторию
Определите цель общения и подумайте, что у вас общего и различного с аудиторией. Вот несколько вопросов, которые могут помочь:
- Выполняют ли они ту же работу, что и я?
- Это в той же области бизнеса?
- У них тот же уровень опыта?
- Должен ли контент быть актуальным через год? Больше?
Ваше общение должно быть направлено не на то, чтобы показать, как много вы знаете, а на то, что вы хотите, чтобы ваша аудитория получила от него, или на действия, которые вы хотите, чтобы они предприняли. Зачастую они не знают вашу работу или ваш бизнес.
2. Используйте списки и форматирование
Чтение длинного повествования или абзаца — сложная задача. Краткое изложение ключевых моментов помогает читателям быстрее усваивать контент.
- Сделайте это лёгким
- Пусть маркеры будут простыми
- Используйте форматирование, чтобы привлечь внимание к ключевым моментам
3. Меньше значит больше
После того, как вы создали контент, перечитайте его и удалите ненужные слова и абзацы.
Вот пример потенциальных гиперссылок:
- Нажмите здесь, чтобы сделать что-то интересное
- Нажмите здесь, чтобы сделать что-то ещё
Его можно легко упростить:
- Сделайте что-то интересное
- Сделайте что-то ещё
Обратите внимание, что ссылка сама «говорит», что нужно сделать. В зависимости от реальной ситуации слова могут быть потенциально упрощены ещё больше.
4. Избегайте внутренних шуток
Чем шире ваша аудитория, тем меньше вероятность того, что все поймут юмор, который вы включаете в сообщение. Прежде чем включать сленг, юмор, шутки или подобный контент, подумайте, будет ли этот контент одинаково понятен всем, кто может его прочитать. Наличие контента, который некоторые не понимают, часто будет означать, что остальная часть вашего сообщения также будет менее понятна.
Сохранение игривого тона 😄 возможно, просто будьте осторожны с «внутрячками», которые поймут лишь немногие.
5. Минимизируйте предположения
Предположения часто могут иметь форму TLA (трехбуквенных аббревиатур), и, если вас немного сбила с толку «TLA» — это и является примером такого рода предположений, которые могут отвлечь читателей от сути сообщения.
Чёткое понимание аудитории и того, что они могут знать, а что нет, может помочь. Использование аббревиатур может быть приемлемым в случаях, когда вы уверены, что все их знают.
Окончание следует…
Источник: https://knowyourtoolset.com/2025/05/tips-for-communication/
👍5
День 2313. #Карьера
Советы по Эффективной Письменной Рабочей Коммуникации. Окончание
Начало
6. Эффективно используйте визуальные элементы
Изображение стоит тысячи слов. Потоки, отношения или архитектуры можно кратко представить с помощью диаграммы. Код — ещё один пример хорошего визуального элемента, но имейте в виду, что если вы используете какой-то «реальный» код, удалите лишние строки, не существенные для примера (даже несущественные комментарии, как в примере ниже):
7. Резюмируйте заранее
Обычное сокращение в мире технологий — tl;dr — что означает «слишком долго;не читал» (для олдов: «ниасилил ибо войнаимир»). В верхней части сообщения добавьте краткое резюме того, о чём оно будет.
Краткое резюме может помочь читателю понять, СТОИТ ли ему продолжать читать, поскольку оно обобщает всё содержимое в короткой аннотации. Если аннотация интересна, он может продолжить чтение и углубиться в детали.
Резюмирование особенно важно, если вы просите о действии или даёте рекомендацию. В таких случаях сразу переходите к сути (и используйте форматирование), как в следующих примерах, которые могут быть в начале сообщения:
- Пожалуйста, создайте функцию до следующего вторника
- Рекомендую использовать фреймворк A
Далее вы можете подробно изложить как требования, так и рекомендации, но изложение своей точки зрения сразу устраняет путаницу.
8. Избегайте метафор
Метафоры могут отвлекать от реального сообщения, которое вы пытаетесь донести. Часто они сами по себе не очень понятны, и то, что вы пытаетесь представить, теперь зависит от метафоры.
9. Избегайте «Привет»-ственных сообщений
Не начинайте новое общение с одного сообщения, типа: «Привет, Имярек».
Это раздражающее сообщение встречается слишком часто и не помогает общению. Никакого ответа не требуется, а собеседник понятия не имеет, что вы хотите, и вынужден ждать продолжения. Это особенно раздражает, если он сосредоточен на чём-то, а теперь нужно подумать о том, кто отправитель и чего он может хотеть.
Гораздо лучше написать: «Привет, Имярек, нужна твоя помощь с багом, который мы получили…»
На этом этапе собеседник даже может оценить приоритет на основе дополнительного контекста сообщения и решить, заняться ли им немедленно или ответить позже, когда не будет занят.
10. Создавайте важные сообщения в два этапа
При написании важного сообщения создайте черновик, а затем выполните одно из двух действий или оба:
- Вернитесь к нему позже (лучше всего на следующий день, после сна).
- Попросите людей, которым вы доверяете, дать отзыв
Часто свежий взгляд и вторая пара глаз могут помочь улучшить сообщение или избежать проблемной фразы.
Источник: https://knowyourtoolset.com/2025/05/tips-for-communication/
Советы по Эффективной Письменной Рабочей Коммуникации. Окончание
Начало
6. Эффективно используйте визуальные элементы
Изображение стоит тысячи слов. Потоки, отношения или архитектуры можно кратко представить с помощью диаграммы. Код — ещё один пример хорошего визуального элемента, но имейте в виду, что если вы используете какой-то «реальный» код, удалите лишние строки, не существенные для примера (даже несущественные комментарии, как в примере ниже):
public void SomeMethod()
{
// логика метода тут
}
7. Резюмируйте заранее
Обычное сокращение в мире технологий — tl;dr — что означает «слишком долго;не читал» (для олдов: «ниасилил ибо войнаимир»). В верхней части сообщения добавьте краткое резюме того, о чём оно будет.
Краткое резюме может помочь читателю понять, СТОИТ ли ему продолжать читать, поскольку оно обобщает всё содержимое в короткой аннотации. Если аннотация интересна, он может продолжить чтение и углубиться в детали.
Резюмирование особенно важно, если вы просите о действии или даёте рекомендацию. В таких случаях сразу переходите к сути (и используйте форматирование), как в следующих примерах, которые могут быть в начале сообщения:
- Пожалуйста, создайте функцию до следующего вторника
- Рекомендую использовать фреймворк A
Далее вы можете подробно изложить как требования, так и рекомендации, но изложение своей точки зрения сразу устраняет путаницу.
8. Избегайте метафор
Метафоры могут отвлекать от реального сообщения, которое вы пытаетесь донести. Часто они сами по себе не очень понятны, и то, что вы пытаетесь представить, теперь зависит от метафоры.
9. Избегайте «Привет»-ственных сообщений
Не начинайте новое общение с одного сообщения, типа: «Привет, Имярек».
Это раздражающее сообщение встречается слишком часто и не помогает общению. Никакого ответа не требуется, а собеседник понятия не имеет, что вы хотите, и вынужден ждать продолжения. Это особенно раздражает, если он сосредоточен на чём-то, а теперь нужно подумать о том, кто отправитель и чего он может хотеть.
Гораздо лучше написать: «Привет, Имярек, нужна твоя помощь с багом, который мы получили…»
На этом этапе собеседник даже может оценить приоритет на основе дополнительного контекста сообщения и решить, заняться ли им немедленно или ответить позже, когда не будет занят.
10. Создавайте важные сообщения в два этапа
При написании важного сообщения создайте черновик, а затем выполните одно из двух действий или оба:
- Вернитесь к нему позже (лучше всего на следующий день, после сна).
- Попросите людей, которым вы доверяете, дать отзыв
Часто свежий взгляд и вторая пара глаз могут помочь улучшить сообщение или избежать проблемной фразы.
Источник: https://knowyourtoolset.com/2025/05/tips-for-communication/
👍2
День 2404. #Карьера
8 Правил Прохождения Техсобеса. Начало
Советы от шведского разработчика/архитектора ПО Виктора 'viblo' Бломквиста. Советы, основаны на его опыте работы и собеседований на «обычные» должности разработчиков в Европе, особенно в Швеции, в небольших и средних технологических компаниях, где интервьюеры не стремятся вас унизить или подшутить над вами. Думаю, они подойдут и для многих наших компаний.
1. Практика — залог успеха
Главный совет - сначала попрактиковаться! Не в смысле сотни часов на LeetCode или заучивания документации по Kubernetes. В смысле «тренировочных собеседований», чтобы освоиться в обстановке собеседования. Многие (большинство?) разработчики просто не очень комфортно чувствуют себя на собеседованиях, и практика действительно помогает. Совершенно нормально нервничать, запинаться и т.п. Но нужно уметь рассказать интервьюеру, что вы знаете! Я как-то не смог рассказать, какими способами можно передавать данные между разными процессами. Да, просто нервничал и был неудачный день. Но при этом, несмотря на солидный опыт и резюме, такого кандидата сложно рекомендовать к найму, независимо от других качеств.
В начале карьеры собеседования – это стресс. А мы не любим делать то, что вызывает стресс, поэтому боимся практиковаться. Не повторяйте эту ошибку! Практика — залог успеха!
2. Резюме. Много коротких работ
У некоторых кандидатов много коротких работ (например, 3-5 работ продолжительностью год или меньше). Это не критично, и скорее всего, вас пригласят на собеседование в любом случае. Но вам нужно иметь веские аргументы, почему на этой работе будет по-другому. Если, конечно, компания специально не ищет человека на короткий срок. Продумайте свои доводы заранее. И, вероятно, лучше упомянуть об этом до того, как вас об этом спросят.
3. Резюме. Изменения ролей
Если ваша текущая должность отличается от той, на которую вы претендуете, необходимо это осветить и объяснить. Это также важно и тогда, когда вы претендуете на более «низкую» должность. Один из типичных случаев — кандидаты, которые сейчас возглавляют небольшую команду, но подают заявку на должность разработчика. Такие кандидаты и их опыт могут быть очень ценными, особенно при найме на должность старшего разработчика в небольшой компании, где от разработчиков ожидается больше ответственности, чем просто выполнение заранее спланированной задачи. В то же время есть несколько вещей, в которых вам следует убедить интервьюеров:
- что у вас всё ещё есть технические навыки. Руководители команд нередко теряют связь с технологиями, или, возможно, изначально не были так увлечены ими;
- объяснить, почему вы хотите вернуться к программированию на постоянной основе. То, что вы не можете найти работу тимлидом – не очень хорошее объяснение.
4. Не говорите слишком много
Особенно если вы в чём-то не уверены, длительное рассуждение не поможет. Звучит очевидно, правда? Но, видимо, на практике про это забывают! Бывают кандидаты, которые могут дать достойный ответ на простой вопрос, но затем заваливают свой собственный ответ, пускаясь в рассуждения.
Связанная с этим проблема: вы, как ни парадоксально, можете не дать интервьюеру достаточно узнать о вас. Часто лучший результат технического вопроса — это обсуждение с интервьюером(-ами) на равных. Это возможно только в том случае, если вы позволите интервьюеру говорить и не будете уходить в десятиминутный монолог на заданную тему. Это особенно важно, если у вас нет глубокого опыта в этой теме или вы не умеете хорошо выступать.
Окончание следует…
Источник: https://www.viblo.se/posts/interviewing/
8 Правил Прохождения Техсобеса. Начало
Советы от шведского разработчика/архитектора ПО Виктора 'viblo' Бломквиста. Советы, основаны на его опыте работы и собеседований на «обычные» должности разработчиков в Европе, особенно в Швеции, в небольших и средних технологических компаниях, где интервьюеры не стремятся вас унизить или подшутить над вами. Думаю, они подойдут и для многих наших компаний.
1. Практика — залог успеха
Главный совет - сначала попрактиковаться! Не в смысле сотни часов на LeetCode или заучивания документации по Kubernetes. В смысле «тренировочных собеседований», чтобы освоиться в обстановке собеседования. Многие (большинство?) разработчики просто не очень комфортно чувствуют себя на собеседованиях, и практика действительно помогает. Совершенно нормально нервничать, запинаться и т.п. Но нужно уметь рассказать интервьюеру, что вы знаете! Я как-то не смог рассказать, какими способами можно передавать данные между разными процессами. Да, просто нервничал и был неудачный день. Но при этом, несмотря на солидный опыт и резюме, такого кандидата сложно рекомендовать к найму, независимо от других качеств.
В начале карьеры собеседования – это стресс. А мы не любим делать то, что вызывает стресс, поэтому боимся практиковаться. Не повторяйте эту ошибку! Практика — залог успеха!
2. Резюме. Много коротких работ
У некоторых кандидатов много коротких работ (например, 3-5 работ продолжительностью год или меньше). Это не критично, и скорее всего, вас пригласят на собеседование в любом случае. Но вам нужно иметь веские аргументы, почему на этой работе будет по-другому. Если, конечно, компания специально не ищет человека на короткий срок. Продумайте свои доводы заранее. И, вероятно, лучше упомянуть об этом до того, как вас об этом спросят.
3. Резюме. Изменения ролей
Если ваша текущая должность отличается от той, на которую вы претендуете, необходимо это осветить и объяснить. Это также важно и тогда, когда вы претендуете на более «низкую» должность. Один из типичных случаев — кандидаты, которые сейчас возглавляют небольшую команду, но подают заявку на должность разработчика. Такие кандидаты и их опыт могут быть очень ценными, особенно при найме на должность старшего разработчика в небольшой компании, где от разработчиков ожидается больше ответственности, чем просто выполнение заранее спланированной задачи. В то же время есть несколько вещей, в которых вам следует убедить интервьюеров:
- что у вас всё ещё есть технические навыки. Руководители команд нередко теряют связь с технологиями, или, возможно, изначально не были так увлечены ими;
- объяснить, почему вы хотите вернуться к программированию на постоянной основе. То, что вы не можете найти работу тимлидом – не очень хорошее объяснение.
4. Не говорите слишком много
Особенно если вы в чём-то не уверены, длительное рассуждение не поможет. Звучит очевидно, правда? Но, видимо, на практике про это забывают! Бывают кандидаты, которые могут дать достойный ответ на простой вопрос, но затем заваливают свой собственный ответ, пускаясь в рассуждения.
Связанная с этим проблема: вы, как ни парадоксально, можете не дать интервьюеру достаточно узнать о вас. Часто лучший результат технического вопроса — это обсуждение с интервьюером(-ами) на равных. Это возможно только в том случае, если вы позволите интервьюеру говорить и не будете уходить в десятиминутный монолог на заданную тему. Это особенно важно, если у вас нет глубокого опыта в этой теме или вы не умеете хорошо выступать.
Окончание следует…
Источник: https://www.viblo.se/posts/interviewing/
👍17👎2
День 2405. #Карьера
8 Правил Прохождения Техсобеса. Окончание
Начало
5. Устаревший и неактуальный опыт
Как кандидату с опытом, вам нужно быть очень осторожным, говоря об устаревших/неактуальных технологиях или опыте, который не соответствует тому, что ищет интервьюер. Проблема не в том, что у вас есть такой опыт, а в том, что интервьюер опасается, что вы не знаете или не любите то, что требуется, и что вы не сможете адаптироваться к технологиям и процессам новой компании.
Например, ваши навыки написания скриптов для Linux могут быть всё ещё актуальны для компании, работающей с собственным Kubernetes, но нужно это объяснить! Не зацикливайтесь на том, как вы написали скрипт для установки 100 физических машин, потому что в данном контексте это бесполезно. Вместо этого вы можете рассказать о том, как глубокие знания Linux помогают вам писать оптимизированные и безопасные Docker-файлы или устранять сетевые неполадки при запуске в под.
6. Признавайте свои ограничения (но не слишком!)
Большинство кандидатов хорошо осознают свои возможности и знают свои границы. Это, в общем и целом, хорошо. В большинстве случаев, когда человек говорит о теме, в которой он не очень хорошо разбирается, это и так очевидно, так что можно прямо признать это. В то же время, не будьте слишком скромными и не нужно выставлять напоказ все свои слабости!
7. Примеры
Какой бы ни была тема, всегда полезно иметь возможность обратиться к реальному опыту. Будет здорово собрать несколько хороших примеров перед собеседованием — стоит подготовиться!
Например, вас спрашивают о вашем опыте в области событийно-управляемой архитектуры, но вы пока мало что сделали в этой области. Тем не менее, однажды вы внедрили очередь работ. Расскажите об этом и объясните, что вы сделали, как и почему. Другой вариант — вспомнить случай, когда вы рассматривали возможность использования событийно-управляемой архитектуры, но отказались от неё по разным причинам. А затем завершите разговор вопросом о том, как она работает в нанимающей вас компании. У всех технологий есть свои недостатки, но понимание этого часто отсутствует, поэтому это отличный способ продемонстрировать свою зрелость и дать им возможность рассказать о своей системе. Большинство интервьюеров любят рассказывать о том, как работает их уникальная система.
Но есть кое-что, на что стоит обратить внимание, если вы кандидат с опытом! Будьте очень осторожны, приводя примеры десятилетней давности. И будьте столь же осторожны, чтобы не использовать примеры, основанные на неправильных технологиях. Если вы претендуете на должность, связанную с микросервисами, не говорите о разработке приложений WinForms больше, чем это абсолютно необходимо, даже если вы думаете, что это в тему.
8. Вопросы
Едва ли не самый популярный совет для собеседований. Не забудьте задать несколько вопросов. В конце концов, возможно, вы будете там работать, и стоит попытаться заранее обнаружить какие-либо тревожные сигналы! Или, если не получится, хотя бы воспользуйтесь возможностью, чтобы интервьюеры рассказали о чём-то, что им интересно — почти все любят описывать свою текущую архитектуру, структуру команды или повседневную работу! Просто помните, что задаваемые вами вопросы отражают вас: что вас интересует, что вас волнует?
Собеседование окончено!
Получили работу?
Поздравляю! Вас наняли. Это значит, что они считают, что вы справитесь. Поначалу всё может быть очень запутанным и пугающим, особенно если вы не знакомы с этой ролью или типом компании. Со временем всё наладится, приложите все усилия и держитесь, и через пару месяцев вы почувствуете себя как дома.
Не получили работу?
Какой бы ни была причина, не расстраивайтесь! Иногда это выгодно обеим сторонам: возможно, вы не подошли, а может быть, компания оказалась не той, о которой вы мечтали. А может быть, это просто невезение. Однажды я не смог написать простой SQL-запрос, хотя имею огромный опыт написания и оптимизации гораздо более сложных запросов и хранимых процедур. Иногда звёзды просто не сходятся.
Источник: https://www.viblo.se/posts/interviewing/
8 Правил Прохождения Техсобеса. Окончание
Начало
5. Устаревший и неактуальный опыт
Как кандидату с опытом, вам нужно быть очень осторожным, говоря об устаревших/неактуальных технологиях или опыте, который не соответствует тому, что ищет интервьюер. Проблема не в том, что у вас есть такой опыт, а в том, что интервьюер опасается, что вы не знаете или не любите то, что требуется, и что вы не сможете адаптироваться к технологиям и процессам новой компании.
Например, ваши навыки написания скриптов для Linux могут быть всё ещё актуальны для компании, работающей с собственным Kubernetes, но нужно это объяснить! Не зацикливайтесь на том, как вы написали скрипт для установки 100 физических машин, потому что в данном контексте это бесполезно. Вместо этого вы можете рассказать о том, как глубокие знания Linux помогают вам писать оптимизированные и безопасные Docker-файлы или устранять сетевые неполадки при запуске в под.
6. Признавайте свои ограничения (но не слишком!)
Большинство кандидатов хорошо осознают свои возможности и знают свои границы. Это, в общем и целом, хорошо. В большинстве случаев, когда человек говорит о теме, в которой он не очень хорошо разбирается, это и так очевидно, так что можно прямо признать это. В то же время, не будьте слишком скромными и не нужно выставлять напоказ все свои слабости!
7. Примеры
Какой бы ни была тема, всегда полезно иметь возможность обратиться к реальному опыту. Будет здорово собрать несколько хороших примеров перед собеседованием — стоит подготовиться!
Например, вас спрашивают о вашем опыте в области событийно-управляемой архитектуры, но вы пока мало что сделали в этой области. Тем не менее, однажды вы внедрили очередь работ. Расскажите об этом и объясните, что вы сделали, как и почему. Другой вариант — вспомнить случай, когда вы рассматривали возможность использования событийно-управляемой архитектуры, но отказались от неё по разным причинам. А затем завершите разговор вопросом о том, как она работает в нанимающей вас компании. У всех технологий есть свои недостатки, но понимание этого часто отсутствует, поэтому это отличный способ продемонстрировать свою зрелость и дать им возможность рассказать о своей системе. Большинство интервьюеров любят рассказывать о том, как работает их уникальная система.
Но есть кое-что, на что стоит обратить внимание, если вы кандидат с опытом! Будьте очень осторожны, приводя примеры десятилетней давности. И будьте столь же осторожны, чтобы не использовать примеры, основанные на неправильных технологиях. Если вы претендуете на должность, связанную с микросервисами, не говорите о разработке приложений WinForms больше, чем это абсолютно необходимо, даже если вы думаете, что это в тему.
8. Вопросы
Едва ли не самый популярный совет для собеседований. Не забудьте задать несколько вопросов. В конце концов, возможно, вы будете там работать, и стоит попытаться заранее обнаружить какие-либо тревожные сигналы! Или, если не получится, хотя бы воспользуйтесь возможностью, чтобы интервьюеры рассказали о чём-то, что им интересно — почти все любят описывать свою текущую архитектуру, структуру команды или повседневную работу! Просто помните, что задаваемые вами вопросы отражают вас: что вас интересует, что вас волнует?
Собеседование окончено!
Получили работу?
Поздравляю! Вас наняли. Это значит, что они считают, что вы справитесь. Поначалу всё может быть очень запутанным и пугающим, особенно если вы не знакомы с этой ролью или типом компании. Со временем всё наладится, приложите все усилия и держитесь, и через пару месяцев вы почувствуете себя как дома.
Не получили работу?
Какой бы ни была причина, не расстраивайтесь! Иногда это выгодно обеим сторонам: возможно, вы не подошли, а может быть, компания оказалась не той, о которой вы мечтали. А может быть, это просто невезение. Однажды я не смог написать простой SQL-запрос, хотя имею огромный опыт написания и оптимизации гораздо более сложных запросов и хранимых процедур. Иногда звёзды просто не сходятся.
Источник: https://www.viblo.se/posts/interviewing/
👍18
День 2446. #Карьера
Не Только Код: Что Делает Тебя Сеньором. Начало
Вы замечали, что на собеседованиях на старшие должности вас всё меньше гоняют по техническим вопросам? Вместо этого спрашивают что-то вроде: «Что такое технический долг?» Или «Что вы делаете, когда сроки срываются? Как расставляете приоритеты в задачах?» Быть сеньором не значит освоить каждый протокол или запомнить каждый алгоритм. Это рассудительность, работа с людьми, принятие решений, долгосрочное мышление. За годы опыта вы совершаете ошибки, и хорошо, если извлекаете из них уроки. Рассмотрим некоторые наиболее важные уроки на пути к сеньорской должности. Будем использовать вымышленного персонажа Эдди.
1. Рассуждения важнее правил
Однажды нам нужно было добавить новые поля в таблицу DynamoDB в рабочей среде. Эдди, блестящий джун, предложил тяжёлую миграцию: реплицировать таблицу, синхронизировать её с потоками, а затем, после недели тестирования, выполнить переход. План казался исчерпывающим, но он не рассматривал более простые варианты. Почему не обновить существующие записи с помощью скрипта? «Это опасно. Нельзя обновлять данные БД в проде», - воскликнул Эдди, без каких-либо обоснований или данных. Но в этой системе БД всего лишь обеспечивала работу офлайн-заданий, поэтому риск был невелик.
Подход Эдди отражал распространённую ловушку: воспринимать «лучшие практики» как абсолютную истину. «Никогда не трогайте прод». «Микросервисы всегда лучше монолита». Правила кажутся безопасными, но они зависят от контекста. Опытный разработчик - не тот, у которого в арсенале обширный набор правил. Он всегда старается объяснить, почему решение имеет смысл в данной ситуации, и взвешивает риски и компромиссы.
2. Не делайте предположений, проверяйте
Когда системы выходят из строя, легко сделать поспешные выводы: «Должно быть, дело в БД», «Возможно, это новое развёртывание». Но предположения отнимают драгоценные часы, а когда прод лежит, каждая минута на счету. Лучшие инженеры не полагаются на догадки. Они доверяют данным и используют свой опыт, чтобы определить, где искать в первую очередь, но всегда проверяют. Настоящее мастерство не в «правильной догадке», а в дисциплине, позволяющей проверять логи, воспроизводить проблемы и просить коллег проверить работоспособность. Проверка решает проблемы быстрее и укрепляет доверие. Ничто не подрывает доверие быстрее, чем самоуверенное обвинение в чём-то неправильном.
3. Сомневайтесь в хороших новостях
Однажды Эдди на радостях воскликнул: «API работает на 20% быстрее после моих изменений!». Странно, его просили просто отрефакторить код. Это выглядело как победа, но, когда что-то выглядит слишком хорошо, чтобы быть правдой, так оно и есть. После анализа мы выяснили: он случайно удалил логику повторных попыток в наших нисходящих вызовах. За блестящими цифрами копились скрытые сбои.
Всегда относитесь к внезапным чудесам скептически. Когда показатели внезапно улучшаются, первым вопросом должен быть: «Что мы сломали?» Здоровый скептицизм не даёт праздновать ложные победы. Он подкрепляет истину: данные ценны, только когда вы понимаете, почему они возникли.
4. Механизм важнее благих намерений
«Мы просто не забудем сделать X» - это всегда исходит из благих намерений, но они не защищают системы. Люди отвлекаются, устают или поджимают сроки. Однажды критический инцидент произошёл из-за того, что кто-то забыл запустить скрипт после развёртывания. Дело не в невнимательности, а в хрупкости процесса. Самые сильные команды не полагаются на память или обещания. Автоматизированные проверки, конвейеры CI/CD, флаги функций, ревью кода — это не «приятные мелочи», а защитные барьеры. Вместо того, чтобы доверять кому-то ручной запуск скрипта, вы делаете скрипт частью процесса развёртывания.
Ведущие инженеры проектируют системы, где безопасный путь — это также и самый простой. Ошибки неизбежны. Сильную инженерную культуру определяет способность системы выявлять эти ошибки раньше, чем это сделают ваши клиенты.
Окончание следует…
Источник: https://levelup.gitconnected.com/beyond-the-code-lessons-that-make-you-senior-1ba44469aa42
Не Только Код: Что Делает Тебя Сеньором. Начало
Вы замечали, что на собеседованиях на старшие должности вас всё меньше гоняют по техническим вопросам? Вместо этого спрашивают что-то вроде: «Что такое технический долг?» Или «Что вы делаете, когда сроки срываются? Как расставляете приоритеты в задачах?» Быть сеньором не значит освоить каждый протокол или запомнить каждый алгоритм. Это рассудительность, работа с людьми, принятие решений, долгосрочное мышление. За годы опыта вы совершаете ошибки, и хорошо, если извлекаете из них уроки. Рассмотрим некоторые наиболее важные уроки на пути к сеньорской должности. Будем использовать вымышленного персонажа Эдди.
1. Рассуждения важнее правил
Однажды нам нужно было добавить новые поля в таблицу DynamoDB в рабочей среде. Эдди, блестящий джун, предложил тяжёлую миграцию: реплицировать таблицу, синхронизировать её с потоками, а затем, после недели тестирования, выполнить переход. План казался исчерпывающим, но он не рассматривал более простые варианты. Почему не обновить существующие записи с помощью скрипта? «Это опасно. Нельзя обновлять данные БД в проде», - воскликнул Эдди, без каких-либо обоснований или данных. Но в этой системе БД всего лишь обеспечивала работу офлайн-заданий, поэтому риск был невелик.
Подход Эдди отражал распространённую ловушку: воспринимать «лучшие практики» как абсолютную истину. «Никогда не трогайте прод». «Микросервисы всегда лучше монолита». Правила кажутся безопасными, но они зависят от контекста. Опытный разработчик - не тот, у которого в арсенале обширный набор правил. Он всегда старается объяснить, почему решение имеет смысл в данной ситуации, и взвешивает риски и компромиссы.
2. Не делайте предположений, проверяйте
Когда системы выходят из строя, легко сделать поспешные выводы: «Должно быть, дело в БД», «Возможно, это новое развёртывание». Но предположения отнимают драгоценные часы, а когда прод лежит, каждая минута на счету. Лучшие инженеры не полагаются на догадки. Они доверяют данным и используют свой опыт, чтобы определить, где искать в первую очередь, но всегда проверяют. Настоящее мастерство не в «правильной догадке», а в дисциплине, позволяющей проверять логи, воспроизводить проблемы и просить коллег проверить работоспособность. Проверка решает проблемы быстрее и укрепляет доверие. Ничто не подрывает доверие быстрее, чем самоуверенное обвинение в чём-то неправильном.
3. Сомневайтесь в хороших новостях
Однажды Эдди на радостях воскликнул: «API работает на 20% быстрее после моих изменений!». Странно, его просили просто отрефакторить код. Это выглядело как победа, но, когда что-то выглядит слишком хорошо, чтобы быть правдой, так оно и есть. После анализа мы выяснили: он случайно удалил логику повторных попыток в наших нисходящих вызовах. За блестящими цифрами копились скрытые сбои.
Всегда относитесь к внезапным чудесам скептически. Когда показатели внезапно улучшаются, первым вопросом должен быть: «Что мы сломали?» Здоровый скептицизм не даёт праздновать ложные победы. Он подкрепляет истину: данные ценны, только когда вы понимаете, почему они возникли.
4. Механизм важнее благих намерений
«Мы просто не забудем сделать X» - это всегда исходит из благих намерений, но они не защищают системы. Люди отвлекаются, устают или поджимают сроки. Однажды критический инцидент произошёл из-за того, что кто-то забыл запустить скрипт после развёртывания. Дело не в невнимательности, а в хрупкости процесса. Самые сильные команды не полагаются на память или обещания. Автоматизированные проверки, конвейеры CI/CD, флаги функций, ревью кода — это не «приятные мелочи», а защитные барьеры. Вместо того, чтобы доверять кому-то ручной запуск скрипта, вы делаете скрипт частью процесса развёртывания.
Ведущие инженеры проектируют системы, где безопасный путь — это также и самый простой. Ошибки неизбежны. Сильную инженерную культуру определяет способность системы выявлять эти ошибки раньше, чем это сделают ваши клиенты.
Окончание следует…
Источник: https://levelup.gitconnected.com/beyond-the-code-lessons-that-make-you-senior-1ba44469aa42
👍28
День 2447. #Карьера
Не Только Код: Что Делает Тебя Сеньором. Окончание
Начало
5. Дисциплина отказа
Однажды Эдди был на встрече с одним из клиентов. Они использовали наши API и хотели внедрить новую логику фильтрации. Вместо того, чтобы реализовывать её на своей стороне, они предложили сделать это на нашем бэкенде. Они убедили Эдди согласиться. Но когда он поделился решением с командой, все ведущие инженеры выразили несогласие. У клиентов не было веских причин так делать, они просто хотели переложить всю сложность на нас.
Это один из самых сложных уроков в карьере. Сеньоры не из тех, кто на всё отвечает «да». Они защищают свои команды от ненужной сложности, отвергают бессмысленные компромиссы, и понимают, что не каждый запрос заслуживает одобрения.
6. Рост начинается с ответственности
В начале карьеры мы во многом полагаемся на старших коллег. Но инженерия полна неопределённости. Старшие коллеги — не те, кто всегда знает правильный ответ; они принимают обоснованные решения, взвешивают компромиссы и берут на себя ответственность. Когда эти решения оказываются неправильными, они не перекладывают вину на других, а принимают последствия, учатся и корректируют свои действия.
7. От защитника к наставнику
Естественным инстинктом является оградить младших коллег от неудач. Оставлять длинные комментарии, объяснять каждую деталь или даже исправлять их код. Это может предотвратить сиюминутные трудности, но также лишает их возможности извлекать уроки, которые можно извлечь только из личного опыта.
Роль сеньора не в предотвращении ошибок, а в создании безопасного пространства, где ошибки могут происходить без катастрофических последствий. Настоящий рост достигается благодаря ошибкам, восстановлению и дальнейшему развитию. Высший показатель лидерства — способность команды процветать без вас. Если вы создали культуру, в которой люди учатся на безопасных ошибках, то вы выполнили свою задачу наставника.
8. Простота масштабируется, сложность ломается
Сделать просто почти всегда лучше, чем заумно. Иногда возникает соблазн проектировать систему с учётом всех возможных сценариев, «закладывая фундамент» в будущее с помощью абстракций и расширяемости. Но чаще всего эти дополнительные уровни превращаются в мёртвый груз. Старайтесь избегать преждевременной сложности любой ценой. Простые решения не только проще писать, но и легче тестировать, поддерживать и адаптировать к ним новых разработчиков.
9. Каждая система рано или поздно ломается, будьте готовы
Ни одна система не является по-настоящему отказоустойчивой. Код живой: он развивается, интегрируется с новыми зависимостями и адаптируется к меняющимся требованиям. Каждое изменение, каким бы небольшим и хорошо протестированным оно ни было, увеличивает вероятность возникновения сбоев. Сеньоры предвидят это, чётко соблюдая гарантии, тщательно контролируя версии API и настраивая мониторинг и т.п. Тесты ценны, но не являются панацеей. При достаточном времени, достаточном трафике и достаточном количестве изменений любая система выйдет из строя. Вопрос - когда и насколько вы готовы к этому.
10. Принимайте изменения и адаптируйтесь
Изменения постоянны, и их темп только ускоряется. Сейчас LLM уже стали частью повседневных рабочих процессов. Есть ли вокруг них хайп? Да. Но было бы ошибкой предполагать, что они просто исчезнут, а мы станем работать по старинке. Они продолжат совершенствоваться и постепенно брать на себя всё больше ответственности.
Мы ещё в начале пути к пониманию долгосрочного влияния LLM. Но уже понятно, что они не заменят инженерное суждение, а при разумном использовании могут ускорить процесс.
Поэтому принятие изменений не означает слепого доверия к коду, сгенерированному ИИ, и не предполагает, что он решит все проблемы. Это означает быть в курсе событий, осторожно экспериментировать и интегрировать то, что действительно приносит пользу, учитывая риски.
Источник: https://levelup.gitconnected.com/beyond-the-code-lessons-that-make-you-senior-1ba44469aa42
Не Только Код: Что Делает Тебя Сеньором. Окончание
Начало
5. Дисциплина отказа
Однажды Эдди был на встрече с одним из клиентов. Они использовали наши API и хотели внедрить новую логику фильтрации. Вместо того, чтобы реализовывать её на своей стороне, они предложили сделать это на нашем бэкенде. Они убедили Эдди согласиться. Но когда он поделился решением с командой, все ведущие инженеры выразили несогласие. У клиентов не было веских причин так делать, они просто хотели переложить всю сложность на нас.
Это один из самых сложных уроков в карьере. Сеньоры не из тех, кто на всё отвечает «да». Они защищают свои команды от ненужной сложности, отвергают бессмысленные компромиссы, и понимают, что не каждый запрос заслуживает одобрения.
6. Рост начинается с ответственности
В начале карьеры мы во многом полагаемся на старших коллег. Но инженерия полна неопределённости. Старшие коллеги — не те, кто всегда знает правильный ответ; они принимают обоснованные решения, взвешивают компромиссы и берут на себя ответственность. Когда эти решения оказываются неправильными, они не перекладывают вину на других, а принимают последствия, учатся и корректируют свои действия.
7. От защитника к наставнику
Естественным инстинктом является оградить младших коллег от неудач. Оставлять длинные комментарии, объяснять каждую деталь или даже исправлять их код. Это может предотвратить сиюминутные трудности, но также лишает их возможности извлекать уроки, которые можно извлечь только из личного опыта.
Роль сеньора не в предотвращении ошибок, а в создании безопасного пространства, где ошибки могут происходить без катастрофических последствий. Настоящий рост достигается благодаря ошибкам, восстановлению и дальнейшему развитию. Высший показатель лидерства — способность команды процветать без вас. Если вы создали культуру, в которой люди учатся на безопасных ошибках, то вы выполнили свою задачу наставника.
8. Простота масштабируется, сложность ломается
Сделать просто почти всегда лучше, чем заумно. Иногда возникает соблазн проектировать систему с учётом всех возможных сценариев, «закладывая фундамент» в будущее с помощью абстракций и расширяемости. Но чаще всего эти дополнительные уровни превращаются в мёртвый груз. Старайтесь избегать преждевременной сложности любой ценой. Простые решения не только проще писать, но и легче тестировать, поддерживать и адаптировать к ним новых разработчиков.
9. Каждая система рано или поздно ломается, будьте готовы
Ни одна система не является по-настоящему отказоустойчивой. Код живой: он развивается, интегрируется с новыми зависимостями и адаптируется к меняющимся требованиям. Каждое изменение, каким бы небольшим и хорошо протестированным оно ни было, увеличивает вероятность возникновения сбоев. Сеньоры предвидят это, чётко соблюдая гарантии, тщательно контролируя версии API и настраивая мониторинг и т.п. Тесты ценны, но не являются панацеей. При достаточном времени, достаточном трафике и достаточном количестве изменений любая система выйдет из строя. Вопрос - когда и насколько вы готовы к этому.
10. Принимайте изменения и адаптируйтесь
Изменения постоянны, и их темп только ускоряется. Сейчас LLM уже стали частью повседневных рабочих процессов. Есть ли вокруг них хайп? Да. Но было бы ошибкой предполагать, что они просто исчезнут, а мы станем работать по старинке. Они продолжат совершенствоваться и постепенно брать на себя всё больше ответственности.
Мы ещё в начале пути к пониманию долгосрочного влияния LLM. Но уже понятно, что они не заменят инженерное суждение, а при разумном использовании могут ускорить процесс.
Поэтому принятие изменений не означает слепого доверия к коду, сгенерированному ИИ, и не предполагает, что он решит все проблемы. Это означает быть в курсе событий, осторожно экспериментировать и интегрировать то, что действительно приносит пользу, учитывая риски.
Источник: https://levelup.gitconnected.com/beyond-the-code-lessons-that-make-you-senior-1ba44469aa42
👍29
День 2451. #Карьера
Я Разработчик Средних Лет, и Мои Лучшие Качества… Изменились
И то, что для меня важно, тоже изменилось.
Автор оригинала: Jeffrey Bakker
Языки, которые я использовал, платформы, на которых я работал, и решённые бизнес-задачи невероятно разнообразны. Мне нравится разработка функций, архитектура, покрытие кода, тестирование, CI/CD, UI и даже документация. Всё должно быть хорошо, так о чём же эта история?
Мой мозг изменился
В среднем возрасте мой технический фокус сместился. Я меньше одержим погоней за каждым новым инструментом и больше сосредоточен на глубине и ясности. Мой интеллект способен справиться с большей широтой, но мой фокус рассеян; я осознаю гораздо больше, о чём раньше не беспокоился. Я не запоминаю детали, как раньше, но быстрее связываю идеи и вижу закономерности, которые раньше упускал из виду.
Я обменял часть своих технических навыков на более «человеческие», и это открыло мне больше дверей. Мне приходится чаще использовать навыки общения. Как интроверта, любившего прятаться в своей работе, эта мысль раньше меня пугала.
Стало не хуже, просто по-другому
Хваля молодых разработчиков за их новые и захватывающие функции, я с теплотой скучаю по той же похвале, но не скучаю по давлению, которое часто с ней связано. Да, я всё ещё иногда работаю сверхурочно, но мне нравится делать это ради тех задач, которые мне нравятся.
Я бывал в центре внимания, но никогда не стремился к нему. Иногда рутинная работа сама по себе награда. Я всегда думаю о том, как помочь нашей команде. Мне бы хотелось работать над темой, которая соответствует моим средне- и долгосрочным карьерным целям, а не над темой месяца.
Мой золотой век был период с 2012 по 2019 год, охватывающий три софтверные корпорации. До этого я уже разрабатывал ПО типичными неправильными способами. Поначалу я отрицал и сопротивлялся некоторым передовым практикам (отвыкать от привычек сложно). Но в итоге я стал лучше, начал отстаивать все передовые практики. Меня слышали и уважали, потому что я добился успеха. Несколько лет спустя я выгорел, пытаясь изменить компанию, которая находилась в таком же состоянии отрицания, что и я сам несколько лет назад.
Мне не нужно переживать прошлое
Каждый из нас вспоминал времена, когда всё шло идеально. Спустя десять лет работы сеньором, я могу сказать, что я-«молодой сеньор», много знал о технологиях, но мало о людях и корпорациях. Я мог действовать самостоятельно, когда позволяли, но моё видение ограничивалось тем, что мне было позволено видеть. Я был способным и всесторонне развитым технически, но в бизнесе у меня был эффект Даннинга-Крюгера.
Что меня ждёт в будущем?
Лет 10 назад один из моих тимлидов углубился в управление персоналом, признав, что он «слишком стар, чтобы идти в ногу с новейшими технологиями и практиками». Другой менеджер, наоборот, сказал, что выбрал менеджмент, потому что разработка со временем стала скучной. Ему нужен был новый вызов.
Я всегда думал, что пойду по пути техлида. Но я оставил стек, на котором специализировался несколько лет. Сейчас я вряд ли могу продемонстрировать какие-либо лидерские качества в текущем стеке. DevOps выглядит привлекательно, поскольку соответствует тому, что я считаю важным. Хотя я бы скучал по временам, когда был и разработчиком функций, и тестировщиком, и DevOpsом.
Итого
У меня была полноценная карьера. Я не сияю так ярко, как раньше, но я стал мудрее. Молодым разработчикам есть на что опереться, чтобы они могли сиять. Никогда ещё технологии разработки ПО не были так многослойны и многообразны. Работа с современными языками программирования может доставлять удовольствие. Мы достаточно раз терпели неудачи, чтобы показать вам, что не работает, и у нас достаточно примеров того, что работает стабильно. Ваша главная задача сейчас — выделяться. Сияйте ярко!
PS: Напишите в комментариях, как изменились ваши приоритеты в карьере с течением времени.
Источник: https://levelup.gitconnected.com/im-a-middle-aged-developer-and-my-time-to-shine-has-sunset-a1b5d5c6ff2d
Я Разработчик Средних Лет, и Мои Лучшие Качества… Изменились
И то, что для меня важно, тоже изменилось.
Автор оригинала: Jeffrey Bakker
Языки, которые я использовал, платформы, на которых я работал, и решённые бизнес-задачи невероятно разнообразны. Мне нравится разработка функций, архитектура, покрытие кода, тестирование, CI/CD, UI и даже документация. Всё должно быть хорошо, так о чём же эта история?
Мой мозг изменился
В среднем возрасте мой технический фокус сместился. Я меньше одержим погоней за каждым новым инструментом и больше сосредоточен на глубине и ясности. Мой интеллект способен справиться с большей широтой, но мой фокус рассеян; я осознаю гораздо больше, о чём раньше не беспокоился. Я не запоминаю детали, как раньше, но быстрее связываю идеи и вижу закономерности, которые раньше упускал из виду.
Я обменял часть своих технических навыков на более «человеческие», и это открыло мне больше дверей. Мне приходится чаще использовать навыки общения. Как интроверта, любившего прятаться в своей работе, эта мысль раньше меня пугала.
Стало не хуже, просто по-другому
Хваля молодых разработчиков за их новые и захватывающие функции, я с теплотой скучаю по той же похвале, но не скучаю по давлению, которое часто с ней связано. Да, я всё ещё иногда работаю сверхурочно, но мне нравится делать это ради тех задач, которые мне нравятся.
Я бывал в центре внимания, но никогда не стремился к нему. Иногда рутинная работа сама по себе награда. Я всегда думаю о том, как помочь нашей команде. Мне бы хотелось работать над темой, которая соответствует моим средне- и долгосрочным карьерным целям, а не над темой месяца.
Мой золотой век был период с 2012 по 2019 год, охватывающий три софтверные корпорации. До этого я уже разрабатывал ПО типичными неправильными способами. Поначалу я отрицал и сопротивлялся некоторым передовым практикам (отвыкать от привычек сложно). Но в итоге я стал лучше, начал отстаивать все передовые практики. Меня слышали и уважали, потому что я добился успеха. Несколько лет спустя я выгорел, пытаясь изменить компанию, которая находилась в таком же состоянии отрицания, что и я сам несколько лет назад.
Мне не нужно переживать прошлое
Каждый из нас вспоминал времена, когда всё шло идеально. Спустя десять лет работы сеньором, я могу сказать, что я-«молодой сеньор», много знал о технологиях, но мало о людях и корпорациях. Я мог действовать самостоятельно, когда позволяли, но моё видение ограничивалось тем, что мне было позволено видеть. Я был способным и всесторонне развитым технически, но в бизнесе у меня был эффект Даннинга-Крюгера.
Что меня ждёт в будущем?
Лет 10 назад один из моих тимлидов углубился в управление персоналом, признав, что он «слишком стар, чтобы идти в ногу с новейшими технологиями и практиками». Другой менеджер, наоборот, сказал, что выбрал менеджмент, потому что разработка со временем стала скучной. Ему нужен был новый вызов.
Я всегда думал, что пойду по пути техлида. Но я оставил стек, на котором специализировался несколько лет. Сейчас я вряд ли могу продемонстрировать какие-либо лидерские качества в текущем стеке. DevOps выглядит привлекательно, поскольку соответствует тому, что я считаю важным. Хотя я бы скучал по временам, когда был и разработчиком функций, и тестировщиком, и DevOpsом.
Итого
У меня была полноценная карьера. Я не сияю так ярко, как раньше, но я стал мудрее. Молодым разработчикам есть на что опереться, чтобы они могли сиять. Никогда ещё технологии разработки ПО не были так многослойны и многообразны. Работа с современными языками программирования может доставлять удовольствие. Мы достаточно раз терпели неудачи, чтобы показать вам, что не работает, и у нас достаточно примеров того, что работает стабильно. Ваша главная задача сейчас — выделяться. Сияйте ярко!
PS: Напишите в комментариях, как изменились ваши приоритеты в карьере с течением времени.
Источник: https://levelup.gitconnected.com/im-a-middle-aged-developer-and-my-time-to-shine-has-sunset-a1b5d5c6ff2d
👍12👎1