Здесь градация. Не да/нет, а множество оттенков. Кроме того, зависит от вашего отношения к новостям: если вы биржевый трейдер, то для вас это действительно не отдых.
рутинная работа («добавить строчку в меню»), ничем не отличается от чтения статей на хабре по нагрузке на мозг
Смотря что и как читать. Я сложные статьи отмечаю и читаю когда есть время на обдумывание.
А вот это как раз неверно. Потому что смена контекста-то происходит, просто вы отказываетесь ее признавать.
Почему же отказываюсь? Признаю.
Но в момент отдыха я могу продолжать думать о прерванном деле и решать проблемы в фоновом режиме. То есть когда сам прервал и не даю сильной нагрузки — процесс переходит в фоновый режим и затем быстро восстанавливается.
Я могу повторить еще раз: я таких никогда не видел.
Эффект избирательности. Даже если увидите — не поверите, будете думать что человек мухлюет :)
Почитайте статью, посмотрите обсуждение. Сколько в среднем в день ваши коллеги решают задач (посмотрите выписку из Jira). Везде увидите это магическое число 5-7, даже если задачи мелкие.
И не ставьте знак равенства между отвлечением на просмотр новостей/статей и выполнением работы.
Сочувствую вам. У меня переключений контекста в день десятки.
Просто имейте в виду: у многих людей переключение отнимает значительно больше времени. Если будете менеджерить — учитывайте эту особенность. И это вовсе не значит, что эти люди менее эффективны (может и наоборот — умеют копать глубоко).
А я и не утверждал, что одна минута. Но по факту, как раз в 15 минут можно уложить правку и смену контекста.
Утверждал s0rr0w. У него получилось 1 мин. + 9 мин. на переключение. А у вас 10 мин. + 5 мин. на переключение. У вас сшилком быстро происходит переключение контекста, у большниства программистов займет значительно больше 5 минут.
Я для себя вывел формулу: не более 5 переключений в день. Кстати, многие с кем обсуждал — согласились и даже приводили в подтверждение некие исследования.
А вообще — в пределах 15 минут, из которых 10 — это пречекин и деплой
Ну вот видите: 10 минут. Никак ни одна минута :)
По переключению контекста за 2.5 минуты — мне до вас далеко (у меня уйдет минут 20-30). Я пишу код в измененном состоянии сознания, в своего рода трансе. Могу и просто писать, но эффективность во много раз ниже.
Классическим решением является свой NuGet-репозиторий. При первом запуске происходит авторизация и скачиваются пакеты (с учетом всех зависимостей). Потеря 2-3 минут единоразово не критична.
Можно хранить пакеты и с исходным кодом — есть плюсы и минусы такого решения. В таком случае у вас уйдет больше времени на постоянное обновление папки с пакетами (в итоге может даже больше потеряете).
А вы NuGet используете только для внешних библиотек, или и для своих? У вас есть свой (внутренний) репозиторий-NuGet для пакетов, или храните их вместе с исходниками?
1. Я в эти 10 минут включил и смену потока. Скопировать одну строчку и поменять два значения в новой строчке не занимает более 1й минуты работы
Для правильных языков (.Net, Java) вы сначала достаете из репозитория нужну ветку (1-2 мин.), открываете проект в студии (до 5 мин, если большой проект), находите эту страницу, исправляете (1-2 мин.), компилите, запускаете, проверяте что все работает (до 5 мин.), коммитите изменения в репозиторий (1-2 мин.), деплоите новую версию на сервер (если вы имеете права — 1-2 мин., при этом сайт будет не доступен.).
Итого, для сайта на .Net (на Java будет то же самое) — от 14 до 18 минут только изменение, без учета смены контекста.
Вопрос, сколько изменений можно вносить руками, чтобы это наконец стало затратным? Ответ: 234
Два момента:
1. Это только кажется «10 минут». Вы отвлекаете программиста, выводите из контекста. Потом он пойдет пить кофе, т.к. не сможет сосредоточиться.
2. Хороший архитектор это не тот, кто делает сам каждый кирпичик. Вполне можно не клепать самим HTML-меню а купить готовое. Я однажды пришел к выводу, что делать контрол под проект — практически всегда плохая идея. Хорошее меню — уже отдельный проект на несколько месяцев работы.
На мой взгляд, при минимальном планировании, такие вещи как меню изменяются не часто. Предварительно нужно продумать все «за» и «против», сделать прототип, оценить…
Так что в данной ситуации, похоже, конкуренты имеют преимущество.
А почему вы считаете что оно ошибочно? Есть причина так считать?
Это нужно провести соц. опрос в среде программистов.
Ну… Психология не точная наука.
Какого доверия?
Мы ведь говорили о экономической целесообразности автоматизации ручного труда и о опасности недооценивания времени на переключение контекста.
Здесь градация. Не да/нет, а множество оттенков. Кроме того, зависит от вашего отношения к новостям: если вы биржевый трейдер, то для вас это действительно не отдых.
Смотря что и как читать. Я сложные статьи отмечаю и читаю когда есть время на обдумывание.
Почему же отказываюсь? Признаю.
Но в момент отдыха я могу продолжать думать о прерванном деле и решать проблемы в фоновом режиме. То есть когда сам прервал и не даю сильной нагрузки — процесс переходит в фоновый режим и затем быстро восстанавливается.
Эффект избирательности. Даже если увидите — не поверите, будете думать что человек мухлюет :)
Почитайте статью, посмотрите обсуждение. Сколько в среднем в день ваши коллеги решают задач (посмотрите выписку из Jira). Везде увидите это магическое число 5-7, даже если задачи мелкие.
И не ставьте знак равенства между отвлечением на просмотр новостей/статей и выполнением работы.
Зависит от работы. Если работа сложная — бывало и на несколько дней забывал про форумы и хабры. Скайп специально отключал.
А вот если что-либо нудное — то перерывы помогают не умереть от тоски.
В среднем случае (не очень сложная работа) неожиданное срочное задание минут 30 оттягивает.
Правильно.
Исключение можно сделать для механическай работы, которая не требует погружения и обдумывания.
Просто имейте в виду: у многих людей переключение отнимает значительно больше времени. Если будете менеджерить — учитывайте эту особенность. И это вовсе не значит, что эти люди менее эффективны (может и наоборот — умеют копать глубоко).
Утверждал s0rr0w. У него получилось 1 мин. + 9 мин. на переключение. А у вас 10 мин. + 5 мин. на переключение. У вас сшилком быстро происходит переключение контекста, у большниства программистов займет значительно больше 5 минут.
Я для себя вывел формулу: не более 5 переключений в день. Кстати, многие с кем обсуждал — согласились и даже приводили в подтверждение некие исследования.
Ну вот видите: 10 минут. Никак ни одна минута :)
По переключению контекста за 2.5 минуты — мне до вас далеко (у меня уйдет минут 20-30). Я пишу код в измененном состоянии сознания, в своего рода трансе. Могу и просто писать, но эффективность во много раз ниже.
Не жалуюсь, а констатирую факт: даже мелкое внезапное изменение старой версии (когда нужно лезть в репозиторий) отнимает больше минуты.
А вот в вашем проекте сколько времени уйдет на передеплой старой версии с мелким изменением и ручным тестированием?
Можно хранить пакеты и с исходным кодом — есть плюсы и минусы такого решения. В таком случае у вас уйдет больше времени на постоянное обновление папки с пакетами (в итоге может даже больше потеряете).
Ну а почему одни люди носят обувь за $300-500, а другие дороже $20-50 ничего в жизни не обували?
Это высший класс. Да, технологии дорогие, но есть люди, которые не гонятся за дешивизной. И мне приятнее работать с такими людьми.
Для правильных языков (.Net, Java) вы сначала достаете из репозитория нужну ветку (1-2 мин.), открываете проект в студии (до 5 мин, если большой проект), находите эту страницу, исправляете (1-2 мин.), компилите, запускаете, проверяте что все работает (до 5 мин.), коммитите изменения в репозиторий (1-2 мин.), деплоите новую версию на сервер (если вы имеете права — 1-2 мин., при этом сайт будет не доступен.).
Итого, для сайта на .Net (на Java будет то же самое) — от 14 до 18 минут только изменение, без учета смены контекста.
Два момента:
1. Это только кажется «10 минут». Вы отвлекаете программиста, выводите из контекста. Потом он пойдет пить кофе, т.к. не сможет сосредоточиться.
2. Хороший архитектор это не тот, кто делает сам каждый кирпичик. Вполне можно не клепать самим HTML-меню а купить готовое. Я однажды пришел к выводу, что делать контрол под проект — практически всегда плохая идея. Хорошее меню — уже отдельный проект на несколько месяцев работы.
Так что в данной ситуации, похоже, конкуренты имеют преимущество.