А при чём тут "мода", или "новость", когда пик на половозрастной пирамиде движется вверх? Выбора-то особо и нет. Уверен, среди этих "новых" работников ещё и женщин чуть больше, чем мужчин.
В Rust работа над качеством/безопасностью кода сдвигается на более ранний этап, в прототип программы. Нет вариантов сделать MVP, не потратив время на качество кода. С этой стороны, Rust менее пригоден для продуктовой разработки, по крайней мере, на начальном этапе.
С другой стороны, код-решето даже в прототипе создаст массу проблем, и на их исправление времени уйдёт вероятно даже больше, чем было бы потрачено на борьбу с компилятором Rust. В пользу этой точки зрения можно зачесть тот факт, что Rust стабильно побеждает на ICFP Programming Contest.
Что заставляет думать, что при таком подходе мы не сорвем этот (и последующие) дедлайны?
Смысл не в несрыве дедлайнов, а в хорошей отчётности руководству. В отчёте может быть что-то вроде "построили стабильные процессы, уволили токсичного сотрудника, сделали шаги в сторону масштабирования разработки, работаем над эффективностью, нанятая команда джунов быстро разберётся в предметной области не хуже этих старых, которые работать не умели". А после хороших отчётов можно и деньги просить.
На своем опыте работы в разных компаниях ни разу не встречал случаев, когда зарплаты друг перед другом светят. Подозреваю, что данное предложение сгенерировано ИИ.
Не светить зарплатой - веяние последних лет 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 используют, и юнит-тесты пишут, даже на начальном уровне, что уж говорить о "середнячках". Да, есть очень простые проекты, где тесты не нужны, есть модули систем, где они малоприменимы, но обычно тесты полезны.
Не совсем так. Тимлид отвечает за результат команды (выполнение всех задач), а разработчик отвечает за поставленные лично ему задачи. Всегда можно построить процесс так, чтобы у каждого его фрагмента был ответственный. Важно то, что роль тимлида включает ответственность "за всё" (в пределах команды) и возможность смены исполнителя задачи, а роль разработчика не имеет отвественности за всю команду.
Хотя да, в некоторых организациях бывает, что члены команды разработки несут коллективную ответственность за косяки ближайших коллег, менеджеров, других отделов, коммерческого и генерального директоров и т.д., а тимлид не имеет полномочий делать даже замечания команде, но это некая нездоровая организация процесса.
Как такое возможно??
Авито и всего провайдера иногда успешно блокирует.
А при чём тут "мода", или "новость", когда пик на половозрастной пирамиде движется вверх? Выбора-то особо и нет. Уверен, среди этих "новых" работников ещё и женщин чуть больше, чем мужчин.
Интересная идея.
В Rust работа над качеством/безопасностью кода сдвигается на более ранний этап, в прототип программы. Нет вариантов сделать MVP, не потратив время на качество кода. С этой стороны, Rust менее пригоден для продуктовой разработки, по крайней мере, на начальном этапе.
С другой стороны, код-решето даже в прототипе создаст массу проблем, и на их исправление времени уйдёт вероятно даже больше, чем было бы потрачено на борьбу с компилятором Rust. В пользу этой точки зрения можно зачесть тот факт, что Rust стабильно побеждает на ICFP Programming Contest.
Да никак)
Вот вы 1 апреля шутите, а ведь кое-где эти советы уже используются 😅
Смысл не в несрыве дедлайнов, а в хорошей отчётности руководству. В отчёте может быть что-то вроде "построили стабильные процессы, уволили токсичного сотрудника, сделали шаги в сторону масштабирования разработки, работаем над эффективностью, нанятая команда джунов быстро разберётся в предметной области не хуже этих старых, которые работать не умели". А после хороших отчётов можно и деньги просить.
Не светить зарплатой - веяние последних лет 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 почти не видно...
Только не при оптимизации.