Я могу повторить еще раз: я таких никогда не видел.
Эффект избирательности. Даже если увидите — не поверите, будете думать что человек мухлюет :)
Почитайте статью, посмотрите обсуждение. Сколько в среднем в день ваши коллеги решают задач (посмотрите выписку из 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-меню а купить готовое. Я однажды пришел к выводу, что делать контрол под проект — практически всегда плохая идея. Хорошее меню — уже отдельный проект на несколько месяцев работы.
На мой взгляд, при минимальном планировании, такие вещи как меню изменяются не часто. Предварительно нужно продумать все «за» и «против», сделать прототип, оценить…
Так что в данной ситуации, похоже, конкуренты имеют преимущество.
У конкурентов начинается срач между ведущими, которым жалко менять спроектированное меню и две недели крутого правильного программирования, плюс у них замылен глаз. В итоге мы получили две недели времени.
А что было бы, если бы в этой конкретной ситуации трехуровневое меню оказалось правильным выбором?
Конкуренты экономят уйму времени, т.к. их меню обновлялется автоматически. А вы бы тратили драгоценное время своих программистов на «Вась, а ну добавь как еще один подпункт для сковородок...». И ведь признайтесь — раз оно работает, то лень было бы делать правильную архитектуру, вроде проще руками добавить пару пунктов…
Если уж Вы следуете каким-то принципам, то следуйте им с самого начала, не думая, что по первости можно и без них обойтись
А разве я не об этом написал? Некоторые сразу делают качественно (TDD — это признак качественной работы). Другие же стремятся сделать чем быстрее и дешевле, не взирая на качество.
Кто прав а кто нет — вопрос не однозначный. Строго говоря, не всем людям нужно качество. Кто-то любит дорогую и качественную обувь, которую комфортно носить (за $300-500), а кто-то дороже $20-50 ничего в жизни не обувал. И что лучше: делать качественную обувь или ширпотреб?
2 диаметрально противоположных мнения по данному вопросу:
1. Одна группа громко доказывает, мол нужно писать как можно быстрее без учета качества. А уж потом, когда проект взлетит, наймете того лоха, который оказался в жопе, пока вылизывал свой код.
2. Мысли второй группы изложены в статье.
Хотелось бы конкретики, а именно исследования реальных стартапов, как они делались.
Эффект избирательности. Даже если увидите — не поверите, будете думать что человек мухлюет :)
Почитайте статью, посмотрите обсуждение. Сколько в среднем в день ваши коллеги решают задач (посмотрите выписку из 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-меню а купить готовое. Я однажды пришел к выводу, что делать контрол под проект — практически всегда плохая идея. Хорошее меню — уже отдельный проект на несколько месяцев работы.
Так что в данной ситуации, похоже, конкуренты имеют преимущество.
А что было бы, если бы в этой конкретной ситуации трехуровневое меню оказалось правильным выбором?
Конкуренты экономят уйму времени, т.к. их меню обновлялется автоматически. А вы бы тратили драгоценное время своих программистов на «Вась, а ну добавь как еще один подпункт для сковородок...». И ведь признайтесь — раз оно работает, то лень было бы делать правильную архитектуру, вроде проще руками добавить пару пунктов…
А разве я не об этом написал? Некоторые сразу делают качественно (TDD — это признак качественной работы). Другие же стремятся сделать чем быстрее и дешевле, не взирая на качество.
Кто прав а кто нет — вопрос не однозначный. Строго говоря, не всем людям нужно качество. Кто-то любит дорогую и качественную обувь, которую комфортно носить (за $300-500), а кто-то дороже $20-50 ничего в жизни не обувал. И что лучше: делать качественную обувь или ширпотреб?
1. Одна группа громко доказывает, мол нужно писать как можно быстрее без учета качества. А уж потом, когда проект взлетит, наймете того лоха, который оказался в жопе, пока вылизывал свой код.
2. Мысли второй группы изложены в статье.
Хотелось бы конкретики, а именно исследования реальных стартапов, как они делались.