И может проверить их уровни сопротивления и толерантности

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

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

Итак, вот главные вещи, которые могут свести программиста с ума.

Пустой или отсутствующий файл README

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

«Не приносите мне проект, в котором нет даже надлежащего README. Я не могу принять это усилие».

Он быстро встал со стула и ушел с собрания.

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

Нет решения при переполнении стека

Это полный облом.

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

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

Встречи

Позвольте мне прояснить: инженеры ненавидят совещания. По крайней мере, большинство из них.

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

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

Бесполезные сообщения об ошибках

Представьте, что код, который вы просматриваете, не работает с этим сообщением об ошибке. Нет трассировки стека, нет правильного обмена сообщениями.

Это обязательно сведет с ума любого инженера.

Если вы хотите повеселиться, вот несколько нелепых сообщений об ошибках Windows.

Нулевые тестовые случаи

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

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

Должен ли я сначала исправить ошибку?

Должен ли я просто писать тестовые примеры для этого кода?

Должен ли я писать тестовые примеры для всего кода?

Их проблемы теперь ваши проблемы.

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

Изменение требований в середине процесса разработки проекта

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

Можем ли мы это сделать?

Как насчет того, чтобы вывести этот поток наружу?

Можем ли мы добавить эту функцию?

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

Жестко запрограммированные значения

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

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

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

Переключение контекста каждые несколько часов

Можете ли вы внести это небольшое изменение?

Вы можете присоединиться к этой встрече?

Не могли бы вы быстро составить это письмо?

Можете ли вы сделать презентацию того, что вы делаете?

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

Задайте им еще один вопрос, и они могут лопнуть, как воздушный шарик.

Будучи инженером с более чем 15-летним стажем, это главные вещи, которые иногда сводили меня с ума. Если есть что-то, что я пропустил, не стесняйтесь поделиться этим.