Дело не в том, что разработчики параноики, их действительно винят в этом

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

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

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

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

Лучше всего винить в этом разработчика, который покинул проект.

Ушедшие разработчики

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

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

Разработчики понимают, что создание программного обеспечения связано с ошибками, ошибками и проблемами.

Разработчик, который ушел, или кто-то может сказать сбежал, вступает в отношения любви / ненависти

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

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

Мне нравится думать, что ушедшие разработчики следуют тем же путем, что и Энди в Искуплении Шоушенка.

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

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

  • Клиент - Кто создал эту ошибку, это ужасно, кто угодно мог найти это, открыв страницу
  • Разработчик - должно быть, это Энди Дюфрен, разработчик, который ушел, он был ужасен

Другое обсуждение

  • Заказчик - Где отсутствует документация
  • Разработчик - Это было в списке дел Энди Дюфресна, должно быть, он ушел, не сделав этого.

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

Винить тестировщиков

Разработчики ненавидят тестировать свою собственную работу, потому что тестировать ее утомительно, разработчики обычно идут счастливым путем с системным администратором и проверяют, работает ли тестирование, бум тестирования закончился.

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

Требования и предположения

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

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

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

Поздний проект

Вините в этом менеджера проекта и заказчика, а не разработчиков, они делают только то, что им говорят :-)

Мусорный код

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

Это должно быть ужасно для разработчика?

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

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

Код настолько плох, что маленькие дети плачут!

Это был комментарий к LinkedIn с картинкой о том, как скоро мы сможем забыть код, который пишем.