Вы разработчик программного обеспечения, инженер или программист, и, надеюсь, вам нравится то, что вы делаете (большую часть времени)
Однако для большинства разработчиков обязательно наступят дни, когда ваши механизмы превратятся в мелкую пыль, а крик «Я ненавижу программирование» эхом разносится по комнате команды разработчиков.
Не думайте, что вы должны страдать в одиночестве
Мы знаем, что разработчики часто не согласны друг с другом, но это может быть тот редкий случай, когда мы все едины.
Мы создали 10 самых ненавидимых разработчиков после долгих исследований с различными командами разработчиков, и эти раздражения должны находить отклик у большинства из вас, независимо от вашего уровня или языка, на котором вы программируете.
Это может подготовить вас к старым добрым стенаниям, но должно быть полезно просвещать более широкий мир о том, что вас заводит, и повышать вероятность того, что ваши клиенты и коллеги будут более внимательными в будущем.
1. Mission Creep (противник проекта)
Программный проект был спланирован и согласован, основная работа завершена. Вы гордитесь своими достижениями и внутренне празднуете успех
Вы осуществили все мечты ваших клиентов и готовы перейти к следующему проекту
Остановись прямо там!
То, что ваши клиенты думали, что они хотели несколько месяцев назад, кажется, внезапно изменилось. Самая важная функция больше не нужна, и у них есть несколько блестящих новых идей, которые они хотели бы, чтобы вы включили. Их идеи означают, что вам придется полностью перенастроить все, что вы делали до этого момента. Что еще хуже, они довольно расплывчато говорят об изменениях, которых на самом деле хотят сейчас.
Их нереалистичные ожидания и чрезмерно оптимистичные сроки означают, что ваше время разработки просто удвоилось при одновременном входе в проект Twilight Zone.
К счастью, не каждый проект такой, но у большинства есть элемент дополнительных требований, что приводит к дальнейшему времени разработки, ресурсам, волне страха и незавершенности.
2. Перерывы
Вы находитесь в зоне — вы можете представить идеальное решение проблемы, над которой вы работаете, когда — бам! Все потеряно
Вам потребуется 25 минут, чтобы вернуться туда, где вы были (не считая времени, потраченного на разговор с прерывателем) — и это если вам когда-нибудь снова удастся изменить зону.
Многие разработчики носят наушники, но для непосвященных они могут подумать, что вы просто тихо качаетесь, а не отвлекаетесь.
Вы можете создать краткое уведомление на двери команды разработчиков, в котором объясняется, почему вы не хотите, чтобы вас прерывали, но постарайтесь мягко объяснить своим клиентам, почему вы так ненавидите прерывания — немного понимания может заставить их дважды подумать, прежде чем прерывая вас и облегчая вашу боль
3. Скучные скучные встречи
Совещания мешают написанию кода и делают ваши сроки еще более жесткими. Их так же ненавидят, как прерывания, и они могут даже включать в себя целую коллекцию ваших любимых прерывателей в одном месте.
Что еще хуже, большая часть совещаний часто не нужна, и их можно решить по электронной почте в то время, когда это не прерывает ваш поток. Они могут быть неэффективными, затягиваться с добавлением новых тем без необходимости, часто без повестки дня и контролироваться теми, у кого самый громкий голос, а это означает, что у вас может даже не быть возможности принять участие.
Они могут даже иметь мало общего с вашей реальной работой и, вероятно, являются ключевой причиной того, почему многие разработчики хотят работать удаленно и сохранять концентрацию.
4. Плохой код
Всем известная цитата
«Всегда программируйте так, как будто парень, который в конечном итоге будет поддерживать ваш код, будет жестоким психопатом, вы знаете, где вы живете» Джон Ф Вудс
. . . . это хороший способ продолжить
Как разработчик или программист вы, несомненно, будете время от времени работать с чужим кодом. Код может варьироваться от того, что написано богами программирования, где вы можете учиться на их опыте, до строк бреда, написанных новичками или ленивыми программистами, где вам придется полностью переписать оскорбительный код.
Возможно, у вас просто есть свой стиль и вы хотите его придерживаться. Другие люди, взламывающие ваш код, тоже могут раздражать
Каким бы ни был сценарий — если вам нужно время для рефакторинга или поддержки этого кода — вы не будете счастливы.
Если код не задокументирован или вы не можете понять мыслительные процессы исходных кодеров, это займет еще больше времени.
. . . . пожалуйста, постарайтесь не готовить свои острые ножи и адресную книгу
5. Какая документация?
Что касается документации — большинство разработчиков ненавидят это делать — и ненавидят читать ее, когда она не соответствует требованиям и делает обслуживание сизифовой задачей.
Однако вы не можете получить свой торт с документацией и съесть его. Старайтесь быть лучшим разработчиком, который пишет, чтобы помочь другим, и тратит время на составление четких полезных инструкций. Или еще лучше — работайте с конечным пользователем или с тем, кто напишет это за вас.
Покажите, насколько вы ценны для команды с помощью хорошо написанной документации, и это может даже помочь вам быстрее продвигаться по карьерной лестнице, когда ваша неоценимая помощь будет признана.
6. Отладка (работа над цепочкой кодирования)
Еще одна главная ненависть разработчиков — работать над небольшими фрагментами кода, а не над чем-то интересным и творчески полезным.
Или даже не писать достаточно кода!
Как разработчик программного обеспечения или программист вы неизбежно будете иногда получать работу, которая вам не нравится.
Если это так повторяется — подумайте об автоматизации. Или найдите кого-нибудь, кто получает удовольствие от занятий, которые вы ненавидите, наденьте наушники или попытайтесь найти в этом какую-то радость. Иногда может быть полезно немного разгрузить мозг, прежде чем готовиться к чему-то более сложному?
Вы можете обнаружить, что постоянно занимаетесь отладкой — ищете эту иголку в стоге сена и отвлекаетесь — усугубляется давлением решить ее как можно скорее или потратить всю ночь на попытки. Это может показаться довольно низкой точкой, но не сдавайтесь — попросите свою команду тоже взглянуть — иногда новый взгляд может что-то заметить или предложить другое решение.
7. Они понятия не имеют, чем я на самом деле занимаюсь
«что-то связанное с компьютерами» — Моя мама
Ваша семья знает, что вы регулярно нажимаете на кнопки, в то время как ваши менеджеры думают, что вы можете делать что угодно, от починки принтеров до письма на любом языке или взлома их Netflix.
Вы и ваша команда можете понимать разницу между разными ИТ-ролями и языками, но ваша семья, друзья и удаленные коллеги, вероятно, никогда не поймут больше, чем основы.
Примите это сейчас (или будьте готовы раздать ламинированные мини-описательные/иллюстрированные организационные диаграммы с вашим собственным цветом). По крайней мере, это отвлечет тех, кто хочет, чтобы вы починили их принтер.
8. Знай все боссы
Разработчики ненавидят слишком много управления и неправильный тип управления
Добросовестный разработчик захочет следовать правилам чистого кода и создавать высококачественное программное обеспечение. Однако всеобъемлющие решения могут исходить от кого-то, кто заботится только о конечном результате, а не о техническом обслуживании или текущей производительности, которые могут разочаровывать.
К сожалению, персонажи Дилберта часто звучат правдоподобно, а босс-всезнайка слишком распространен. ИТ-отделы часто могут быть введены в заблуждение начальниками, которые считают себя экспертами, и которые, возможно, когда-то были экспертами, но теперь слишком удалены от власти, чтобы принимать правильные решения. Управление само по себе важно для команды разработчиков, потому что без структуры, общей цели, кого-то, кто может управлять ожиданиями клиентов и вести переговоры от имени команды, жизнь разработчика может быть тяжелой борьбой.
Неправильный начальник может нанести серьезный ущерб и привести к неправильному выбору технологий, сосредоточению внимания на неправильных решениях, неподходящим найму, низкому моральному духу, плохой приоритизации задач, нереалистичным ожиданиям и даже может обвинить разработчиков, когда все пойдет не так — список можно продолжить. . .
9. Новые блестящие языки
Почти все ненавидят работать с устаревшими устаревшими системами, которые требуют тщательного обслуживания и мешают новым технологическим достижениям.
Точно так же спешка с внедрением новых языков или фреймворков для решения старых проблем также может вызывать разочарование. Возможно, вы потратили годы на то, чтобы стать экспертом в своей технологии, чтобы внезапно обнаружить, что она отошла на второй план, в то время как ее место заняло что-то более модное. Теперь вам нужно узнать что-то новое или остаться позади, а уровень работы по обновлению вашего текущего приложения может сбить вас с толку.
Конечно, переход к более новаторской технологии может быть положительным моментом, а не использовать что-то старое и неэффективное, но раздражающее для старших разработчиков, которые видели бесконечные изменения ради изменений на протяжении многих лет.
10. QA Взлом вашего кода
Вы, вероятно, ненавидите QA — они созданы для того, чтобы что-то ломать
Хороший тестер на вес золота — и он должен вас раздражать — и когда он не дает вам совершать ужасные ошибки, вы должны быть ему благодарны.
В отличие от этого, плохой тестировщик — это королевская боль в пословицах, создающая ненужную драму и даже, возможно, пропускающая самые важные проблемы. Недостаток знаний может создать больше проблем, чем необходимо для их исправления.
Надеюсь, ты все еще любишь свою работу
Работа разработчика, инженера-программиста, кодера, программиста — как бы мы ее ни называли в этом десятилетии — бесспорно велика.
Придирки в этом списке распространены, но, надеюсь, не оттолкнут вас. Если вокруг вас отличная команда, босс, который знает свое дело, и вы можете время от времени писать то, что хотите, то большую часть времени вы должны быть счастливы.
Если вы постоянно прижаты спиной к стене и вам не нравится то, что вы делаете, — идите и найдите лучшую компанию или команду — там есть куча отличной работы.
Первоначально опубликовано на www.explore-group.com.
