Хакер спрашивает: «Что заставляет это работать?» Инженер спрашивает: «Как это должно работать?» В этом разница между хакером и инженером. Хакера в первую очередь интересуют результаты. Инженер в первую очередь занимается дизайном. У каждой точки зрения есть преимущества и недостатки.
Хакеры
Плюсы:
- Делает работу быстро
- Находит интересное поведение системы
- Основные функции могут быть добавлены без перезаписи или замедления скорости
- Требуется меньше понимания, чтобы внести значительный вклад
Минусы:
- Код спагетти
- Увеличение технического долга
- Члены команды могут испытывать трудности с пониманием того, почему все было сделано именно так, а не иначе.
- Нечистота кода и разочарование в результате
- Много прерываний, вы не можете просто писать код, потому что вам нужно видеть, работает ли он регулярно (это не разработка с нуля)
Инженеры
Плюсы:
- Чистый код
- Четкие ментальные модели
- Меньше «трудно исправимых» ошибок с новыми системами
- Удовольствие от разработки с нуля
Минусы:
- Желание провести рефакторинг или переписать архитектуру / ментальную модель по мере изменения требований реального мира.
- Разочарование со стороны руководства по поводу того, как долго все продолжается
- Разочарование в коде, написанном хакерами из вашей команды
Это просто перспектива
Хакеры и инженеры — это просто точки зрения, благоприятствующие разным интересам. Это действительно интересная идея для меня. Это не врожденное качество или черта. Это простая привычка мышления, инструмент. Отсюда следует, что мы можем использовать этот инструмент по своему желанию. Выбор правильного инструмента для правильной работы.
Время историй
Технический директор моей компании наглядно показал это на своем примере за последний год. Мы перенесли большую часть функциональности в новый фреймворк. Я с ужасом наблюдал, как он нарушал всевозможные правила в новом фреймворке для достижения наших целей. Я презирал его за это. Код был абсолютным беспорядком! Я ругался и жаловался. Он справился с этим хорошо и остался на курсе.
К моему удивлению, миграция прошла быстро. В изменениях были ошибки, но в целом они работали хорошо. Позже я понял, что миграция была лишь первым шагом к тому, чтобы все стало лучше. В течение года мы делали его все лучше и лучше, исправляя вещи по мере добавления функциональности. Мы смогли продолжить «исправлять» наш код, не замедляя разработку.
С того времени прошло меньше года. Скромный пирог имеет вкусный вкус! На самом деле, это так. Я смог увидеть результат этой «хакерской» стратегии. Оглядываясь назад, можно сказать, что если бы мы «спроектировали» миграцию, велика вероятность того, что проект оставил бы пресловутый неприятный осадок во рту у руководства. Этот дурной тон, вероятно, привел бы к недоверию к возможностям разработчиков.
Теперь, когда я понимаю эти точки зрения, я ценю их. Я занимаюсь небольшим хакерством с небольшим инженерным делом. Это отношения «и то, и другое», а не «или или». В этом есть баланс. Это инструмент.
Надеюсь, вы видите ложную дихотомию между хакерством и инженерией. По крайней мере, для меня это полезный урок. Есть также более глубокий урок командного игрока, но это для другого поста.
Наслаждаться!
