#люди

В году уже не помню каком, когда Docker только только набирал обороты, а первые смельчаки пробовали свои силы в k8s, у меня появилась затея поднять на VmWare кластер из однотипных контейнеров, который должен был бы обслуживать трафик.

Я закинул эту идею своей команде, мне посоветовали пообщаться с одним из Staff+, который собаку съел на хостинге и развертывании. Долго тянуть с этой историей не буду, скажу, что по итогам этого общения решил задачу вообще по-другому и вовсе без контейнеров.

Нередко приходиться обращаться к старшим коллегам или из соседних команд по какому-то специфическому вопросу, и в этот момент меньше всего хочется услышать встречный вопрос: "Какую проблему решаем?"

Однако задница горит только так, в путь. Вот представьте - сидите, долго корпите над ПРОБЛЕМОЙ, продумываете РЕШЕНИЕ, и задумываетесь о применении ИНСТРУМЕНТА. Идете к эксперту, а тот чем рассказать про этот инструмент, вместо этого сам задает встречные вопросы, да и вообще братишка, тут все по новой надо, и вообще не то делаешь. Скотина такая.

Я слышал этот вопрос очень часто, а со временем переметнулся в лагерь тех, кто его задает. Притом необязательно задавать прям в лоб, можно замучать наводящими "зачем" и "почему", но задача всегда в одном - докопаться до изначальной постановки проблемы, что вполне объяснимо.

И не стоит забывать, что обе стороны могут быть правы, да и в конце концов в вопросах архитектуры всегда есть откупы. Так что холиварить нет смысла.

В Uber при написании дизайн-документа нужно добавлять пункт "альтернативы", в котором прописывается, что еще смотрели и почему не подходит. Это не всегда помогает от ненужных вопросов, но сокращает количество почемучек до адекватных значений.

В комментарии приглашаются все рассказать о своем опыте и как их контора способствует быстроте принятия инженерных решений.