Что может замедлить разработчика? [закрыто]

12

Какие вещи имеют тенденцию замедлять разработчика?

Пожалуйста, постарайтесь не публиковать ответы, которые:

productivity  organization 
— Том Вейсман
источник
@ Марк Трапп: Да ?! Это совсем не дубликат ...: -S
— Тамара Вийсман
1
Если вопрос окажется бесполезным, я удалю его в ближайшем будущем, люди перечисляют отвлекающие факторы, которые уже покрыты другим вопросом от меня. Так что я склонен искать не отвлекающие вещи ... TheLQ и Билл - хороший пример ответов.
— Тамара Вийсман
Решено оставить вопрос открытым, потому что речь идет о вещах, которые не отвлекают ...
— Тамара Вийсман
11
Stackoverflow, SuperUser, программисты ... да, в основном такие сайты :)
— bedwyr 22.10.10

Ответы:

49

О, это легко:

  1. Встречи
  2. Больше встреч
  3. Встречи о последней встрече
  4. Встречи для подготовки к предстоящей встрече
  5. Разработка презентации Power Point для встречи
  6. Разработка презентации Power Point для встречи, обсуждающей функции, которые не были реализованы, не должна быть реализована, и по какой-то причине этот парень из отдела продаж будет прыгать повсюду. Я не могу предсказать, какой документ вы хотите отобразить в приложении, исходя из вашего текущего местоположения без подключения к интернету или доступа к вашему жесткому диску. Нет, просто перестань просить об этом тоже.
— Wheaties
источник
4
короче говоря: управление? ; o)
— n1ckp
11
@ n1ck Нет, нет. Хорошее управление может ускорить разработку. Плохое планирование времени программиста (то есть один аспект того, чтобы быть менеджером) может действительно замедлить развитие.
— пшеница
3
Что убивает меня, так это когда моя компания делает это: встречи, дополнительные встречи, встречи о последней встрече, встреча, чтобы подготовиться, встреча, чтобы обсудить, почему мы ничего не можем достичь. Почему мы не можем ничего достичь? У вас есть сорок разработчиков, сидящих в комнате и слушающих вас !!
— Майк М.
2
Обратите внимание, что этот ответ почти поместится на слайде Powerpoint.
44

Медленный компьютер

— оборота TheLQ
источник
Та же проблема здесь
— pramodc84
1
Я бы купил себе ноутбук как можно скорее и поработал бы над этим, если бы оказался в такой ситуации, предполагая, что компания это разрешит.
— Адамк
Медленные компьютеры, как правило, являются основной причиной отвлечения внимания. Каждый раз, когда программист ждет, они могут войти в режим отвлечения и не вернутся в программу, пока через некоторое время.
— edA-qa mort-ora-y
Они заменили мой компьютер пару недель назад. Он менее мощный, чем 4-летний, который он заменяет. Ницца.
— MetalMikester
25

StackOverflow, programmers.stackexchange.com и т. Д. :)

— Райан Ринальди
источник
4
Не согласен! StackOverflow помогает решать проблемы, что ускоряет разработку!
— Волшебник
3
Обидная глупость. За каждую минуту, которую я «потратил» на SO, она выкупала меня обратно 20.
— МВД
11
+1. совсем не обидно. Так что это очень хорошо для промедления. Это мой новый фейсбук. :)
— back2dos
@ back2dos Пожалуйста, не сравнивайте удивительность SO с куском ... это Facebook.
— Адамк
15

Любая попытка следовать процессу, который не подходит для поставленной задачи.

Это могут быть самые разные вещи, но я вижу такие общие:

  • методики тестирования, которые не соответствуют тестируемому коду
  • процессы, которые являются значительно более гибкими или традиционными, чем результат поставки (ий)
  • рекомендации, предназначенные для набора инструментов, отличного от выбранного набора инструментов
  • принципы проектирования, которые не соответствуют потребностям проекта
  • используя набор инструментов, который не подходит для задачи

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

— Билл
источник
13

Политика

Например: когда требования принадлежат более чем одному человеку (или, что еще хуже, двум разным корпоративным интересам), и они вносят конкурирующие и противоречивые изменения в требования во время разработки.

— Крис Бакетт
источник
9

Беседы других

и шум в целом

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

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

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

Непосредственный и очевидный ответ « Разве вы не можете просто получить наушники с шумоподавлением» не помогает, когда вы хотите молчать.

Иногда для проверки кода я беру свою стопку бумаг в столовую (конечно, не во время обеда), но там есть телевизор, который обычно гремит. Я выключу, если никто не смотрит. В противном случае я пойду найду пустой куб в другом отделе в другой части здания.

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

— Энди Лестер
источник
Иногда там становится слишком тихо, где я нахожусь. Я начинаю фокусироваться на щелчках мышью у всех и людях, тяжело дышащих и т. Д. Это все равно, что лежать в кровати и слышать крикет.
— kirk.burleson
8

Написание слишком большого количества строк кода без адекватных тестов.

— Fortyrunner
источник
Это причина номер один в моем опыте.
— Паддислакер
1
@Paddyslacker: больше тестов = более продуктивно? А? Только для людей, которые не должны быть в программировании в первую очередь. Испытание может быть полезным, но "причина номер один вещей останавливается"? Ты серьезно?
— n1ckp
1
@ n1ck: Да, я серьезно. Код переходит в не поддерживаемое состояние, а отсутствие тестов и тестируемости базы кода означает, что каждую новую функцию становится все труднее добавлять. Я нахожу забавным, что вы думаете, что люди, которые пишут больше тестов, «не должны в первую очередь заниматься программированием». Значит, Рой Ошеров, Майкл Фезерс, дядя Боб, Кент Бек и т.д. не должны быть в программировании?
— паддислакер
@Paddyslacker: я не знаю. Никогда не видел их код. Может быть, они должны быть лучше в управлении из вашего описания? И почему код становится не поддерживаемым именно из-за отсутствия теста? Тест может сделать плохой код великим с помощью какой-то магии, может быть?
— n1ckp
1
@ n1ck, тесты не окупаются при написании кода на начальном этапе, но имеют огромное значение при необходимости поддерживать код позже.
5

Отсутствие качественного кофе.

— Роберт Харви
источник
Или нехватка хорошей газировки. Я скучаю так много без кофеина диеты вишневого кокса! В моей стране я могу получить только диетическую колу или кокс без кофеина, а не вишневый кокс вообще :-(
— Wizard
1
@Wizard - я работаю в компании, которая поставляет Diet Cherry Coke. Не уверен, почему я ушел. Если чувствую твою боль.
— Джефф
2
@Wizard: просто купите банку с вишней мараскино и добавьте немного сиропа в свой напиток. Теперь вы можете сделать его настолько сильным, насколько захотите ... (тот же трюк для ванили: настоящий ванильный кокс намного превосходит предварительно смешанный материал)
— Shog9
@Г-н. C: Проблема в том, что мне нужна диета + кофе без кофеина, комбинация, которой нет в моей стране.
— Волшебник
5

делать точные оценки, которые нельзя отклонять от начала разработки, на мой взгляд, это сценарий с куриным яйцом

— MetaGuru
источник
Если вы часто сталкиваетесь с этим, я бы посоветовал потратить некоторое нетривиальное время на изучение оценки. Затем вы можете ответить: «Если это оценка, то, по определению, это не количество времени, которое потребуется».
— МВД
о, я использовал это раньше, ответом всегда является то, что я плохо оцениваю, если его нельзя разбить на видимые 2-4-часовые задачи, то, очевидно, я делаю это неправильно
— MetaGuru
5

Исправление чужой сломанной сборки

— rwong
источник
звучит так, будто кто-то плохо воспитывает своего коллегу.
— Отображаемое имя
@ bold: это может произойти естественным образом из-за асинхронности. Допустим, ежедневное время завершения сборки - 5 часов утра, а последняя версия - в 9 часов утра. (Другими словами, вы не можете помешать людям рано приходить на работу.)
— rwong
4

Встречи без повестки дня.

Медленная машина.

Отсутствие второго монитора.

Старая мышь, у которой вместо хороших новых шариков.

Отсутствие доступа к Интернету на компьютере, что делает запрос MSDN / stackoverflow / etc немного болезненным.

— ist_lion
источник
Связанный с не повесткой дня встречи угонщик встречи. Вы знаете ... вы помещаете это в календарь на час, но даже если тема будет закрыта за 20 минут, есть тот парень, который продолжает искать другие темы, чтобы заполнить эти 20 минут. Я бы вас голосовал, но потом мне пришлось бы понизить голосование за «отсутствие второго монитора» в качестве замедления. Это удобно, но отсутствие этого иногда не замедляло меня.
— МВД
4

Потратил слишком много времени на программирование

Даже если вам действительно нравится программирование, потраченное на него слишком много времени, в конечном итоге, обожжет вас

— нанда
источник
4

Избегайте всего, что выводит вас из «зоны». Это означает ваш почтовый ящик, всплывающее приложение в Твиттере, корпоративный чат и т. Д.

Наличие тихого рабочего состояния означает также и отсутствие шума на рабочем столе .

— оборота GmonC
источник
3

Любой запрос на изменение, который было бы проще реализовать, если бы вы знали об этом заранее.

— JeffO
источник
«Ходить по воде и разрабатывать программное обеспечение по спецификации легко, если оба они заморожены»
— back2dos
1
Глупая цитата. Ходить по льду не всегда легко.
— Питер Боутон
1
@Peter Boughton: Если мы выберем масштаб, в котором разработка программного обеспечения на основе изменяющихся спецификаций затруднена, а на замороженных - легка, то ходить по льду всегда легко. Вы можете научить 6 лет делать это. Но я полагаю, вы знаете, что вы просто получаете удовольствие от умных задниц.
— back2dos
И вы можете научить шестилетнего ребенка работать с изменяющимися характеристиками. Это не умная оценка, это раздражение от чрезмерного использования таких цитат, которые не помогают. Замороженные спецификации нелегко разработать, если они ошибочны (поскольку они не могут быть исправлены), и изменение спецификаций хорошо, если вы заранее знаете, какие детали находятся в движении (как вы можете обойти это).
— Питер Боутон
3

Плохой код

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

— n1ckp
источник
2

Многое, что замедляет вас - это хороший пост в блоге.

...

Многие проекты повторяют основные функции уровня инфраструктуры снова и снова, замедляя этот бизнес в предоставлении функций, которые отличают бизнес от его конкурентов.

...

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

...

— Тамара Вийсман
источник
+1: отличный ответ. Я ушел с работы, потому что компания не хотела выделять время для сокращения технического долга. Разработчики были вынуждены «повторять основные функции уровня инфраструктуры снова и снова».
— Джим Г.
2

Ну, в последнее время самое большое замедление связано с тем, что мы разрабатываем несколько вещей одновременно, которые должны были быть выполнены в определенном порядке. Поэтому я жду, пока (имена не изменятся, чтобы защитить невинных) Джон заканчивает работу над своим компонентом, который мне нужен для моего пакета служб SSIS, и Гарри замедляется, ожидая, пока я импортирую записи, потому что ему нужны некоторые данные, чтобы проверить его экспорт (когда-либо пытаться написать сложный отчет об экспорте, когда нет данных ни в одной из таблиц?) и все замедляются, потому что проектирование еще не завершено, а таблицы базы данных, которые нам нужны для выполнения наших задач, еще не созданы и могут даже не закончиться до того, что они сказали, что они будут и т.д.

— HLGEM
источник
1
Похоже, вы говорите о узких местах, вызванных слишком тонким распределением работы между членами команды.
— МВД
1
Дело не в том, что команда разбросана тонко, но руководство не задумывалось о зависимостях при назначении проектов. И кое-что, что, как предполагалось, было готово в тот момент, когда другой человек получил назначение в проект, не было, как только люди пытались их реально использовать.
— HLGEM
2

Отвечая на вопросы на stackexchange.com, как этот.

— tactoth
источник
Тогда вы можете улучшить свои навыки набора текста.
2

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

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

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

— user6061
источник
2
  • Необходимо подождать около 15 минут, чтобы компьютер загрузился в работоспособное состояние
  • В ожидании ПК для переключения приложений
  • Быть единственным человеком в офисе, который должен сделать свой собственный чай / кофе.
  • Сломанная клавиатура (исправлено!)
  • Работа вне офиса управляющего директора (главного исполнительного директора США) (и не в офисе тоже), с промежуточным разделением (особенно, когда есть встреча)
  • Босс доступен только по электронной почте, но все остальные находятся в здании
  • Не разрешено использовать VCS - очевидно, это должно быть в моем мозгу
  • Маленький экран
  • Не позволяет время для перерывов, кроме обеда
  • Необходимость делать резервные копии удаленного сервера, несмотря на наличие системного администратора в здании
  • Приказано делать резервные копии вручную.
  • Быть вынужденным использовать глупую систему управления временем, которая излишне сложна
  • Только получить смутное представление о требованиях два месяца в работе

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

— Алан Пирс
источник
Похоже, вам нужно выбраться оттуда!
— Адамк
2
  • Отсутствие документации (система, компания и т. Д.)
  • Отсутствие прокомментированного кода
  • Неполное понимание системы
  • Политика (т.е. ненужные встречи, оформление документов, препятствия со стороны руководства ...)
  • Неполная документация требований
  • Facebook!
  • Слишком много спать?
— soran awla
источник
1

Слишком много людей в проекте.

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

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

— MIA
источник
0

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

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

— Илья К.
источник
0

  • Чрезмерное оформление документов

  • Наличие зависимости от кого-то, кого никогда нет рядом (например, от вашего босса - если вам нужно задать вопрос, но он всегда на собраниях)

  • Неадекватные инструменты и оборудование.

  • Люди без толку вбивают весло (любое видимое для пользовательского интерфейса изменение подвержено этому) или просто спорят о тривиальных вещах.

  • Сломанная кофемашина

  • Быть назначенным неправильные задачи

— JohnL
источник
0

Кондиционер не работает.

Таким образом, температура в офисе достигает 40 градусов летом, -5 зимой.

-5 не подходит для печати, так как я не могу носить перчатки и печатать. 40, просто замедляет мое мышление.

— Mumbles
источник
0

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

Однако я часто вижу, как программисты пытаются набросать хороший дизайн перед тем, как начать писать код. Я обнаружил, что легче "начать работу", так как во время программирования вы узнаете больше о своей проблеме и решении, что позволит вам быстро преобразовать свое решение в хороший дизайн. Большинство возникающих проблем практически неизвестны в начале написания кода (по крайней мере, на мой взгляд), поэтому тратить много времени на предварительный дизайн - просто трата времени.

По этой же причине мне не нравится TDD, вы тратите слишком много времени на написание тестов, что делает вас либо менее склонными к рефакторингу, либо отнимает много времени, чтобы переписать тесты. Модульные тесты отлично подходят для некоторых случаев и некоторых этапов проекта, но начало одного из них не является одним из них ИМХО :)

Получите что-то работающее быстро и улучшите это.

— Homde
источник
-1 Я понимаю ваше мышление, но смысл этапа проектирования - ограничить необходимость рефакторинга. Это также облегчает модульное тестирование, которое постоянно помогает убедиться, что что-то работающее не сломано и не выпущено. Если вы не планируете, вы все усложните другим, когда им придется постараться сохранить то, что неизбежно будет плохо структурированным кодом.
— Adamk
Кто сказал, что это будет плохо с архитектурой? Я просто говорю, что вы не хотите чрезмерной фазы проектирования и вам нужно много реорганизовать и реструктурировать во время проекта, чтобы получить качественный код. С другой стороны, чтобы это работало, у вас должны быть четко разграниченные обязанности по коду, когда разные люди не копаются в коде друг друга.
— Homde
Опыт говорит, что у него плохая архитектура. Полеты на сиденьях у штанов и ковбойские кодировки - это, вероятно, худшие вещи, которые вы можете сделать во время разработки. Фаза разработки, которая продлится неделю, сэкономит вам месяцы программирования и приведет к коду, который делает то, что предполагалось в первый раз. Идея TDD в том, что вы не меняете тесты. Эти тесты предназначены для имитации практического использования, и если ваш код не может завершить тест, значит, ваш код неправильный.
— Майк С
Мой опыт говорит об обратном, но я думаю, это зависит от ковбоя и команды :) Я узнал больше за одну неделю программирования и сделал некоторый код, чтобы показать это. Конечно, у вас будет плохая архитектура, если вы не будете проводить экстремальный и непрерывный рефакторинг и у вас будет достаточно гибкая команда / ковбой, чтобы не отставать. Думать, что вы можете сделать «фазу проектирования», выучить все и сделать все правильно с первого раза, просто наивно. Истинная ценность прототипа - те уроки, которые вы выучите, вы выбросите их и сделаете это правильно. Делайте это несколько раз и быстро :)
— Homde
0

Блок программиста : в отличие от других замедлений, этот труднее решить.

— Darknight
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.