Нет никакого сговора, обычная эскалация вопроса об ответственности: не разработчик по безалаберности чувствительные данные упустил на сторону, а начальство знало про дыру и согласовало спорное техническое решение.
Можно и чего попроще взять. Например, "Записки экстремиста" Курчаткина. На моей памяти как напечатали в одном из толстых журналов в самом начале 90-х, так больше широко не упоминались.
Навскидку: а поисковая волна так или иначе должна раздуться, чтобы обойти зону с ограничением для входа в "ближнем к целевой точке" месте, нет? И для нашей предметной области размер раздувания, наверное, на порядок меньше общего диаметра графа. Т.е. эффект есть, но предполагаю, статистически малозначимый.
Лет 20 назад применял для весов ребер простое правило коррекции "лучше километр по обычной дороге, чем метр по дороге с ограничением", и результаты были превосходными. Только задача была не специфическая для грузового транспорта, а на более общие ограничения знаком "движение запрещено".
Как только перестанет хватать кандидатов, все эти крысиные бега на собесах иссякнут сами собой. Кто давно живет, то все это уже не по одному разу увидел.
Хороший кодревью еще поискать сильно надо. Обычно все вырождается в одну из крайностей:
формальный просмотр глазами, не вникая в суть -- строчки кода неприличных пятен Роршаха не образуют и то хлеб. Это еще довольно безобидный вариант.
парное колупание каждой буквы изменений с автором; от п.1 отличается только тем, что автор занимается пересказом кода, а ревьюер по-прежнему лениво скользит глазами и рандомно ставит вопросы "почему?" В итоге вместо полезных изменений с рефакторингом и погашением техдолга обычно выбирается то, где поменьше про код рассказывать нужно.
Потому что нормальный кодревью -- это, по большому счету, "сделать ту же задачу другим человеком, а потом сверить решения", восходящий к древнему принципу "у дураков мысли-то сходятся". Но никто время на такое в здравом уме в планирование не закладывает.
А случайно выявленные ошибки стиля написания, правил работы с сущностями и т.п. -- на такое при нормальной организации работ давно формальные тесты понаписаны, которые поэффективнее человеков будут.
Объем копипасты после ИИ затмит тот, что мы уже имеем после того, как в нашу жизнь пришел stackoverflow. Возможно, наконец-то начнут по-настоящему ценить тех, кто реализует в продукте очередную фичу, сокращая при этом объем кодовой базы :)
Если трекинг носит не аналитический, а репрессивный характер, то вода все равно дырочку найдет: или сотрудники научатся фиктивную активность трекать, или работу поменяют.
А с аналитикой жить проще всем сторонам: одни видят, что оговоренное время нанимателю продали, рассовав его по задачам; а наниматель видит, что какие-то задачи идут дольше, чем ожидалось, и может начинать вентилировать вопрос с качеством планирования (в первую очередь, учета подводных камней внешне простых задач).
Да ведь это метод резиновой уточки: пока объяснишь ей, в чем твой затык, уже и делать ничего не нужно оказывается.
Нет никакого сговора, обычная эскалация вопроса об ответственности: не разработчик по безалаберности чувствительные данные упустил на сторону, а начальство знало про дыру и согласовало спорное техническое решение.
А как упоминание этого факта должно сказаться на вашем найме? Пусть его поведение не ваша недоработка, но и не профессиональная заслуга же?
Бывает такой онбординг, что лучше бы его не было вовсе. Особенно, когда HR -- массовик-затейник по жизни, а дирекция по рукам ему не бьет вовремя.
Слез и раскаяния. Во всяком случае, именно так считывается обилие разноплановых вопросов в перечне того-что-стоит-знать.
"А если встанет на ребро?" ©
"6 из 45" стало же под конец 80-х
"Знаете, я и сам своего рода Леонид" ©
Не, просто пиара вокруг не случилось, как я понимаю.
Можно и чего попроще взять. Например, "Записки экстремиста" Курчаткина. На моей памяти как напечатали в одном из толстых журналов в самом начале 90-х, так больше широко не упоминались.
Гражданин, пройдемте!
[вспоминая, где именно характерно такое склонение мужских фамилий]
Навскидку: а поисковая волна так или иначе должна раздуться, чтобы обойти зону с ограничением для входа в "ближнем к целевой точке" месте, нет? И для нашей предметной области размер раздувания, наверное, на порядок меньше общего диаметра графа. Т.е. эффект есть, но предполагаю, статистически малозначимый.
Лет 20 назад применял для весов ребер простое правило коррекции "лучше километр по обычной дороге, чем метр по дороге с ограничением", и результаты были превосходными. Только задача была не специфическая для грузового транспорта, а на более общие ограничения знаком "движение запрещено".
Обычно "простая" схема хорошо сочетается с менеджером паролей на случай провалов в памяти и специальных парольных политик на отдельных сервисах.
Как сказала бы здесь типичная хрюша, вы плохо подготовили самопрезентацию к собеседованию, мы вам перезвоним.
Часто сложность кейса вытекает из большой истории компромиссов на проекте, и сжато подать все это вообще нереально.
Пока же, конечно, печально наблюдать, как лицемерная ценность "проактивности" из найма в продажах приползает к техническим специалистам.
Как только перестанет хватать кандидатов, все эти крысиные бега на собесах иссякнут сами собой. Кто давно живет, то все это уже не по одному разу увидел.
Хороший кодревью еще поискать сильно надо. Обычно все вырождается в одну из крайностей:
формальный просмотр глазами, не вникая в суть -- строчки кода неприличных пятен Роршаха не образуют и то хлеб. Это еще довольно безобидный вариант.
парное колупание каждой буквы изменений с автором; от п.1 отличается только тем, что автор занимается пересказом кода, а ревьюер по-прежнему лениво скользит глазами и рандомно ставит вопросы "почему?" В итоге вместо полезных изменений с рефакторингом и погашением техдолга обычно выбирается то, где поменьше про код рассказывать нужно.
Потому что нормальный кодревью -- это, по большому счету, "сделать ту же задачу другим человеком, а потом сверить решения", восходящий к древнему принципу "у дураков мысли-то сходятся". Но никто время на такое в здравом уме в планирование не закладывает.
А случайно выявленные ошибки стиля написания, правил работы с сущностями и т.п. -- на такое при нормальной организации работ давно формальные тесты понаписаны, которые поэффективнее человеков будут.
Объем копипасты после ИИ затмит тот, что мы уже имеем после того, как в нашу жизнь пришел stackoverflow. Возможно, наконец-то начнут по-настоящему ценить тех, кто реализует в продукте очередную фичу, сокращая при этом объем кодовой базы :)
Если трекинг носит не аналитический, а репрессивный характер, то вода все равно дырочку найдет: или сотрудники научатся фиктивную активность трекать, или работу поменяют.
А с аналитикой жить проще всем сторонам: одни видят, что оговоренное время нанимателю продали, рассовав его по задачам; а наниматель видит, что какие-то задачи идут дольше, чем ожидалось, и может начинать вентилировать вопрос с качеством планирования (в первую очередь, учета подводных камней внешне простых задач).
В любой непонятной ситуации правильно будет 42.
Ваши программисты должны быть осьминогами, чтобы отстрелить себе напрочь все ноги хотя бы частью приведенных способов.