На своем опыте работы в разных компаниях ни разу не встречал случаев, когда зарплаты друг перед другом светят. Подозреваю, что данное предложение сгенерировано ИИ.
Не светить зарплатой - веяние последних лет 5ти, иногда даже это правило в ЛНА прописано. Но не везде так.
Не сказал бы. Его идеи об оптимизации процессов весьма очевидны, по крайней мере в настоящее время, и даже при оптимизации компьютерных программ применяются схожие идеи, но под другими именами (например, закон Амдала).
И откуда эта мода на непроверяемые метрики в резюме?..
Провёл 100 интервью с пользователями за год.
Сделал 5 CJM включающих каждый этап работы с продуктом по 50 шагов на каждой.
Построил стратегию на 3 года вперед.
Увеличил стоимость подписки на 30%, ввёл новый тариф.
И что HR будет делать с этой информацией? Сравнивать с другими? Тогда выгоднее писать как-то так:
Провёл 100500 интервью с пользователями за год.
Сделал 100600 CJM включающих каждый этап работы с продуктом по 100700 шагов на каждой.
Построил стратегию на 100800 лет вперед.
Увеличил стоимость подписки на 100900%, ввёл новый тариф.
Закрытую информацию проверить невозможно, т.е. HR сам обманываться рад. Так почему бы не "порадовать" HR завышенными показателями? У нас же не выдают сертификаты или дипломы за "Провёл 1000 интервью", "Увеличил конверсию на 1%".
Всё ещё не понял. KPI - процент от зарплаты? Значит, у них KPI в рублях измеряется? Тогда весь KPI идёт на премию?.. В чём смысл такого KPI для работодателя? И о формулах ничего конкретного не сказано в ТЗ...
Не пойму, к чему эти нарративы про "8ГБ хватит всем" и про киношки. Хабр же ещё не форум любителей соцсетей и кино?
Под мои задачи из области разработки 8ГБ с трудом хватало ещё в 2016, а сейчас я вижу, что коллегам 16 ГБ все чаще не хватает.
А потом истории про 8ГБ читают отделы закупок, и внезапно выдают "игровые" ноуты с 8ГБ.
Из-за того, что память стала дорогая, не стоит считать, что "8ГБ хватит всем". Уменьшение трат уменьшает качество. У меня куча историй про то, как экономили-экономили, а потом заказчик ушёл к конкурентам, которые смогли выдать лучший продукт, не будучи ограниченными в ресурсах.
Когда разработка работает без системы контроля версий - это не "массовый народный продукт", а "дно разработки". Бэкапы исходников скриптами, ручные объединения правок... Так лет 20-30 назад делали, за это время можно было внедрить git, в котором это автоматизировано общепринятым способом.
И большинство разработчиков всё-таки и git используют, и юнит-тесты пишут, даже на начальном уровне, что уж говорить о "середнячках". Да, есть очень простые проекты, где тесты не нужны, есть модули систем, где они малоприменимы, но обычно тесты полезны.
Не совсем так. Тимлид отвечает за результат команды (выполнение всех задач), а разработчик отвечает за поставленные лично ему задачи. Всегда можно построить процесс так, чтобы у каждого его фрагмента был ответственный. Важно то, что роль тимлида включает ответственность "за всё" (в пределах команды) и возможность смены исполнителя задачи, а роль разработчика не имеет отвественности за всю команду.
Хотя да, в некоторых организациях бывает, что члены команды разработки несут коллективную ответственность за косяки ближайших коллег, менеджеров, других отделов, коммерческого и генерального директоров и т.д., а тимлид не имеет полномочий делать даже замечания команде, но это некая нездоровая организация процесса.
Сейчас уже 5 ГГц в бусте, 14 ядер, и почти 5к ядер в видеокарте - это в ноутбуке трёхлетней давности. На десктопах до 6 ГГц. Прогресс ни в коем случае не остановился.
Ладно на С++ разница 3 раза. А если вы вдруг пишете такой код для CUDA и вместо double float (по 4 байта), то во втором варианте 32 точки считаются из памяти за 3 обращения, а в первом варианте - за 96! Потому что во втором варианте одновременные обращения идут рядом (xs[0..31], ys[0..31], zs[0..31]), и такие запросы к памяти объединяются, а во первом - обращения вперемешку (ps[0].x, ps[1].x, ... , ps[31].x, ps[0].y, ..., ps[0].z, ...) не объединяются, а кэша может и не быть (на старых картах).
Детерминированности производительности кода нет. На разных процессорах разных объём кэша - и это уже предпосылка к тому, что код будет выполняться за разное время. А ещё процессор может быть другой модели, предсказывать ветвления по-другому, иметь разное число АЛУ...
Именно поэтому первая рекомендация при оптимизации кода - первым делом выполнять профайлинг.
Не светить зарплатой - веяние последних лет 5ти, иногда даже это правило в ЛНА прописано. Но не везде так.
Не сказал бы. Его идеи об оптимизации процессов весьма очевидны, по крайней мере в настоящее время, и даже при оптимизации компьютерных программ применяются схожие идеи, но под другими именами (например, закон Амдала).
И откуда эта мода на непроверяемые метрики в резюме?..
И что HR будет делать с этой информацией? Сравнивать с другими? Тогда выгоднее писать как-то так:
Закрытую информацию проверить невозможно, т.е. HR сам обманываться рад. Так почему бы не "порадовать" HR завышенными показателями? У нас же не выдают сертификаты или дипломы за "Провёл 1000 интервью", "Увеличил конверсию на 1%".
Всё ещё не понял. KPI - процент от зарплаты? Значит, у них KPI в рублях измеряется? Тогда весь KPI идёт на премию?.. В чём смысл такого KPI для работодателя? И о формулах ничего конкретного не сказано в ТЗ...
Когда играл в "Чистый код" и проиграл...
Мне в каких-то медицинских бумагах когда-то написали то ли профессию "сотрудник", то ли должность "сотрудник".
Не пойму, к чему эти нарративы про "8ГБ хватит всем" и про киношки. Хабр же
ещёне форум любителей соцсетей и кино?Под мои задачи из области разработки 8ГБ с трудом хватало ещё в 2016, а сейчас я вижу, что коллегам 16 ГБ все чаще не хватает.
А потом истории про 8ГБ читают отделы закупок, и внезапно выдают "игровые" ноуты с 8ГБ.
Из-за того, что память стала дорогая, не стоит считать, что "8ГБ хватит всем". Уменьшение трат уменьшает качество. У меня куча историй про то, как экономили-экономили, а потом заказчик ушёл к конкурентам, которые смогли выдать лучший продукт, не будучи ограниченными в ресурсах.
8ГБ маловато для расчетов, которые занимают 30ГБ 😁
Ещё хорошо, что своп на nvme довольно быстро работает, и 100ГБ свопа конечно тормозят, но систему не вешают.
Бредовенько.
В 2023 году как-то купил 64ГБ DDR5, а теперь наблюдаю, как страдают те, у кого по 16ГБ.
Когда разработка работает без системы контроля версий - это не "массовый народный продукт", а "дно разработки". Бэкапы исходников скриптами, ручные объединения правок... Так лет 20-30 назад делали, за это время можно было внедрить git, в котором это автоматизировано общепринятым способом.
И большинство разработчиков всё-таки и git используют, и юнит-тесты пишут, даже на начальном уровне, что уж говорить о "середнячках". Да, есть очень простые проекты, где тесты не нужны, есть модули систем, где они малоприменимы, но обычно тесты полезны.
Не совсем так. Тимлид отвечает за результат команды (выполнение всех задач), а разработчик отвечает за поставленные лично ему задачи. Всегда можно построить процесс так, чтобы у каждого его фрагмента был ответственный. Важно то, что роль тимлида включает ответственность "за всё" (в пределах команды) и возможность смены исполнителя задачи, а роль разработчика не имеет отвественности за всю команду.
Хотя да, в некоторых организациях бывает, что члены команды разработки несут коллективную ответственность за косяки ближайших коллег, менеджеров, других отделов, коммерческого и генерального директоров и т.д., а тимлид не имеет полномочий делать даже замечания команде, но это некая нездоровая организация процесса.
Python почти не видно...
Только не при оптимизации.
я пробовал где-то в 2012 - тогда деление было реально дольше.
Сейчас уже 5 ГГц в бусте, 14 ядер, и почти 5к ядер в видеокарте - это в ноутбуке трёхлетней давности. На десктопах до 6 ГГц. Прогресс ни в коем случае не остановился.
Ладно на С++ разница 3 раза. А если вы вдруг пишете такой код для CUDA и вместо double float (по 4 байта), то во втором варианте 32 точки считаются из памяти за 3 обращения, а в первом варианте - за 96! Потому что во втором варианте одновременные обращения идут рядом (xs[0..31], ys[0..31], zs[0..31]), и такие запросы к памяти объединяются, а во первом - обращения вперемешку (ps[0].x, ps[1].x, ... , ps[31].x, ps[0].y, ..., ps[0].z, ...) не объединяются, а кэша может и не быть (на старых картах).
Детерминированности производительности кода нет. На разных процессорах разных объём кэша - и это уже предпосылка к тому, что код будет выполняться за разное время. А ещё процессор может быть другой модели, предсказывать ветвления по-другому, иметь разное число АЛУ...
Именно поэтому первая рекомендация при оптимизации кода - первым делом выполнять профайлинг.
возможно, что всё-таки получено 0 ожогов...
Достаточно упомянуть, что некоторые пельмени сразу с говном.Проблема "архитектуры в головах" в том, что она быстро забывается.