Фото автора Джонатан Хоксмарк на Unsplash
Раньше я работал под очень академическим техническим руководителем. Когда он не переписывал функции, которые были созданы в течение нескольких дней или недель, чтобы сделать их более совершенными — с точки зрения кода и организации файлов — он читал сообщения в блогах о шаблонах проектирования и о том, как все должнобыть в вашей кодовой базе.
Прошло три месяца с даты, когда мы должны были выпустить первую версию нашего приложения, и у нас до сих пор ничего не вышло. Пока другие члены нашей команды были заняты созданием и доставкой функций для v1, он писал и переписывал, возился с файловой структурой и пытался сделать все идеальным. В конце концов наш технический директор пронюхал об этом, поскольку проходила неделя за неделей, а приложение все еще не было выпущено.
После того, как приложение было отправлено, наш технический руководитель покинул компанию, и я получил повышение на его должность. Потом произошло нечто странное:
Моим первоначальным желанием было продолжить традицию. Не переписывание, а перфекционизм.
Вскоре после этого я разрабатывал функцию единого входа для наших корпоративных клиентов и начал болтать о «лучшем» способе написания очень маленькой функции и о том, где она должна жить. Это было, наверное, 5 строк, максимум.
Должна ли это быть бесплатная функция? Должен ли он быть в отдельном файле или вместе с другим кодом единого входа?
Должен ли это быть класс с одной открытой функцией?
Поскольку он такой маленький, могу ли я просто прикрепить его к другой части единого знака работы и не беспокоиться о том, что он будет жить сам по себе?
Его мышление стало моим, и я был парализован решениями, которые практически не имели последствий в реальном мире и не имели никакого значения для людей, платящих нашей компании большие деньги.
Я подошел к нашему вице-президенту по инженерным вопросам, чтобы определить, что лучше всего сделать с этой маленькой функцией. Я был готов к такому же разговору с ним, как и бесчисленное количество раз с нашим предыдущим техническим руководителем.
Вместо этого разговор был коротким. Его ответ, который навсегда изменил то, как я работал и думал о коде, был таким:
"Мне все равно, просто заставь это работать".
Фото Jason Hogan на Unsplash
Я чувствовал себя свободным.
В конце концов, я был техническим руководителем! Это была моя команда!
Нам всем не нравился прежний стиль академического перфекционизма и пост-блогинга. Почему я продолжал беспокоиться о том, соответствует ли наш код тому, как кто-то вне нашей команды сказал, что что-то должно выполняться.
Эти тенденции меняются со временем. Поверьте, я редактор «Лучшего программирования» 😊. Сообщение в блоге было полезно в теории, но в конечном итоге не имело значения для бизнеса.
Нам оставалось только отправить.
Это изменило то, как я руководил командой, начиная с того разговора и далее.
«Сделайте заметку, давайте вернемся к ней после того, как мы отправим» — стало моим девизом. Мы все знали, что должны были сделать. Мы создавали функцию, тестировали ее, исправляли все ошибки, затем объявляли ее завершенной и переходили к следующей функции. Где-то был этот список, надежно спрятанный, чтобы мы могли вернуться к нему в будущем.
После того, как мы выпустили продукт, ничего катастрофического не произошло, потому что наш код не был идеальным.
Промедление было вызвано замаскированным страхом. Чтобы понять это, мне понадобился короткий разговор с моим вице-президентом.
Совершенно нормально иметь согласованные стандарты в вашей кодовой базе и лучшие практики для вашей команды и для вашей компании. Если ваша команда работает медленнее из-за того, что каждый в команде должен отфильтровать свой код в соответствии с определенным стилем или предпочтениями определенного, твердо убежденного инженера, вам потребуется гораздо больше времени, чтобы отправить все.
Поэтому независимо от того, учитесь ли вы программировать и читаете это или углубляетесь в свою инженерную карьеру, тратьте больше времени на то, чтобы все работало, и меньше времени зацикливались на должны разработки. сильный>
Убедитесь, что ваш код безопасен, надежен и относительно эффективен. Но помните: ваш код, скорее всего, (пока) не работает в масштабе, при котором неэффективность будет стоить вашему бизнесу значительных денег. Так что неважно! Просто заставь это работать.
По мере масштабирования вы будете переписывать этот код, чтобы сделать его лучше. Пересмотрите это после отправки.
Гораздо более вероятно, что ваш код, который не будет доставлен, будет стоить бизнесу дороже.
Лучший инженерный совет, который я когда-либо получал: «Мне все равно, просто заставьте это работать»
