Комментарии 17
А это точно перевод. А то прям как российские реалии читаешь.
Если посмотреть на кодовую базу, вы увидите много сервисов, названия которых заканчиваются на z, а также удивительно большое количество переменных. Один из старых сотрудников сказал, что когда-то давно кто-то хотел добавить мониторинг. Было не очень безопасно выставлять для мониторинга google.com/somename, поэтому они добавили z, то есть google.com/somenamez — для безопасности. Это в компании, которая сейчас считается лучшей в мире по безопасности.
А может кто объяснить про это. Или дать ссылки.
Выставили в инет голой задницей сервис мониторинга, но обозвали его Ы, чтобы никто не догадался.
Security through obscurity.
Вау, этот парень, должно быть, работает с суперзвёздными программистами. Но будем реалистами...
Я в такой компании проработал почти год. Сквозь такую «броню» аргументов не пробиться. Любая техническая коммуникация с пояснениями, почему нужно что-то менять, сводится к разговору типа «щенок, не учи меня как работать», любая попытка внедрения улучшений саботируется — начинают неправильно использовать технологии/флоу, писать кривые тесты и жаловаться что время потратили, но не помогло.
Есть компания, которая невероятно скрытно относится к своей инфраструктуре. Например, боится сообщать о багах поставщику оборудования, потому что тогда ошибки будут исправлены, а конкуренты смогут использовать исправления. Этого нельзя допустить. Решение: запросить прошивку и исправить баги самостоятельно! Нормально.
Можно перевести этот перевод на русский язык?)
Самый простой вариант — просто делать правильные вещи самостоятельно и игнорировать то, что происходит вокруг. Вы принесёте некоторую пользу, но масштаб вашего влияния ограничен. Далее, можете убедить свою команду делать правильные вещи: я делал это несколько раз для внедрения практик, которые считаю действительно важными.
«Личный пример» работает, проверял сам.
Со временем кто-то да увидит для себя пользу и тоже последует примеру, и так дальше по цепочке.
Имхо, это довольно объяснимо: если руководитель признает провал, то в большинстве компаний это приведет к явным (вроде увольнения, лишения премий на два года) или неявным последствиям (отказы в поездках на конференции, повышения того, кто не попался), даже если они пропагандируют открытость к ошибкам и отсутствию наказаний за это. Поэтому он может либо признать поражение (и получить волну негатива), либо продолжать давить и верить, что либо к неудачному выбору все привыкнут, либо через год можно будет внедрить что-то новое. Кажется, что выбор крайне очевиден.
Но так и не смог убедить сотрудников сначала запускать тесты.
А надо было их запускать в обязательном порядке на CI, локально никто ничего запускать не будет точно.
Выключить или игнорировать уведомления, потому что их слишком много и они слишком раздражают? Действовать вручную с риском ошибиться? Да я могу навскидку назвать сразу несколько компаний, где разбор полётов после катастрофы начинается именно с этих пунктов
Чаще всего в софтверной теме этот подход приводит только к финансовым потерям различных фигурантов проблемы. Но проблема куда глобальнее — такой подход, похоже, у человечества в крови. Далеко ходить не надо — причем первого предупреждения не хватило, и ведь тут уже не обойдешься «патчем, который по шурику разлить на машинки», да и "патч века", по сути, просто костыль на сотню лет. И хорошо бы тут сказать, что роботы спасут мир, но — их ведь тоже проектируют люди…
Нормализация девиантности. Как неправильные практики становятся нормой в нашей отрасли