Удалёнка: опыт и лайфхаки
Реклама
Комментарии 17
+2

А это точно перевод. А то прям как российские реалии читаешь.

+3
Точно:
иначе один из них слишком разозлится и сделает что-то прискорбное.
+2
Из-за переразбития в переводе абзацев на несколько, затруднительно понять, рассказ это об одной и той же компании, или нет
+1
Если посмотреть на кодовую базу, вы увидите много сервисов, названия которых заканчиваются на z, а также удивительно большое количество переменных. Один из старых сотрудников сказал, что когда-то давно кто-то хотел добавить мониторинг. Было не очень безопасно выставлять для мониторинга google.com/somename, поэтому они добавили z, то есть google.com/somenamez — для безопасности. Это в компании, которая сейчас считается лучшей в мире по безопасности.

А может кто объяснить про это. Или дать ссылки.
+2

Выставили в инет голой задницей сервис мониторинга, но обозвали его Ы, чтобы никто не догадался.
Security through obscurity.

+1
А вот и неправильно. Z страницы до сих пор есть у всех сервисов и доступны только изнутри. А z добавляется для пердотвращения потенциальных коллизий с внешними именами. Т.е. безопасность тут не при чем.
+4
Но ведь…
При этом называют причины, которые на самом деле не имеют смысла (например, чтобы избежать коллизии имён).
0
Как это знакомо… Лучшие практики «Rectal Solution & Co» зато осваивать бюджеты — впереди планеты всей. Когда предупреждаешь — «П..%#!#… ц запланирован, у нас же Scrum\Aglie. ». Когда происходит п..%#!#… ц — все бегают с мыльными жопами и орут «Мы все умрем...» или «Ну у нас же Стартап!»
+2
Вау, этот парень, должно быть, работает с суперзвёздными программистами. Но будем реалистами...


Я в такой компании проработал почти год. Сквозь такую «броню» аргументов не пробиться. Любая техническая коммуникация с пояснениями, почему нужно что-то менять, сводится к разговору типа «щенок, не учи меня как работать», любая попытка внедрения улучшений саботируется — начинают неправильно использовать технологии/флоу, писать кривые тесты и жаловаться что время потратили, но не помогло.
-2
Есть компания, которая невероятно скрытно относится к своей инфраструктуре. Например, боится сообщать о багах поставщику оборудования, потому что тогда ошибки будут исправлены, а конкуренты смогут использовать исправления. Этого нельзя допустить. Решение: запросить прошивку и исправить баги самостоятельно! Нормально.


Можно перевести этот перевод на русский язык?)
+2
Самый простой вариант — просто делать правильные вещи самостоятельно и игнорировать то, что происходит вокруг. Вы принесёте некоторую пользу, но масштаб вашего влияния ограничен. Далее, можете убедить свою команду делать правильные вещи: я делал это несколько раз для внедрения практик, которые считаю действительно важными.


«Личный пример» работает, проверял сам.
Со временем кто-то да увидит для себя пользу и тоже последует примеру, и так дальше по цепочке.
+2
Подумалось. Я мало видел статей, где написано, какая это ужасная/плохо работающая/непродуманная новая технология. Типа, вот мы работали всегда на X, потом поставили Y, убили много времени, ничего не достигли и вернулись на X. Как-то принято восхищаться всем новым, пробовать, и если хотя бы минимально адекватно работает — тут же переходить на новое.
0

Имхо, это довольно объяснимо: если руководитель признает провал, то в большинстве компаний это приведет к явным (вроде увольнения, лишения премий на два года) или неявным последствиям (отказы в поездках на конференции, повышения того, кто не попался), даже если они пропагандируют открытость к ошибкам и отсутствию наказаний за это. Поэтому он может либо признать поражение (и получить волну негатива), либо продолжать давить и верить, что либо к неудачному выбору все привыкнут, либо через год можно будет внедрить что-то новое. Кажется, что выбор крайне очевиден.

0
Но так и не смог убедить сотрудников сначала запускать тесты.

А надо было их запускать в обязательном порядке на CI, локально никто ничего запускать не будет точно.
0
локально никто ничего запускать не будет точно
Хук на pre-commit чуть лучше будет. На больших кодовых базах restore/build перед тестами могут занимать минуты.
0
Выключить или игнорировать уведомления, потому что их слишком много и они слишком раздражают? Действовать вручную с риском ошибиться? Да я могу навскидку назвать сразу несколько компаний, где разбор полётов после катастрофы начинается именно с этих пунктов


Чаще всего в софтверной теме этот подход приводит только к финансовым потерям различных фигурантов проблемы. Но проблема куда глобальнее — такой подход, похоже, у человечества в крови. Далеко ходить не надо — причем первого предупреждения не хватило, и ведь тут уже не обойдешься «патчем, который по шурику разлить на машинки», да и "патч века", по сути, просто костыль на сотню лет. И хорошо бы тут сказать, что роботы спасут мир, но — их ведь тоже проектируют люди…

Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.