или: Как полюбить кроличью нору, не теряя кода доставки
Поговорим немного о кроличьей норе. Для разных программистов это означает разные вещи, но у него есть своеобразное качество ощущения, будто вы что-то делаете, но ничего не делаете сделано. Проверка кода завершена. Отправлено и объединено в мастер готово. Закройте тикет готовым. Вы, конечно, что-то делаете, но полезно ли это? Что вы делаете 20 вкладок в эту проблему, исследуете наследование одной таблицы, задаетесь вопросом, следует ли вам переключить свое внимание с объектно-ориентированного программирования на функциональное программирование, перефразируя свой код 12 раз, прежде чем у вас все равно будет покрытие тестом?
Кроличьи норы могут быть глубокими. Они редко уходят далеко. Ваша готовность углубиться - это, вероятно, то, что делает вас внутренне отличным программистом, но ваша неспособность отказаться от этого и идти к горизонтальной цели делает вас немного обузой для ваших товарищей по команде и менеджеров проектов. Им я дам совет, примите кроличью нору, вытащите своих инженеров, но не подавляйте их страсть к исследованиям!
Ваши самые частые кроличьи хулеры, вероятно, являются вашими наиболее целеустремленными учениками и могут быть фантастическим активом для команды при вашей поддержке. Но что касается тебя, мой друг в кроличьей норе, я призываю тебя выйти и отправить какой-нибудь чертов код.
Единственное, что исправить кроличью нору - это добавить какой-то проклятый код, который что-то делает, независимо от того, что вы об этом думаете. Тем лучше, если люди будут в восторге от функциональности, а вы - от реализации. Отправим его. Отправляйте его и любите его недостатки.
—
Равбитолинг часто используется в том же метафорическом пространстве, что и «невозможность видеть лес за деревьями». По сути, вы настолько сосредотачиваетесь на решении определенной подгруппы проблемы, что забываете решить реальную задачу, которую вас послали решить. В худшем проявлении вы работаете чрезвычайно усердно, достаточно усердно, чтобы быть на пределе своих возможностей в течение нескольких дней, но когда появляется планирование спринта, вам нечего показать, кроме слабого утверждения, что дела идут, но ничего конкретного показать.
Вы выгорели, вашей команде нечего показать. Вы чувствуете себя неподдерживаемым, ваша команда неделя за неделей чувствует тяжесть вашего неотправленного кода. Вам стыдно просить о помощи, ваша команда не знает, как вам помочь, самые плохие менеджеры даже не знают, что вам может понадобиться помощь. Это ужасно. Избегайте этого любой ценой.
—
Я думаю, что есть множество способов проникнуть в кроличью нору, и они заслуживают их совета, но у них есть по крайней мере одна общая черта. Все они предпочитают идеал реальному. Все они сосредоточены на том, что можно сделать, а не на том, что делается. Они сосредотачиваются либо на прошлом, и на том, как код мог быть написан, либо на том, насколько идеальным может быть код однажды, но они не сосредотачиваются на настоящем.
(Я также думаю, что программисты, наиболее склонные к злобе, - это инженеры среднего звена. Мои люди. Мой уровень. Или, говоря современным языком нашей отрасли, старшие инженеры по программному обеспечению (но не ведущие инженеры, разработчики платформ и т. Д.). Может быть, вы Я работал в одной, двух или трех компаниях. Вы профессионально программировали 3–8 лет. Вы стали лучше, но часто все еще чувствуете себя немного потерянным. Вам поручают «тяжелые проблемы», но иногда вы чувствуете выход из вашей глубины.
Вы знаете более чем достаточно, чтобы быть опасным. Вы можете увидеть недостатки в любой реализации. Вы боитесь писать такой же плохой код, как и код, который вы писали несколько лет назад. Из болезненного опыта вы знаете, что такая тесная взаимосвязь приведет к проблемам с рефакторингом в следующем году, и поэтому вам нужно рефакторировать 1/3 кодовой базы, прежде чем вы сможете добавить эту функцию.
Назовем это пустыней вполне компетентных.
—
Есть много способов попасть в кроличью нору.
Вы можете решить другую проблему, чем та, которую вас попросили решить, особенно глубокая кроличья нора заставит вас решить массу проблем, которые необходимо решить, прежде чем вы сможете решить ту, которую вас попросили решить. Вы уверены, что вам нужно решить их все прямо сейчас?
—
Можно крутиться по кругу. Это отличный вариант для программистов, склонных к синдрому самозванца и стыду. Возможно, проблема, которую вас попросили решить, немного выходит за рамки ваших текущих возможностей. Вместо того, чтобы просить о помощи (ведь это страшно!), Вы проводите день за днем, просматривая документы и учебные пособия и пытаясь понять, как это исправить. Пребывание на грани своих возможностей помогает вам расти, а столкновение с глубоким концом вредит как вам, так и вашей команде. В то время как вы чувствуете себя некомпетентным придурком и тратите 20 часов, не решая проблему, ваша команда теряет способность как повысить ваш уровень, так и решить проблему за 5 часов с помощью некоторых пар.
Вы хотите исправить? Проследите за всеми своими программистами, что они уже достаточно хороши, и если они чего-то не знают, это возможность для роста всей команды (либо будучи наставниками, либо выясняя это вместе). Наймите менеджеров с эмоциональным интеллектом, чтобы понять, что стыд - это тяжело, что он пересекается с маргинализацией и никогда не может служить хорошим мотиватором. Поднимите вверх своих инженеров, которые кажутся хорошими в наставничестве, и помогите им добиться большего.
—
Вы можете бриться. Это отлично подходит для тех из вас, кто любит работать продуктивно. Сделайте ваш редактор лучше. Сделайте линтер лучше. Реорганизуйте класс в три класса, которые являются Better Code (tm), но не добавляют функциональности. Добавьте несколько тестов, которые уже проходят, потому что поведение, которое вы тестируете, уже работает. Так приятно писать хороший код, но ваш билет все еще находится в стадии разработки.
—
Наконец, стремитесь к совершенству. Решите свой билет и поймите, что вы добавили технический долг. Исправьте технический долг и поймите, что вы добавили больше. Напишите 40 новых тестов. Исправьте, как CI запускает тесты. Исправьте скрипт, строящий ваши экземпляры. Отправьте отчет об ошибке в Amazon. Отправьте отчет об ошибке с помощью Heroku. Напишите новый DSL для Rspec. Начните рефакторинг половины своего приложения, и через 2 дня вы поймете, что у вас есть 17 файлов, в которых есть еще не зафиксированные изменения, и не только исходные изменения больше не работают, но и еще 40 тестов, которые теперь не работают.
—
Что-нибудь из этого вам знакомо? Если нет, не стесняйтесь закончить эту статью и закройте еще несколько билетов JIRA для своей команды. Вы в ударе, и у вас все отлично!
В противном случае я хотел бы предположить, что все эти проблемы возникают либо из-за отсутствия эмоциональной поддержки, которая вам сейчас нужна в вашей организации (но вы всегда можете предоставить ее себе!), Либо из-за непонимания того, как работает разработка программного обеспечения.
—
#1)
Эмоциональная проблема - это стыд. Синдром самозванца, страх, как ни крути. По сути, вы как-то застряли и не хотите просить о помощи. Может тебе страшно. Может быть, нет, может быть, вы убеждены, что уже знаете путь вперед, и никто не сможет вам помочь, потому что вся ваша команда тупица. Может быть. Независимо от того. Любой достойный терапевт знает, что высокомерие - это самый распространенный способ для эго справиться со стыдом.
В любом случае, я обещаю вам несколько вещей: вас наняли люди, которые верят в вас, и если это организация, в которой вы хотите остаться, они оба правы в своей ставке на вас, потому что вы приносите что-то в организацию, в которой они нуждались, и также действительно действительно действительно инвестировал в вас и ваш успех. Хотя бы по той простой причине, что нанимать сложно и дорого! Это означает, что они хотят повысить ваш уровень, но им просто нужно знать, где вам нужна помощь!
Так что рискните оказаться уязвимым.
«Послушайте, я не понимаю Докера. Я снял этот PR 2 дня назад, и я до сих пор не могу даже развернуть среду разработки, и все кажутся разочарованными, когда я прошу о помощи, поэтому я не знаю, что делать. Я заперт. Я борюсь с Докером вместо того, чтобы писать код. Я даже не знаю, с чем должен помочь этот пиар! »
Позвольте мне сказать вам, что если вы не единственный программист в своей организации, вы не единственный, кто задает этот вопрос. Во-вторых, есть кто-то, кто восхищается вашими способностями решать проблемы, и он будет уполномочен задать вопрос в будущем, потому что вы задали его сейчас. В-третьих, виртуальные машины - заноза в заднице, поэтому можно задавать вопросы. В-четвертых, почти каждый программист, который не компенсирует высокомерие, боится задавать вопросы в какой-то момент, поэтому ваши честные вопросы помогают всей нашей профессии. Шутки в сторону! Вы хороши в том, что делаете, но наша сфера деятельности обширна, и нормальные глупые вопросы помогают нам всем.
Еще я обещаю вам, что никто из тех, с кем вы работаете, не родился с осознанием того, что вы боитесь, что вам не хватает. Может быть, вы меня не слышите, поэтому я повторюсь, человек, которого вы боитесь, который кажется таким уверенным (вспомните роль высокомерия в защите эго), не знал разницы между запросами PUT и PATCH в прошлом году. Так что просто спроси, все хорошо.
#2)
Никто не нанимал вас для написания идеального программного обеспечения. Никто не нанял вас, потому что вы никогда не нарушали Закон Деметры. Они наняли тебя, чтобы ты поработал. Так что сделай какое-нибудь дерьмо.
Я понял, мой друг. Вы видите бури на горизонте. Вы видите неудачные решения в прошлом. Вы - отважный паладин хорошего кода и готовы броситься на свой меч, прежде чем добавите еще больше технического долга.
Вы делаете ту же ошибку, что и менеджеры проектов, когда они переходят к водопаду, а не к agile. Не существует идеального кода. Всегда есть технический долг. Вы никогда не сможете узнать будущее. Вместо того, чтобы сосредотачиваться на совершенстве, сосредоточьтесь на пропаганде итеративных улучшений. Отправьте функцию, подайте заявки на технический долг, обнаруженный при реализации этой функции, расставьте приоритеты по этим заявкам.
Идеальный код никогда не будет отправлен.
Вам / нужно отправить /. Пока вы не отправите идеальный код, у вас в голове! Все в твоей голове! Лучшие художники, которых я знаю, отправляются ВСЕ ВРЕМЯ. Накапливаются письма с отказом. Некоторые вещи публикуются с раздражением. Лучшее не может быть опубликовано. Но, в конце концов, все, что мы знаем о работе в сложных доменах, говорит нам о том, что нам нужно поставлять быстро, часто повторять, четко выражать свои предположения и сотрудничать с нашими менеджерами по работе с клиентами и менеджерами для доставки функций и устранения технического долга.
Но, честно говоря, никого не волнует, знаете ли вы, что такое монада или зачем писать спецификации функций, если вы не можете добавить функцию.
Убейте метод водопада в своем мозгу. Вы никогда не запрограммируете ничего идеального. Кодируйте свой MVP, придумайте, где его можно улучшить, и призывайте уделять время исправлению технического долга каждый раз, когда вы снова касаетесь этого кода.
На самом деле дело в следующем. Если вы больше никогда не коснетесь своей функции, технический долг, который вы понесли, не имеет значения. Если вы коснетесь этого несколько раз, у вас будет много раз, когда вы будете рекомендовать потратить время на написание лучшего кода.
Хороший код - это не о функциональности, а о том, насколько просто его изменить. Тем не менее, если код не нужно менять, не имеет большого значения, если он уродливый, но функциональный.
—
Лучший совет, который я могу дать любой команде, имеющей дело с любыми конечными проблемами, почти такой же (и работает для кроличьих дыр).
# 1) Иметь очень четкие результаты
# 2) Устранение вины, повышение ответственности, общение
# 3) Все неудачи - это неудачи каждого
# 4) Все успехи отмечаются
# 5) Повышение уровня кого-то еще является поводом для более высокого празднования, чем то, что вы делаете это сами (убейте своих героев-программистов, потому что они выгорят, и тогда вас будут трахать)
# 6) Подавайте заявки на технические долги, предоставляя функции, и относитесь к ним серьезно
# 7) Празднуйте свои кроличьи норы! Объедините их исправления с тестовыми привязями, пока вы снова их вернете в нужное русло.
