День 1929. #Карьера
Наибольшее Влияние на Качество Кода
Вы тщательно собрали команду отличных разработчиков, топ-архитекторов, UX-дизайнеров и т. д. Вы уверены, что с этой командой вы сможете справиться с любой задачей.
Однако после двух лет работы над проектом вы во многом потеряли эту уверенность. Список запрошенных функций продолжает расти, существующие функции необходимо перерабатывать, поскольку потребности бизнеса изменились, а люди работают всё дольше и дольше, чтобы укладываться в сроки. То, что начиналось как обходной путь для более быстрого достижения конечной цели, превратилось в просто работу. Обходные пути больше не являются исключением, а стали правилом. Решение становится всё менее стабильным, повсюду появляются ошибки. Что происходит?
Мы только что обнаружили самое большое влияние на качество кода. Дело не в навыках команды, не в языке программирования или технологиях, которые они используют, а в чём-то другом.
Избегайте режима аврала!
Режим аврала означает работу сверхурочно в течение длительных периодов времени, чтобы завершить проект или уложиться в срок. В период кризиса разработчики часто прилагают дополнительные усилия, чтобы обеспечить своевременную доставку.
Исследования показали, что разработчики, которые много работают в течение длительного времени, что приводит к лишению сна, на 44% менее продуктивны. Сектор, печально известный режимами аврала, — игровая индустрия. Многие игры, в которых разработчики были вынуждены перерабатывать, чтобы укладываться в сроки, приводили к выпуску продуктов с ошибками и плохим отзывам.
Аврал – это провал в управлении проектом.
Ян Шрайбер, доцент Рочестерского технологического института, рассказал о физиологических эффектах аврала. Он говорит, что дело может дойти даже до того, что ваша продуктивность уйдёт в минус: «Когда вы проработаете более 60 часов в неделю, ваши когнитивные функции станут хуже, чем у человека, который вообще не работал.»
Поэтому в следующий раз, когда ваш менеджер по уже просроченному проекту попросит вас «сделать всё возможное», воспримите это буквально. Наденьте кроссовки, бегайте, пока голова не прояснится, и хорошо выспитесь. Эффект будет намного выше, чем просто изнурительно работать от дедлайна к дедлайну.
Источник: https://bartwullems.blogspot.com/2024/05/the-biggest-effect-on-code-quality.html
Наибольшее Влияние на Качество Кода
Вы тщательно собрали команду отличных разработчиков, топ-архитекторов, UX-дизайнеров и т. д. Вы уверены, что с этой командой вы сможете справиться с любой задачей.
Однако после двух лет работы над проектом вы во многом потеряли эту уверенность. Список запрошенных функций продолжает расти, существующие функции необходимо перерабатывать, поскольку потребности бизнеса изменились, а люди работают всё дольше и дольше, чтобы укладываться в сроки. То, что начиналось как обходной путь для более быстрого достижения конечной цели, превратилось в просто работу. Обходные пути больше не являются исключением, а стали правилом. Решение становится всё менее стабильным, повсюду появляются ошибки. Что происходит?
Мы только что обнаружили самое большое влияние на качество кода. Дело не в навыках команды, не в языке программирования или технологиях, которые они используют, а в чём-то другом.
Избегайте режима аврала!
Режим аврала означает работу сверхурочно в течение длительных периодов времени, чтобы завершить проект или уложиться в срок. В период кризиса разработчики часто прилагают дополнительные усилия, чтобы обеспечить своевременную доставку.
Исследования показали, что разработчики, которые много работают в течение длительного времени, что приводит к лишению сна, на 44% менее продуктивны. Сектор, печально известный режимами аврала, — игровая индустрия. Многие игры, в которых разработчики были вынуждены перерабатывать, чтобы укладываться в сроки, приводили к выпуску продуктов с ошибками и плохим отзывам.
Аврал – это провал в управлении проектом.
Ян Шрайбер, доцент Рочестерского технологического института, рассказал о физиологических эффектах аврала. Он говорит, что дело может дойти даже до того, что ваша продуктивность уйдёт в минус: «Когда вы проработаете более 60 часов в неделю, ваши когнитивные функции станут хуже, чем у человека, который вообще не работал.»
Поэтому в следующий раз, когда ваш менеджер по уже просроченному проекту попросит вас «сделать всё возможное», воспримите это буквально. Наденьте кроссовки, бегайте, пока голова не прояснится, и хорошо выспитесь. Эффект будет намного выше, чем просто изнурительно работать от дедлайна к дедлайну.
Источник: https://bartwullems.blogspot.com/2024/05/the-biggest-effect-on-code-quality.html
👍19
День 1955. #Карьера
Ведите Дневник Разработчика. Начало
Разработчики погрязли в абстракциях! От проектирования системы до мельчайших деталей реализации — мы храним в голове огромное количество информации. На уровне проекта менеджер проекта, владелец продукта, тех. менеджер, бизнес аналитик (иногда все в одном лице) помогают нам понять, что делать дальше. Инструменты управления проектами, вроде Jira, отслеживают наш прогресс. Но на уровне кода легко заблудиться.
Дневник разработчика — это инструмент для отслеживания того, что вы делаете и почему. Поначалу это может показаться рутинной работой, но ведение дневника сэкономит массу времени и избавит от многих головных болей во время работы.
Зачем?
Вы напишете лучший код, если сможете сосредоточить 100% своего внимания на решении одной чётко определенной проблемы за раз, и будете расти как разработчик, анализируя, что работает для вас, а что нет. Дневник — место, где можно определить проблему, которую вы решаете, и записать, что вы пробовали и что сработало.
1. Определяем, что делать
Функция продукта может быть чётко определена, а реализация – нет. Используйте дневник, чтобы обозначить всё, что нужно для выполнения задачи, и набросать план действий.
2. Уменьшаем двусмысленность
Не пытайтесь преодолеть путаницу, написав кучу кода, это может занять часы. Потратьте пять минут на то, чтобы изложить на бумаге свои сомнения и гипотезу. Чего вы не знаете? Как это узнать? Как вы думаете, что произойдет?
3. Учимся на своём опыте
Выполнив работу, вы можете точно прочитать, что вы сделали и как вы к этому подошли, и извлечь уроки из того, что было сложно, а что удалось сделать хорошо.
4. Не отвлекаемся
Отвлекаться – естественно. Вы можете наткнуться на некачественный код и захотеть его отрефакторить, обнаружить, что работаете с той частью кодовой базы, которую не хотели трогать, а теперь нужно что-то изучить, и т.п. Постоянное переключение контекста затрудняет выполнение глубокой работы. Запишите мысли и вопросы, которые у вас возникают, в дневник, и вернётесь к ним позже.
5. Выбрасываем заботы из головы
Можно использовать дневник, чтобы отслеживать свои эмоции. «Утренние страницы» — популярный метод очистки беспорядка в голове в начале каждого дня, можно попробовать это. Нервничаете, тревожитесь, взволнованы? Запишите чувства на бумаге, чтобы очистить голову и уделить всё внимание техническим проблемам.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/05/22/you-should-keep-a-developer-s-journal/
Ведите Дневник Разработчика. Начало
Разработчики погрязли в абстракциях! От проектирования системы до мельчайших деталей реализации — мы храним в голове огромное количество информации. На уровне проекта менеджер проекта, владелец продукта, тех. менеджер, бизнес аналитик (иногда все в одном лице) помогают нам понять, что делать дальше. Инструменты управления проектами, вроде Jira, отслеживают наш прогресс. Но на уровне кода легко заблудиться.
Дневник разработчика — это инструмент для отслеживания того, что вы делаете и почему. Поначалу это может показаться рутинной работой, но ведение дневника сэкономит массу времени и избавит от многих головных болей во время работы.
Зачем?
Вы напишете лучший код, если сможете сосредоточить 100% своего внимания на решении одной чётко определенной проблемы за раз, и будете расти как разработчик, анализируя, что работает для вас, а что нет. Дневник — место, где можно определить проблему, которую вы решаете, и записать, что вы пробовали и что сработало.
1. Определяем, что делать
Функция продукта может быть чётко определена, а реализация – нет. Используйте дневник, чтобы обозначить всё, что нужно для выполнения задачи, и набросать план действий.
2. Уменьшаем двусмысленность
Не пытайтесь преодолеть путаницу, написав кучу кода, это может занять часы. Потратьте пять минут на то, чтобы изложить на бумаге свои сомнения и гипотезу. Чего вы не знаете? Как это узнать? Как вы думаете, что произойдет?
3. Учимся на своём опыте
Выполнив работу, вы можете точно прочитать, что вы сделали и как вы к этому подошли, и извлечь уроки из того, что было сложно, а что удалось сделать хорошо.
4. Не отвлекаемся
Отвлекаться – естественно. Вы можете наткнуться на некачественный код и захотеть его отрефакторить, обнаружить, что работаете с той частью кодовой базы, которую не хотели трогать, а теперь нужно что-то изучить, и т.п. Постоянное переключение контекста затрудняет выполнение глубокой работы. Запишите мысли и вопросы, которые у вас возникают, в дневник, и вернётесь к ним позже.
5. Выбрасываем заботы из головы
Можно использовать дневник, чтобы отслеживать свои эмоции. «Утренние страницы» — популярный метод очистки беспорядка в голове в начале каждого дня, можно попробовать это. Нервничаете, тревожитесь, взволнованы? Запишите чувства на бумаге, чтобы очистить голову и уделить всё внимание техническим проблемам.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/05/22/you-should-keep-a-developer-s-journal/
👍17
День 1956. #Карьера
Ведите Дневник Разработчика. Продолжение
Начало. Зачем?
Как?
1. Настройка
Выберите место. Подойдёт любой текстовый редактор, даже редактор кода и файл markdown (только добавьте его в .gitignore). Чем проще этот этап, тем лучше. Лучше использовать рабочую машину, т.к. возможно понадобится вставлять фрагменты кода.
Дневник — ваш личный документ, в котором можно систематизировать и обработать мысли. Текст должен быть понятным и читабельным для вас. Стремитесь к формату списка дел, а не к сочинению. Не зацикливайтесь на форматировании, организации, формулировках, опечатках. Если вы можете ориентироваться в тексте – всё хорошо!
Для начала попробуйте разбивать текст по дням. Каждый день записывайте свою цель (можно разбить её на задачи) и краткое резюме. Кроме того, у вас могут быть разделы для заметок, полезные ссылки, просто мысли о будущем и т.п. Главное – дневник можно настраивать под себя.
2. Прежде чем писать код
В начале каждого рабочего сеанса (спринта, рабочего дня, сессии «помидора») определите цель сеанса, даже если она кажется очевидной. Чего достичь сегодня? Есть ли ясная и чётко определённая задача по написанию кода, которую необходимо выполнить? Нужно ли что-то изучить в кодовой базе? Нужно проверить гипотезу? Как уменьшить двусмысленность?
Иногда будет просто, иногда сложно определиться с целями, иногда будет жгучее желание побыстрей начать писать код. Если вы чувствуете дискомфорт при формулировании своих мыслей, возможно, вы недостаточно ясно представляете своё решение. Отлично! Именно поэтому вы и ведёте дневник.
3. Пока пишете код
- Застрял – запиши
Если обнаружите, что обдумываете проблему дольше минуты, запишите свои мысли в дневник. Если вы застряли в поиске бага, запишите всё, что пробовали до сих пор. Так будет легче организовать свои мысли и обратиться за помощью, если она вам понадобится.
- Разобрался - запиши
Запишите решение или логику, которая помогла решить проблему, или в чём была ошибка. Не судите себя, просто опишите как дела. Это будет полезно для определения того, что работает для вас в долгосрочной перспективе.
- Выбросьте идеи, вопросы и задачи из головы
Работая над кодом, вы естественным образом будете генерировать идеи и вопросы. В большинстве случаев не стоит прерывать работу ради них. Записывание этих задач поможет разгрузить мозг и сосредоточиться на коде. Если задача чётко определена, вы можете даже написать TODO прямо в коде. Но большинство идей не настолько детализированы, поэтому лучше записать их в дневник. Для них даже могут быть отдельные разделы «Вопросы» или «Идеи».
4. Когда закончили задачу
В конце сеанса кодирования запишите, как всё прошло. Помните, это только для вас. Будьте откровенны. Смогли ли выполнить поставленную задачу? Было ли что-то сложнее, чем вы ожидали? Вы неправильно оценили сложность задачи? Можете ли вы определить, что вас расстраивало? Хотели бы вы сделать что-нибудь по-другому, когда вернётесь к этому завтра? Где-то застряли? Сделали ли что-нибудь, чем гордитесь? Короче говоря, сделайте свою собственную ретроспективу своего дня.
Окончание следует…
Источник: https://stackoverflow.blog/2024/05/22/you-should-keep-a-developer-s-journal/
Ведите Дневник Разработчика. Продолжение
Начало. Зачем?
Как?
1. Настройка
Выберите место. Подойдёт любой текстовый редактор, даже редактор кода и файл markdown (только добавьте его в .gitignore). Чем проще этот этап, тем лучше. Лучше использовать рабочую машину, т.к. возможно понадобится вставлять фрагменты кода.
Дневник — ваш личный документ, в котором можно систематизировать и обработать мысли. Текст должен быть понятным и читабельным для вас. Стремитесь к формату списка дел, а не к сочинению. Не зацикливайтесь на форматировании, организации, формулировках, опечатках. Если вы можете ориентироваться в тексте – всё хорошо!
Для начала попробуйте разбивать текст по дням. Каждый день записывайте свою цель (можно разбить её на задачи) и краткое резюме. Кроме того, у вас могут быть разделы для заметок, полезные ссылки, просто мысли о будущем и т.п. Главное – дневник можно настраивать под себя.
2. Прежде чем писать код
В начале каждого рабочего сеанса (спринта, рабочего дня, сессии «помидора») определите цель сеанса, даже если она кажется очевидной. Чего достичь сегодня? Есть ли ясная и чётко определённая задача по написанию кода, которую необходимо выполнить? Нужно ли что-то изучить в кодовой базе? Нужно проверить гипотезу? Как уменьшить двусмысленность?
Иногда будет просто, иногда сложно определиться с целями, иногда будет жгучее желание побыстрей начать писать код. Если вы чувствуете дискомфорт при формулировании своих мыслей, возможно, вы недостаточно ясно представляете своё решение. Отлично! Именно поэтому вы и ведёте дневник.
3. Пока пишете код
- Застрял – запиши
Если обнаружите, что обдумываете проблему дольше минуты, запишите свои мысли в дневник. Если вы застряли в поиске бага, запишите всё, что пробовали до сих пор. Так будет легче организовать свои мысли и обратиться за помощью, если она вам понадобится.
- Разобрался - запиши
Запишите решение или логику, которая помогла решить проблему, или в чём была ошибка. Не судите себя, просто опишите как дела. Это будет полезно для определения того, что работает для вас в долгосрочной перспективе.
- Выбросьте идеи, вопросы и задачи из головы
Работая над кодом, вы естественным образом будете генерировать идеи и вопросы. В большинстве случаев не стоит прерывать работу ради них. Записывание этих задач поможет разгрузить мозг и сосредоточиться на коде. Если задача чётко определена, вы можете даже написать TODO прямо в коде. Но большинство идей не настолько детализированы, поэтому лучше записать их в дневник. Для них даже могут быть отдельные разделы «Вопросы» или «Идеи».
4. Когда закончили задачу
В конце сеанса кодирования запишите, как всё прошло. Помните, это только для вас. Будьте откровенны. Смогли ли выполнить поставленную задачу? Было ли что-то сложнее, чем вы ожидали? Вы неправильно оценили сложность задачи? Можете ли вы определить, что вас расстраивало? Хотели бы вы сделать что-нибудь по-другому, когда вернётесь к этому завтра? Где-то застряли? Сделали ли что-нибудь, чем гордитесь? Короче говоря, сделайте свою собственную ретроспективу своего дня.
Окончание следует…
Источник: https://stackoverflow.blog/2024/05/22/you-should-keep-a-developer-s-journal/
👍19
День 1957. #Карьера
Ведите Дневник Разработчика. Окончание
Начало. Зачем?
Продолжение. Как?
Ключи к успеху
1. Создаём привычку
Возьмите за привычку писать в начале и в конце каждого сеанса кодирования. Держите дневник поблизости - всегда на расстоянии одной вкладки. У вас должна быть возможность проверить свои заметки или сразу сделать дополнительные заметки. Ваш дневник становится всё более ценным, чем дольше вы его ведёте, поскольку начинают проявляться закономерности.
2. Пишем прямо
Выразите то, что думаете, словами, которые приходят на ум, как можно короче. Никто не ставит оценок, не нужно никого впечатлять красноречием.
3. Думаем о потребностях
Дневник должен включать в себя всё, что вам нужно для эффективной работы. Например, полезно озвучивать для себя свои тревоги и негативные мысли: «Не могу поверить, что уже третий день занимаюсь этой проблемой» или «Чувствую себя самозванцем». Это неприятные мысли, но, если они у вас всё равно возникают, запишите их на бумаге, чтобы сосредоточиться на работе, а не зацикливаться на размышлениях.
4. Учимся на своём опыте
В конце спринта, месяца или квартала выделите немного времени для просмотра своего дневника. Не нужно читать мелкие детали, обратите внимание на то, что вызывало трудности и что помогало их решать, и чего вы достигали каждый день.
Это полезно для:
- Понимания, какой объём работы вы способны выполнить;
- Встреч 1 на 1 с начальником;
- Помощи коллегам, чтобы помочь повысить уровень вашей команды;
- Документирования ваших достижений для будущих разговоров о карьерном росте.
Запишите выводы, полученные в результате размышлений, в том же журнале, например, в разделе «Выводы из этого спринта/проекта/квартала». Опять же, это заставит вас задуматься о том, что вы делаете. Подумайте о том, чтобы поделиться своими знаниями с командой и руководителем. Если у вас возникли проблемы с концепцией/инструментом/частью кодовой базы, скорее всего, у ваших коллег (особенно новичков) тоже.
5. Бережём внимание
Написание текста параллельно с обычной работой по программированию может показаться совершенно другой работой, но, если вы будете придерживаться этого, это станет вашей второй натурой и сэкономит вам массу времени. Гораздо лучше запутаться, описывая мысли в начале проекта, чем когда вы в середине проекта написали кучу кода в десятках файлах. Потратьте пять минут, чтобы спланировать свой день сейчас вместо того, чтобы бегать по кругу позже.
Хороший дневник разработчика должен делать три вещи:
1) Подтолкнуть к обдумыванию своих идей и планированию каждого дня, прежде чем начинать программировать.
2) Заставить более внимательно относиться к своим успехам и трудностям, чтобы вы могли повысить свой уровень.
3) Очищать ваш разум от всего, что мешает кодированию.
Попробуйте вести журнал разработки для вашего следующего проекта или спринта. Вы можете быть удивлены тем, насколько вы станете продуктивнее!
Источник: https://stackoverflow.blog/2024/05/22/you-should-keep-a-developer-s-journal/
Ведите Дневник Разработчика. Окончание
Начало. Зачем?
Продолжение. Как?
Ключи к успеху
1. Создаём привычку
Возьмите за привычку писать в начале и в конце каждого сеанса кодирования. Держите дневник поблизости - всегда на расстоянии одной вкладки. У вас должна быть возможность проверить свои заметки или сразу сделать дополнительные заметки. Ваш дневник становится всё более ценным, чем дольше вы его ведёте, поскольку начинают проявляться закономерности.
2. Пишем прямо
Выразите то, что думаете, словами, которые приходят на ум, как можно короче. Никто не ставит оценок, не нужно никого впечатлять красноречием.
3. Думаем о потребностях
Дневник должен включать в себя всё, что вам нужно для эффективной работы. Например, полезно озвучивать для себя свои тревоги и негативные мысли: «Не могу поверить, что уже третий день занимаюсь этой проблемой» или «Чувствую себя самозванцем». Это неприятные мысли, но, если они у вас всё равно возникают, запишите их на бумаге, чтобы сосредоточиться на работе, а не зацикливаться на размышлениях.
4. Учимся на своём опыте
В конце спринта, месяца или квартала выделите немного времени для просмотра своего дневника. Не нужно читать мелкие детали, обратите внимание на то, что вызывало трудности и что помогало их решать, и чего вы достигали каждый день.
Это полезно для:
- Понимания, какой объём работы вы способны выполнить;
- Встреч 1 на 1 с начальником;
- Помощи коллегам, чтобы помочь повысить уровень вашей команды;
- Документирования ваших достижений для будущих разговоров о карьерном росте.
Запишите выводы, полученные в результате размышлений, в том же журнале, например, в разделе «Выводы из этого спринта/проекта/квартала». Опять же, это заставит вас задуматься о том, что вы делаете. Подумайте о том, чтобы поделиться своими знаниями с командой и руководителем. Если у вас возникли проблемы с концепцией/инструментом/частью кодовой базы, скорее всего, у ваших коллег (особенно новичков) тоже.
5. Бережём внимание
Написание текста параллельно с обычной работой по программированию может показаться совершенно другой работой, но, если вы будете придерживаться этого, это станет вашей второй натурой и сэкономит вам массу времени. Гораздо лучше запутаться, описывая мысли в начале проекта, чем когда вы в середине проекта написали кучу кода в десятках файлах. Потратьте пять минут, чтобы спланировать свой день сейчас вместо того, чтобы бегать по кругу позже.
Хороший дневник разработчика должен делать три вещи:
1) Подтолкнуть к обдумыванию своих идей и планированию каждого дня, прежде чем начинать программировать.
2) Заставить более внимательно относиться к своим успехам и трудностям, чтобы вы могли повысить свой уровень.
3) Очищать ваш разум от всего, что мешает кодированию.
Попробуйте вести журнал разработки для вашего следующего проекта или спринта. Вы можете быть удивлены тем, насколько вы станете продуктивнее!
Источник: https://stackoverflow.blog/2024/05/22/you-should-keep-a-developer-s-journal/
👍9
День 1985. #Карьера
Полезные и Игнорируемые Навыки
Есть полезный, но недооцененный навык: принимать определённую степень хлопот и абсурда, когда этого требует реальность.
Это не самый приятный навык, поэтому его недооценивают. Но вы понимаете, насколько он может быть полезен, когда замечаете кого-то, у кого этого нет. Человек изо всех сил пытается пережить день, расстраиваясь из-за малейших неприятностей. Как большой начальник сходит с ума после того, как в аэропорту дважды меняли выход на посадку. Как он продвинулся так далеко в жизни, не имея возможности справляться с мелкими неприятностями, находящимися вне его контроля? Наиболее вероятный ответ: отрицая то, что, по его мнению, он контролирует, и требуя нереальной точности от подчинённых, которые компенсируют это сокрытием плохих новостей.
Вот ещё несколько полезных и недооцененных навыков:
1. Ваше желание чтобы что-то было правдой, влияет на то, насколько правдивым вы это считаете.
Это заметно в инвестировании, когда огромные вознаграждения за угаданный исход коррелируют с непоколебимой верой людей в свою правоту. Идея о соразмерности вознаграждения способностям верна лишь отчасти. Когда вознаграждение становится достаточно высоким, умственные способности, которые обычно были бы направлены на разработку стратегии и расчёт, перегружены мечтами о награде. Отчасти поэтому люди тратят выходные на поиск нового телефона и 15 минут на выбор крупной инвестиции. Признание того, что огромные награды требуют дополнительного скептицизма в отношении ваших рассуждений, недооценено.
2. Уважительно общаться с людьми, с которыми вы не согласны.
Доверие к человеку выше, когда вы близки. Но вы столкнётесь с большим количеством людей, которые с вами не согласны. Чем больше Интернет знакомит людей с новыми точками зрения, тем больше людей раздражает существование других точек зрения. Способ открыть свой разум тем, с кем вы не согласны, состоит в том, чтобы найти тему, где ваши взгляды совпадают. Это ставит галочку в вашей голове: «Этот человек не совсем сумасшедший». И уже дальше обсуждайте темы, в которых вы не согласны. Без первого шага слишком легко списать человека со счетов, прежде чем вы услышите его аргументы.
3. Возможность поговорить 10 минут с кем угодно.
Технологии заменили многие личные разговоры. Сидеть с кем-то, кого вы никогда не встречали, смотреть ему в глаза и поддерживать разговор – то, что раньше было настолько обычным явлением, что не считалось навыком – теперь является конкурентным преимуществом.
4. Переходить к сути.
Все заняты. Выскажите свою точку зрения, используя как можно меньше слов, и более не мешайте.
5. Дипломатично говорить: «Нет».
«Нет» часто произносится двумя разрушительными способами. Во-первых, человеку неприятно говорить «нет», поэтому он тянет или говорит «да», откладывая неизбежное «нет». Так вы не держите слово, и другой человек будет разочарован больше, чем если бы вы сразу отказали. Другой вариант —непреднамеренное резкое «нет», из-за которого другой человек больше никогда не захочет привлекать ваше внимание к какой-либо идее или проблеме. Дипломатичное «нет» — это когда вы даёте однозначный ответ, но заботитесь о том, как собеседник может интерпретировать его.
6. Уважать удачу так же, как и риск.
На результаты могут влиять события, находящиеся вне вашего контроля. И удача, и риск происходят потому, что мир слишком сложен, чтобы позволить 100% ваших действий определять 100% ваших результатов. Но риск легко замечать, потому что он – приемлемая отмазка, когда что-то идёт не так. Удача – наоборот. Больно думать, что часть, а может и весь ваш успех не был вызван вашими действиями. Так удача преуменьшается и игнорируется в отличие от риска. Способность осознавать, что ваши победы могут не сигнализировать о том, что вы сделали что-то правильно, так же как ваши поражения могут не сигнализировать о том, что вы сделали что-то неправильно, жизненно важна для изучения чего-то ценного на основе обратной связи из реального мира.
Источник: https://collabfund.com/blog/useful-and-overlooked-skills/
Полезные и Игнорируемые Навыки
Есть полезный, но недооцененный навык: принимать определённую степень хлопот и абсурда, когда этого требует реальность.
Это не самый приятный навык, поэтому его недооценивают. Но вы понимаете, насколько он может быть полезен, когда замечаете кого-то, у кого этого нет. Человек изо всех сил пытается пережить день, расстраиваясь из-за малейших неприятностей. Как большой начальник сходит с ума после того, как в аэропорту дважды меняли выход на посадку. Как он продвинулся так далеко в жизни, не имея возможности справляться с мелкими неприятностями, находящимися вне его контроля? Наиболее вероятный ответ: отрицая то, что, по его мнению, он контролирует, и требуя нереальной точности от подчинённых, которые компенсируют это сокрытием плохих новостей.
Вот ещё несколько полезных и недооцененных навыков:
1. Ваше желание чтобы что-то было правдой, влияет на то, насколько правдивым вы это считаете.
Это заметно в инвестировании, когда огромные вознаграждения за угаданный исход коррелируют с непоколебимой верой людей в свою правоту. Идея о соразмерности вознаграждения способностям верна лишь отчасти. Когда вознаграждение становится достаточно высоким, умственные способности, которые обычно были бы направлены на разработку стратегии и расчёт, перегружены мечтами о награде. Отчасти поэтому люди тратят выходные на поиск нового телефона и 15 минут на выбор крупной инвестиции. Признание того, что огромные награды требуют дополнительного скептицизма в отношении ваших рассуждений, недооценено.
2. Уважительно общаться с людьми, с которыми вы не согласны.
Доверие к человеку выше, когда вы близки. Но вы столкнётесь с большим количеством людей, которые с вами не согласны. Чем больше Интернет знакомит людей с новыми точками зрения, тем больше людей раздражает существование других точек зрения. Способ открыть свой разум тем, с кем вы не согласны, состоит в том, чтобы найти тему, где ваши взгляды совпадают. Это ставит галочку в вашей голове: «Этот человек не совсем сумасшедший». И уже дальше обсуждайте темы, в которых вы не согласны. Без первого шага слишком легко списать человека со счетов, прежде чем вы услышите его аргументы.
3. Возможность поговорить 10 минут с кем угодно.
Технологии заменили многие личные разговоры. Сидеть с кем-то, кого вы никогда не встречали, смотреть ему в глаза и поддерживать разговор – то, что раньше было настолько обычным явлением, что не считалось навыком – теперь является конкурентным преимуществом.
4. Переходить к сути.
Все заняты. Выскажите свою точку зрения, используя как можно меньше слов, и более не мешайте.
5. Дипломатично говорить: «Нет».
«Нет» часто произносится двумя разрушительными способами. Во-первых, человеку неприятно говорить «нет», поэтому он тянет или говорит «да», откладывая неизбежное «нет». Так вы не держите слово, и другой человек будет разочарован больше, чем если бы вы сразу отказали. Другой вариант —непреднамеренное резкое «нет», из-за которого другой человек больше никогда не захочет привлекать ваше внимание к какой-либо идее или проблеме. Дипломатичное «нет» — это когда вы даёте однозначный ответ, но заботитесь о том, как собеседник может интерпретировать его.
6. Уважать удачу так же, как и риск.
На результаты могут влиять события, находящиеся вне вашего контроля. И удача, и риск происходят потому, что мир слишком сложен, чтобы позволить 100% ваших действий определять 100% ваших результатов. Но риск легко замечать, потому что он – приемлемая отмазка, когда что-то идёт не так. Удача – наоборот. Больно думать, что часть, а может и весь ваш успех не был вызван вашими действиями. Так удача преуменьшается и игнорируется в отличие от риска. Способность осознавать, что ваши победы могут не сигнализировать о том, что вы сделали что-то правильно, так же как ваши поражения могут не сигнализировать о том, что вы сделали что-то неправильно, жизненно важна для изучения чего-то ценного на основе обратной связи из реального мира.
Источник: https://collabfund.com/blog/useful-and-overlooked-skills/
👍16👎1
День 2057. #Карьера
Категории Руководства в Технических Командах. Начало
В технических проектах важно правильно структурировать, укомплектовывать команды и правильно руководить ими. Один из вариантов — разбить руководителей команд по категориям ответственности. Руководство охватывает огромный спектр вещей, и попытка найти кого-то, кто может быть хорош во всех, часто превращается в охоту за единорогом. Обычно люди хороши в 1-2 областях, и им лучше полностью сосредоточиться на них. Следующие категории являются хорошей отправной точкой для разделения ответственности по руководству командой, но, конечно, реальность всегда сложнее.
1. Общее управление
Самая важная обязанность — гарантировать, что команда движется в правильном направлении: работают ли они над правильной целью высокого уровня и есть ли реалистичный план её достижения?
Общее управление подразумевает работу над:
- Определением миссии, видения или устава.
- Выбором целей, планов и дорожной карты.
- Расстановкой приоритетов между проектами, которые может взять на себя команда.
- Сообщением вышеизложенного как команде, так и людям за её пределами.
Важнейшим навыком является прогнозирование (как в масштабе команды, так и в масштабе компании), т.к. расстановка приоритетов сводится к вопросу: «Какой эффект будет от реализации нашей командой этого проекта?» Также важно уметь хорошо доносить эти прогнозы, приоритеты и цели команды до других заинтересованных сторон.
Хорошо управляемая команда ставит большие достижения на поток. Плохо - чаще всего отстаёт и сталкивается с внезапными трудностями, то есть неправильно предсказывает, какая работа будет наиболее важной, и делает её слишком мало (начинает поздно, нанимает недостаточно людей нужной квалификации и т.п.). Другие признаки плохого управления включают непонимание членами команды, почему они работают над чем-то; работа команды над проектами, которые приносят мало пользы; трения с коллегами или споры о масштабах; или важные проекты, ускользающие от внимания команды.
2. Управление людьми
Означает ответственность за успех людей в команде, чаще всего включающую:
- Коучинг людей для роста их навыков и карьеры.
- Разработку и контроль процессов найма для команды.
- Установление и сообщение ожиданий производительности и их оценка.
Важнейшая ежедневная обязанность — личные встречи (типа коучинга, а не проверки статуса). Другие обязанности: написание должностных инструкций, организация собеседований, поиск кандидатов, сбор отзывов, написание обзоров продуктивности, помощь людям в понимании политики компании, карьерный коучинг и т.д.
Важнейший навык - понимание людей, сопереживание и оценка их перспектив в смысле знания того, что способствует высокой производительности (например, что делает кого-то отличным инженером или исследователем). Также важно уметь вести сложные разговоры, воспринимать чужое мнение и отстаивать свою позицию.
Главный результат - высокопроизводительные и счастливые члены команды. Команды с лучшим управлением нанимают отличных людей, быстро дают им обратную связь по всем вопросам, корректируют их курс, помогают им со временем увеличивать своё влияние и в целом отлично проводить время на работе. Плохое управление людьми выглядит так, будто люди хронически неэффективны или имеют низкий моральный дух.
Распространённый вопрос: насколько техническим должен быть менеджер? Обычно ему нужно иметь достаточно знаний, чтобы следить за большинством обсуждений, не замедляя их, понимать, кто прав в большинстве споров, и в целом легко ориентироваться.
Менеджер по людям несёт ответственность за то, чтобы его подчинённые получали наставничество и обратную связь, но ему не нужно быть основным лицом, осуществляющим это. Часто наставничество в конкретной области исходит от того, кто отвечает за техническое руководство, реже - кого-то другого в организации.
Продолжение следует…
Источник: https://www.benkuhn.net/leadcats/
Категории Руководства в Технических Командах. Начало
В технических проектах важно правильно структурировать, укомплектовывать команды и правильно руководить ими. Один из вариантов — разбить руководителей команд по категориям ответственности. Руководство охватывает огромный спектр вещей, и попытка найти кого-то, кто может быть хорош во всех, часто превращается в охоту за единорогом. Обычно люди хороши в 1-2 областях, и им лучше полностью сосредоточиться на них. Следующие категории являются хорошей отправной точкой для разделения ответственности по руководству командой, но, конечно, реальность всегда сложнее.
1. Общее управление
Самая важная обязанность — гарантировать, что команда движется в правильном направлении: работают ли они над правильной целью высокого уровня и есть ли реалистичный план её достижения?
Общее управление подразумевает работу над:
- Определением миссии, видения или устава.
- Выбором целей, планов и дорожной карты.
- Расстановкой приоритетов между проектами, которые может взять на себя команда.
- Сообщением вышеизложенного как команде, так и людям за её пределами.
Важнейшим навыком является прогнозирование (как в масштабе команды, так и в масштабе компании), т.к. расстановка приоритетов сводится к вопросу: «Какой эффект будет от реализации нашей командой этого проекта?» Также важно уметь хорошо доносить эти прогнозы, приоритеты и цели команды до других заинтересованных сторон.
Хорошо управляемая команда ставит большие достижения на поток. Плохо - чаще всего отстаёт и сталкивается с внезапными трудностями, то есть неправильно предсказывает, какая работа будет наиболее важной, и делает её слишком мало (начинает поздно, нанимает недостаточно людей нужной квалификации и т.п.). Другие признаки плохого управления включают непонимание членами команды, почему они работают над чем-то; работа команды над проектами, которые приносят мало пользы; трения с коллегами или споры о масштабах; или важные проекты, ускользающие от внимания команды.
2. Управление людьми
Означает ответственность за успех людей в команде, чаще всего включающую:
- Коучинг людей для роста их навыков и карьеры.
- Разработку и контроль процессов найма для команды.
- Установление и сообщение ожиданий производительности и их оценка.
Важнейшая ежедневная обязанность — личные встречи (типа коучинга, а не проверки статуса). Другие обязанности: написание должностных инструкций, организация собеседований, поиск кандидатов, сбор отзывов, написание обзоров продуктивности, помощь людям в понимании политики компании, карьерный коучинг и т.д.
Важнейший навык - понимание людей, сопереживание и оценка их перспектив в смысле знания того, что способствует высокой производительности (например, что делает кого-то отличным инженером или исследователем). Также важно уметь вести сложные разговоры, воспринимать чужое мнение и отстаивать свою позицию.
Главный результат - высокопроизводительные и счастливые члены команды. Команды с лучшим управлением нанимают отличных людей, быстро дают им обратную связь по всем вопросам, корректируют их курс, помогают им со временем увеличивать своё влияние и в целом отлично проводить время на работе. Плохое управление людьми выглядит так, будто люди хронически неэффективны или имеют низкий моральный дух.
Распространённый вопрос: насколько техническим должен быть менеджер? Обычно ему нужно иметь достаточно знаний, чтобы следить за большинством обсуждений, не замедляя их, понимать, кто прав в большинстве споров, и в целом легко ориентироваться.
Менеджер по людям несёт ответственность за то, чтобы его подчинённые получали наставничество и обратную связь, но ему не нужно быть основным лицом, осуществляющим это. Часто наставничество в конкретной области исходит от того, кто отвечает за техническое руководство, реже - кого-то другого в организации.
Продолжение следует…
Источник: https://www.benkuhn.net/leadcats/
👍5
День 2058. #Карьера
Категории Руководства в Технических Командах. Продолжение
Начало
3. Управление проектами
Означает обеспечение хорошей работы команды: то есть, чтобы каждый работал эффективно над приоритетами команды, не ждал других и оставался при этом ситуативно осведомлённым о том, что ещё происходит. В краткосрочной перспективе это ключевой фактор, определяющий производительность команды.
Ежедневные задачи:
- Установление и исполнение «рабочего ритма» команды, то есть набора повторяющихся встреч/ритуалов, которые помогают выполнять работу (стендапы, встречи по планированию/приоритизации, ретроспективы и т. д.)
- Выяснение, как разделить работу в команде, делегирование и мониторинг прогресса, чтобы убедиться, что задача не «застряла».
- Поддержание ориентации команды путём обеспечения «видимости» работы, например, с помощью каналов Slack или трекера задач и т. д.
- Обеспечение контакта между командой и остальной частью компании.
Управление проектами — это не просто административная задача; для его успешного выполнения требуется значительный объём экспертных знаний в предметной области (чтобы следить за обсуждениями проекта, понимать обновления статуса, отслеживать зависимости и т. д.). Помимо этого, полезно быть организованным и ориентированным на детали, а также иметь хорошие ментальные модели людей:
- Кто будет хорош в каких типах работы?
- Какие виды координационных ритуалов полезны для этой команды?
Хорошее управление проектами едва заметно: просто «всё идёт своим чередом». Оно заметно, когда всё плохо, что в основном проявляется в неэффективной работе: люди блокируются, часто переключаются из-за перебора приоритетов, неэффективны, т.к. проект им не подходит, выполняют работу неправильно, т.к. не понимают основной цели, упускают важную информацию, которая не была до них корректно доведена, и т. д.
Когда команды становятся большими, управление проектами проще всего делегировать и разделить. Команду в 10+ человек лучше разделить, дать им разные области проекта и отдельных менеджеров проекта.
4. Техническое руководство
Означает ответственность за качество технической работы команды.
Конкретная работа включает:
- Установку технического направления (например, программы исследований на тему или разработку архитектуры системы).
- Проверку выполнения в соответствии с этим направлением (проверку экспериментальных проектов и результатов, технических проектных документов, проверку кода и т. д.)
- Другое техническое наставничество, например, личный менторинг, парное взаимодействие и т. д.
- Частично индивидуальное выполнение, хотя это может варьироваться в зависимости от того, насколько занят технический руководитель.
На практике многие команды имеют достаточно широкую область действия, чтобы в итоге иметь несколько технических руководителей в разных областях — разделенных либо «вертикально» по проекту, либо «горизонтально» по набору навыков, либо частично и так, и так.
Важнейшим навыком для технического руководителя является экспертиза в области. Техническая коммуникация, вероятно, является следующей по важности.
Когда техническое руководство не на должном уровне, это чаще всего проявляется в виде накопления долгов или других проблем, которые замедляют выполнение: фиктивные результаты исследований, неинформативные эксперименты, нестабильные системы, частые сбои и т. д.
Окончание следует…
Источник: https://www.benkuhn.net/leadcats/
Категории Руководства в Технических Командах. Продолжение
Начало
3. Управление проектами
Означает обеспечение хорошей работы команды: то есть, чтобы каждый работал эффективно над приоритетами команды, не ждал других и оставался при этом ситуативно осведомлённым о том, что ещё происходит. В краткосрочной перспективе это ключевой фактор, определяющий производительность команды.
Ежедневные задачи:
- Установление и исполнение «рабочего ритма» команды, то есть набора повторяющихся встреч/ритуалов, которые помогают выполнять работу (стендапы, встречи по планированию/приоритизации, ретроспективы и т. д.)
- Выяснение, как разделить работу в команде, делегирование и мониторинг прогресса, чтобы убедиться, что задача не «застряла».
- Поддержание ориентации команды путём обеспечения «видимости» работы, например, с помощью каналов Slack или трекера задач и т. д.
- Обеспечение контакта между командой и остальной частью компании.
Управление проектами — это не просто административная задача; для его успешного выполнения требуется значительный объём экспертных знаний в предметной области (чтобы следить за обсуждениями проекта, понимать обновления статуса, отслеживать зависимости и т. д.). Помимо этого, полезно быть организованным и ориентированным на детали, а также иметь хорошие ментальные модели людей:
- Кто будет хорош в каких типах работы?
- Какие виды координационных ритуалов полезны для этой команды?
Хорошее управление проектами едва заметно: просто «всё идёт своим чередом». Оно заметно, когда всё плохо, что в основном проявляется в неэффективной работе: люди блокируются, часто переключаются из-за перебора приоритетов, неэффективны, т.к. проект им не подходит, выполняют работу неправильно, т.к. не понимают основной цели, упускают важную информацию, которая не была до них корректно доведена, и т. д.
Когда команды становятся большими, управление проектами проще всего делегировать и разделить. Команду в 10+ человек лучше разделить, дать им разные области проекта и отдельных менеджеров проекта.
4. Техническое руководство
Означает ответственность за качество технической работы команды.
Конкретная работа включает:
- Установку технического направления (например, программы исследований на тему или разработку архитектуры системы).
- Проверку выполнения в соответствии с этим направлением (проверку экспериментальных проектов и результатов, технических проектных документов, проверку кода и т. д.)
- Другое техническое наставничество, например, личный менторинг, парное взаимодействие и т. д.
- Частично индивидуальное выполнение, хотя это может варьироваться в зависимости от того, насколько занят технический руководитель.
На практике многие команды имеют достаточно широкую область действия, чтобы в итоге иметь несколько технических руководителей в разных областях — разделенных либо «вертикально» по проекту, либо «горизонтально» по набору навыков, либо частично и так, и так.
Важнейшим навыком для технического руководителя является экспертиза в области. Техническая коммуникация, вероятно, является следующей по важности.
Когда техническое руководство не на должном уровне, это чаще всего проявляется в виде накопления долгов или других проблем, которые замедляют выполнение: фиктивные результаты исследований, неинформативные эксперименты, нестабильные системы, частые сбои и т. д.
Окончание следует…
Источник: https://www.benkuhn.net/leadcats/
👍8
День 2059. #Карьера
Категории Руководства в Технических Командах. Окончание
Начало
Продолжение
Вот несколько примеров разделения ответственности из реальной жизни. Они крайне неполные и по-прежнему представляют собой упрощённую схему — в любой конкретной команде точное разделение будет зависеть от навыков вовлеченных лидеров, и будет много неясностей и перекрытий ответственности!
«Менеджер – техлид»
Когда новая компания вводит своих первых технических менеджеров, они часто делают это, переводя своего самого сильного технического специалиста(-ов) на руководящую должность и ожидая, что они выполнят все обязанности техлида (см. п.4). Некоторые прекрасно справляются с такими ролями, но чаще всего новый менеджер не очень хорош в одной или нескольких обязанностях — чаще всего в управлении людьми — и испытывает трудности из-за количества других вещей, за которые он отвечает.
Вот несколько факторов, которые повысят вероятность успеха техлида:
- команда небольшая или не испытывает давления, так что у них больше времени, чтобы сосредоточиться на своих областях роста;
- лид имеет высоко вовлечённого менеджера(-ов), который может поддержать, когда нужна помощь;
- домен достаточно прост или инженеры имеют достаточно опыта, так что потребность в технадзоре ограничена;
- у лида большой предыдущий опыт в тех. руководстве, и в управлении людьми;
- лид готов работать много (это, конечно, нельзя считать нормальным).
Инженерный менеджер (ИМ) / техлид (ТЛ)
Такой тип разделения распространён в крупных технологических компаниях, где ИМ отвечает за общее руководство, людей и управление проектами, а ТЛ - за техническое руководство. ТЛ здесь не обязательно должен быть формальным званием, и иногда в команде будет несколько ТЛ в разных областях. Тех. руководство может осуществляться и несколькими сеньорами в разных частях сервиса (реализация модели, архитектура, планирование запросов, управление хранилищем и т. д.).
Продукт-менеджер / техлид
Это разделение менее распространено. ПМ должны действовать как «мини-гендиректора» продуктовой области с довольно широкой автономией для работы в этой области. Поскольку эта роль включает множество компетенций, им не нужно быть такими же технически подкованными, как обычному ИМ.
Это сработает, если у ПМ и ТЛ каждой команды крепкие рабочие отношения, так что они могут эффективно общаться о таких вещах, как компромиссы между скоростью и техническим качеством, а не просто делать, как хочет ПМ.
Менеджер по персоналу/руководитель исследований
В этом разделении, в отличие от разделения ИМ/ТЛ в инженерной команде, разумнее, чтобы руководитель исследования отвечал за общее направление, поскольку оно в значительной степени зависит от высококонтекстных интуитивных суждений о том, в каком направлении исследования следовать. Во многих (хотя и не во всех!) инженерных командах приоритеты в меньшей степени зависят от такого рода высокотехнических суждений.
Это интересно как пример настройки, в которой менеджер по персоналу не отвечает (в первую очередь) за общее направление. Это в некоторой степени аналогично разделению технического директора и вице-президента по инжинирингу в некоторых технологических компаниях, где технический директор отвечает за общее руководство, но большая часть ответственности за руководство людьми лежит на вице-президенте по инженерным разработкам, который ему подчиняется.
Источник: https://www.benkuhn.net/leadcats/
Категории Руководства в Технических Командах. Окончание
Начало
Продолжение
Вот несколько примеров разделения ответственности из реальной жизни. Они крайне неполные и по-прежнему представляют собой упрощённую схему — в любой конкретной команде точное разделение будет зависеть от навыков вовлеченных лидеров, и будет много неясностей и перекрытий ответственности!
«Менеджер – техлид»
Когда новая компания вводит своих первых технических менеджеров, они часто делают это, переводя своего самого сильного технического специалиста(-ов) на руководящую должность и ожидая, что они выполнят все обязанности техлида (см. п.4). Некоторые прекрасно справляются с такими ролями, но чаще всего новый менеджер не очень хорош в одной или нескольких обязанностях — чаще всего в управлении людьми — и испытывает трудности из-за количества других вещей, за которые он отвечает.
Вот несколько факторов, которые повысят вероятность успеха техлида:
- команда небольшая или не испытывает давления, так что у них больше времени, чтобы сосредоточиться на своих областях роста;
- лид имеет высоко вовлечённого менеджера(-ов), который может поддержать, когда нужна помощь;
- домен достаточно прост или инженеры имеют достаточно опыта, так что потребность в технадзоре ограничена;
- у лида большой предыдущий опыт в тех. руководстве, и в управлении людьми;
- лид готов работать много (это, конечно, нельзя считать нормальным).
Инженерный менеджер (ИМ) / техлид (ТЛ)
Такой тип разделения распространён в крупных технологических компаниях, где ИМ отвечает за общее руководство, людей и управление проектами, а ТЛ - за техническое руководство. ТЛ здесь не обязательно должен быть формальным званием, и иногда в команде будет несколько ТЛ в разных областях. Тех. руководство может осуществляться и несколькими сеньорами в разных частях сервиса (реализация модели, архитектура, планирование запросов, управление хранилищем и т. д.).
Продукт-менеджер / техлид
Это разделение менее распространено. ПМ должны действовать как «мини-гендиректора» продуктовой области с довольно широкой автономией для работы в этой области. Поскольку эта роль включает множество компетенций, им не нужно быть такими же технически подкованными, как обычному ИМ.
Это сработает, если у ПМ и ТЛ каждой команды крепкие рабочие отношения, так что они могут эффективно общаться о таких вещах, как компромиссы между скоростью и техническим качеством, а не просто делать, как хочет ПМ.
Менеджер по персоналу/руководитель исследований
В этом разделении, в отличие от разделения ИМ/ТЛ в инженерной команде, разумнее, чтобы руководитель исследования отвечал за общее направление, поскольку оно в значительной степени зависит от высококонтекстных интуитивных суждений о том, в каком направлении исследования следовать. Во многих (хотя и не во всех!) инженерных командах приоритеты в меньшей степени зависят от такого рода высокотехнических суждений.
Это интересно как пример настройки, в которой менеджер по персоналу не отвечает (в первую очередь) за общее направление. Это в некоторой степени аналогично разделению технического директора и вице-президента по инжинирингу в некоторых технологических компаниях, где технический директор отвечает за общее руководство, но большая часть ответственности за руководство людьми лежит на вице-президенте по инженерным разработкам, который ему подчиняется.
Источник: https://www.benkuhn.net/leadcats/
👍2
День 2074. #Карьера
Упрощатели Заходят Далеко, Усложнятели Застревают
«Если вы не можете объяснить это шестилетнему ребенку, вы сами этого не понимаете».
– Альберт Эйнштейн
В бизнесе есть два типа людей:
1. Упрощатели - делают сложные вещи простыми.
2. Усложнятели - делают простые вещи сложными.
Короткая шутка
- Как усложнятель называет упрощателя?
- Босс.
Где-то, когда-то некоторые люди решили, что в бизнесе нужно все усложнять и говорить на деловом жаргоне.
«Что ж, это интересное предложение, и я не обязательно против него, поэтому позвольте мне поднять его на флагшток, чтобы мы могли побить его палками, как пиньяту. Поскольку я слышал, что эта идея имеет некоторую поддержку в этой области, позвольте мне связаться с ребятами наверху, и мы посмотрим, хватит ли у нас ресурсов, чтобы продолжить работу над этим. Если стоимость выше $100 тыс., мне, возможно, придётся отложить эту идею, потому что нам нужно сохранить немного сухого пороха в ожидании результатов стратегической встречи — где, как я знаю, мы рассматриваем серьёзные изменения. Так что давайте оставаться на связи. Честь и хвала команде за то, что они придумали такое отличное ценностное предложение, но сейчас, боюсь, не могу его принять.»
Это один из способов спрятаться за сложностью: сделать себя совершенно непонятным. Хотя это может произвести впечатление на кого-то, ваши подчинённые будут высмеивать вас, а ваши начальники захотят поговорить с кем-то другим. При общении с руководителями нужно говорить чётко и, прежде всего, отвечать на вопросы. В большинстве организаций, хотя жаргон и двусмысленность могут быть распространены среди менеджеров среднего звена, они почти отсутствуют среди руководителей.
Другой способ спрятаться за сложностью — не лингвистический, а концептуальный: всегда находить проблему вышестоящего уровня или более масштабную проблему, которая будет блокировать прогресс на нижнем уровне. Рассмотрим такое утверждение:
«Я хотел бы перейти на новый процесс, но мы ещё не завершили обучение.»
Является ли это веской причиной для отсутствия прогресса в переходе на новый процесс или это пассивное сопротивление, замаскированное под причину? Например, я не хочу переходить на новый процесс, поэтому у меня постоянно «возникают проблемы» с планированием обучения. Или это добросовестное усложнение? Если обучение можно свести к одной странице, которую каждый может прочитать за 5 минут, то просто сократите его.
Есть старая поговорка:
«Когда вы спрашиваете время, некоторые люди скажут вам, как собрать часы. Другие расскажут вам, как построить целую швейцарскую деревню.»
Тест на выявление усложнятелей — это поиск следующих паттернов поведения:
- Медленный прогресс в достижении результатов
- Ссылки на сложность или запутанность
- Тенденция находить искусственные предварительные условия и осложнения, которые кажутся правдоподобными, но при дальнейшем рассмотрении таковыми не являются.
Вещи настолько сложны, насколько мы хотим их сделать. В большинстве случаев сложность — это оправдание либо нежелания что-то делать, либо незнания, как что-то делать.
Стремитесь делать вещи простыми. Стремитесь понять их. Боритесь за то, чтобы найти для них подходящие метафоры. Если вы не тратите энергию, пытаясь упростить вещи для своей аудитории, вы больше всего похожи на усложнятеля. Если так, то в следующий раз, когда вы соберётесь объяснить кому-то, почему что-то занимает так много времени, является таким сложным или требует выполнения 5 шагов перед началом, спросите себя: «Действительно ли я в это верю или я все усложняю, потому что либо не хочу, либо не знаю, как это сделать?»
Источник: https://kellblog.com/2015/05/13/career-advice-simplifiers-go-far-complexifiers-get-stuck/
Упрощатели Заходят Далеко, Усложнятели Застревают
«Если вы не можете объяснить это шестилетнему ребенку, вы сами этого не понимаете».
– Альберт Эйнштейн
В бизнесе есть два типа людей:
1. Упрощатели - делают сложные вещи простыми.
2. Усложнятели - делают простые вещи сложными.
Короткая шутка
- Как усложнятель называет упрощателя?
- Босс.
Где-то, когда-то некоторые люди решили, что в бизнесе нужно все усложнять и говорить на деловом жаргоне.
«Что ж, это интересное предложение, и я не обязательно против него, поэтому позвольте мне поднять его на флагшток, чтобы мы могли побить его палками, как пиньяту. Поскольку я слышал, что эта идея имеет некоторую поддержку в этой области, позвольте мне связаться с ребятами наверху, и мы посмотрим, хватит ли у нас ресурсов, чтобы продолжить работу над этим. Если стоимость выше $100 тыс., мне, возможно, придётся отложить эту идею, потому что нам нужно сохранить немного сухого пороха в ожидании результатов стратегической встречи — где, как я знаю, мы рассматриваем серьёзные изменения. Так что давайте оставаться на связи. Честь и хвала команде за то, что они придумали такое отличное ценностное предложение, но сейчас, боюсь, не могу его принять.»
Это один из способов спрятаться за сложностью: сделать себя совершенно непонятным. Хотя это может произвести впечатление на кого-то, ваши подчинённые будут высмеивать вас, а ваши начальники захотят поговорить с кем-то другим. При общении с руководителями нужно говорить чётко и, прежде всего, отвечать на вопросы. В большинстве организаций, хотя жаргон и двусмысленность могут быть распространены среди менеджеров среднего звена, они почти отсутствуют среди руководителей.
Другой способ спрятаться за сложностью — не лингвистический, а концептуальный: всегда находить проблему вышестоящего уровня или более масштабную проблему, которая будет блокировать прогресс на нижнем уровне. Рассмотрим такое утверждение:
«Я хотел бы перейти на новый процесс, но мы ещё не завершили обучение.»
Является ли это веской причиной для отсутствия прогресса в переходе на новый процесс или это пассивное сопротивление, замаскированное под причину? Например, я не хочу переходить на новый процесс, поэтому у меня постоянно «возникают проблемы» с планированием обучения. Или это добросовестное усложнение? Если обучение можно свести к одной странице, которую каждый может прочитать за 5 минут, то просто сократите его.
Есть старая поговорка:
«Когда вы спрашиваете время, некоторые люди скажут вам, как собрать часы. Другие расскажут вам, как построить целую швейцарскую деревню.»
Тест на выявление усложнятелей — это поиск следующих паттернов поведения:
- Медленный прогресс в достижении результатов
- Ссылки на сложность или запутанность
- Тенденция находить искусственные предварительные условия и осложнения, которые кажутся правдоподобными, но при дальнейшем рассмотрении таковыми не являются.
Вещи настолько сложны, насколько мы хотим их сделать. В большинстве случаев сложность — это оправдание либо нежелания что-то делать, либо незнания, как что-то делать.
Стремитесь делать вещи простыми. Стремитесь понять их. Боритесь за то, чтобы найти для них подходящие метафоры. Если вы не тратите энергию, пытаясь упростить вещи для своей аудитории, вы больше всего похожи на усложнятеля. Если так, то в следующий раз, когда вы соберётесь объяснить кому-то, почему что-то занимает так много времени, является таким сложным или требует выполнения 5 шагов перед началом, спросите себя: «Действительно ли я в это верю или я все усложняю, потому что либо не хочу, либо не знаю, как это сделать?»
Источник: https://kellblog.com/2015/05/13/career-advice-simplifiers-go-far-complexifiers-get-stuck/
👍13
День 2145. #Карьера
Метрика Улучшения
В аэропорту при проходе через службу безопасности можно наблюдать интересный момент. Используем эту аналогию, чтобы поразмышлять о том, что люди делают с кодом.
Вы складываете вещи в контейнеры, отправляете их по ленте, и проходите через рамку. Дальше все стоят и ждут свои вещи. Телефонов в руках нет, поэтому их ничто не отвлекает. Контейнеры приезжают по ленте, и люди забирают свои вещи. И часто нет специально выделенного человека, который бы убирал контейнеры. Так можно выделить несколько групп людей.
Группа A
Большинство берут свои вещи, но оставляют контейнеры на ленте, по сути, создавая кучу пустых контейнеров, что в итоге заставляет кого-то другого убрать их с ленты, чтобы освободить место для своего контейнера. Эти люди выполнили свои задачи, но оставили технический долг для уборки другими.
Группа B
Другие берут свои вещи и снимают контейнер с ленты, приложив дополнительные усилия, чтобы не оставлять окружающую среду хуже, чем она была.
Группа C
Небольшая группа складывает все контейнеры и очищает ленту, но только когда лента заполнена, то есть они действуют так только для того, чтобы освободить место для своего контейнера.
Группа D
Наконец, несколько человек (меньшинство) используют своё время ожидания, чтобы улучшить систему для всех. Они убирают все оставшиеся контейнеры, чтобы очистить ленту, даже когда лента не заполнена.
Одной из метрик оценки качества программиста, которую можно использовать, является «Улучшение» (Betterment). Может ли программист определять области для улучшения и делает ли он их лучше без подсказок?
Некоторым может быть сложно представить, как они могут улучшить работу. Этот небольшой пример служит отличной аналогией для применения показателя улучшения.
Группа A: ниже ожиданий
Эта группа сосредоточилась только на достижении собственных целей, непреднамеренно ухудшая систему, оставляя больше работы другим.
Группа B: соответствуют ожиданиям
Эта группа не только сосредоточилась на своих целях, но и позаботилась о том, чтобы оставить систему нетронутой.
Группа C: соответствуют ожиданиям
Хотя эта группа действительно улучшила систему, их усилия были ситуативными и реактивными, и происходили только тогда, когда препятствие мешало им достичь своей цели.
Группа D: превышают ожидания
Эта группа последовательно действовала, чтобы очистить ленту и улучшить систему, обеспечивая бесперебойную работу для всех, даже когда это не было их работой или напрямую не влияло на них.
Будь то проход через службу безопасности в аэропорту или ваша кодовая база, вопрос в том, к какой группе вы хотите принадлежать?
Источник: https://angiejones.tech/the-betterment-metric/
Метрика Улучшения
В аэропорту при проходе через службу безопасности можно наблюдать интересный момент. Используем эту аналогию, чтобы поразмышлять о том, что люди делают с кодом.
Вы складываете вещи в контейнеры, отправляете их по ленте, и проходите через рамку. Дальше все стоят и ждут свои вещи. Телефонов в руках нет, поэтому их ничто не отвлекает. Контейнеры приезжают по ленте, и люди забирают свои вещи. И часто нет специально выделенного человека, который бы убирал контейнеры. Так можно выделить несколько групп людей.
Группа A
Большинство берут свои вещи, но оставляют контейнеры на ленте, по сути, создавая кучу пустых контейнеров, что в итоге заставляет кого-то другого убрать их с ленты, чтобы освободить место для своего контейнера. Эти люди выполнили свои задачи, но оставили технический долг для уборки другими.
Группа B
Другие берут свои вещи и снимают контейнер с ленты, приложив дополнительные усилия, чтобы не оставлять окружающую среду хуже, чем она была.
Группа C
Небольшая группа складывает все контейнеры и очищает ленту, но только когда лента заполнена, то есть они действуют так только для того, чтобы освободить место для своего контейнера.
Группа D
Наконец, несколько человек (меньшинство) используют своё время ожидания, чтобы улучшить систему для всех. Они убирают все оставшиеся контейнеры, чтобы очистить ленту, даже когда лента не заполнена.
Одной из метрик оценки качества программиста, которую можно использовать, является «Улучшение» (Betterment). Может ли программист определять области для улучшения и делает ли он их лучше без подсказок?
Некоторым может быть сложно представить, как они могут улучшить работу. Этот небольшой пример служит отличной аналогией для применения показателя улучшения.
Группа A: ниже ожиданий
Эта группа сосредоточилась только на достижении собственных целей, непреднамеренно ухудшая систему, оставляя больше работы другим.
Группа B: соответствуют ожиданиям
Эта группа не только сосредоточилась на своих целях, но и позаботилась о том, чтобы оставить систему нетронутой.
Группа C: соответствуют ожиданиям
Хотя эта группа действительно улучшила систему, их усилия были ситуативными и реактивными, и происходили только тогда, когда препятствие мешало им достичь своей цели.
Группа D: превышают ожидания
Эта группа последовательно действовала, чтобы очистить ленту и улучшить систему, обеспечивая бесперебойную работу для всех, даже когда это не было их работой или напрямую не влияло на них.
Будь то проход через службу безопасности в аэропорту или ваша кодовая база, вопрос в том, к какой группе вы хотите принадлежать?
Источник: https://angiejones.tech/the-betterment-metric/
👍12
День 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