Вы потратили часы и часы на написание кода. Вы готовы отправить свои изменения на проверку кода. *Раздается звонок-уведомление. Были запрошены изменения, предложения по коду, потенциальные ошибки и проблемы с чистотой кода. Вы злитесь.
Давайте представим другую ситуацию. Ваша фича попадает в продакшн. Спустя несколько недель вы получаете сообщение из отдела эксплуатации о том, что что-то не работает. Вы начинаете защищаться и предполагаете, что они, должно быть, используют его неправильно.
Это результат того, что вы защищаете свой код. Несмотря на то, что я люблю кодировать, я уверен, что ценность, которую я предоставляю, — это не код. Конец моей работы — это не сам код, а продукт, который я создаю. Однако это не означает, что мой код не должен быть чистым и легко читаемым, поскольку это необходимо для того, чтобы сделать продукт расширяемым в будущем. Инженеры-программисты, которые защищают свой код, не понимают, что программирование — это инструмент. Он, конечно, крайне важен, но не является завершающим в работе. Настоящие специалисты по решению проблем используют свои технические навыки как инструмент.
Опытные инженеры знают, что код — это всего лишь кисть для хорошего искусства. Защита своего кода замедляет вашу работу следующим образом:
- Вы обижаетесь, когда принимаете обратную связь
- Делает вас слепым к потенциальным ошибкам
- Мешает вам учиться у других разработчиков
- Приводит к тому, что вы думаете, что обзоры кода — это личное.
- Закрываете себя для критики и советов
Это вторая часть коротких статей о распространенных карьерных проблемах, с которыми сталкиваются инженеры. Если это звучит интересно, приглашаю вас прочитать «Страх слияния».