Статьи

12 самых страшных страхов разработчиков на Хэллоуин

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

Они идут в Гитчу!

1. Оценка отвращения

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

Оценка ухудшается наивными менеджерами проектов, которые связывают вас с этими цифрами. Напомните им, что оценки называются «оценками» по причине.

2. Подозрительные графики

Проекты должны иметь четко определенные цели и сроки, иначе они могут дрейфовать вечно. Ничто не может считаться «полным», но цели должны быть достижимыми, а сроки — реалистичными. Даже тогда будьте готовы к проскальзыванию, потому что что-то идет не так, и невозможно предвидеть все проблемы.

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

3. Сфера ползет

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

Вы определенно умрете

4. Тремор инструмента

Есть одна вещь хуже, чем отсутствие правильных инструментов для работы: быть вынужденным использовать инструмент, который вы ненавидите. Возможно, вы являетесь разработчиком PHP и переходите на Java. Или эксперт Gulp вынужден использовать Grunt. Или пользователь Atom обязан использовать Eclipse.

Будьте прагматичны и применяйте процедуры и процессы, используемые другими членами вашей команды (если вы не можете убедить их в том, что миграция в другое место является экономически эффективной). Но необходимость использовать случайный инструмент или редактор, потому что «это то, что мы используем здесь» , разрушает душу. Решение? Не скулите и используйте все, что вам нужно. Проще просить прощения, чем просить разрешения — и немногие будут жаловаться, если вы сделаете свою работу.

5. Нетехнические проблемы коллег

Вы боитесь, что некоторые люди приходят в офис? Они могут быть очень приятными людьми, но становится утомительным, когда им приходится объяснять одни и те же технические проблемы каждый раз, когда они посещают. Они захотят узнать, почему IE8 не показывает закругленные углы, почему приложение выглядит по-разному на их древней Blackberry, почему их ноутбук работает медленно, почему электронная почта не работает в 22:52, почему их история просмотра видна и как кто-то получил доступ к своей учетной записи Facebook.

Они не будут расследовать себя. Они не будут Google. Они будут использовать вас: их неофициальная поддержка ИТ-службы. Есть несколько вариантов для рассмотрения. Вы могли бы выставить счет за их время? Или спрятаться.

6. Разочарованный дизайнерский испуг

Возможно, хуже, чем нетехнические коллеги, те, кто «смотрит на UX». Те, кто делают это заявление, неизменно никогда не имеют этих навыков, но это не остановит их, предлагая несерьезные изменения интерфейса. Давайте переместим эту кнопку на два пикселя вправо? Давайте переключимся на фиолетовый — это модный цвет. Давайте сделаем это поп.

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

Вы просто не можете убежать

7. «Просто» Дрожь

Бойтесь слова «просто» . Он используется для того, чтобы предложения звучали просто, в то же время вводя ошеломляюще сложные функции, требующие десятилетия интенсивных исследований, например

  • «Просто сделайте поиск в свободном тексте лучше».
  • «Просто представьте себе искусственный интеллект».
  • «Просто позволяйте пользователям общаться с приложением».

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

8. «Это не займет много времени»

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

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

9. Поддержка борьбы

Исправлять ошибки легко. Трудно понять, в чем проблема, когда сталкиваешься с типичными жалобами, такими как «это не работает» . Пользователи будут предполагать, что вы мистическая сущность, которая знает, какую ОС они используют, какое программное обеспечение они установили, какие функции они использовали и как выглядел их экран, когда у них была проблема три недели назад.

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

Вы собираетесь проиграть

10. Черт возьми

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

11. Бремя скуки

Мы все хотим работать над классными вещами. Мы все хотим оставаться заинтересованными. Мы все хотим изменить ситуацию. Но это не имеет значения, что вы делаете; скука влияет на всех, независимо от их роли. Тем не менее, если вы провели последние 25 лет, работая над проектом налоговой оценки на основе COBOL, возможно, пришло время изменить направление. Вы знаете, что вас сдерживает …

12. Беспокойство Неизвестного

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

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

Я пропустил ваши самые неприятные ужасы? Какие кошмары вы пережили?