Обновить
2
0.5

Пользователь

Отправить сообщение

А что удивительного?

Настроим процессы, при которых сотрудники (добровольно и с песней) исполняют обязанности менеджеров. На менеджерских ЗП сэкономим.

Ну ок, а все ли хотят "добровльно и с песней" нетипичные для себя обязанности?

Ну так настоящий банан во-первых "недостаточно банановый", а во вторых с изъянами: некритичными в видео, но в застывшем кадре, да ещё и в глянце бросающимися в глаза.

У меня дом в 2019 году сдан.
40А заведено в квартиру

Есть ещё один момент, который далеко не очевиден тем, кто хочет "войтивайти".
В IT вы действительно работаете головой, что предполагает высокую мысленную концентрацию, всё время работы.

И если ты "не хочешь копамть" или "не хочешь грузить вагоны" - то ничего страшного, взял ноги в руки и пошёл копать / грузить (пишу это как человек занимавшийся этим в армии).

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


Updated:
Это я к тому, что поддерживаю общий посыл автора поста - идти в IT (а особенно в программирование) сегодня в 2025 году имеет смысл только если вас от этого самого программирования прёт.
В противном случае вы соберёте очень много минусов от "программист моя нелюбимая профессия" и довольно немного плюсов.

Спасибо за пояснения (сначала не так прочитал).

Вообще план был (и работал) с 2005 по 2015 примерно такой:
1. Платить год выше рынка (джуну тоже надо кушать);
2. Платить следующий год ниже рынка (по итогу 2 лет выйти в 0);
3. Потом переходить на историю "платить в рынке".

К этому плану обе стороны относились с пониманием.

Когда в 2020 массово пошли вкатыши, с другой трудовой этикой - работодатель приспособился.

В этой истории, как и в любой истории с массовым микро-обманом на грани мошенничества, пострадавшими являются добросовестные кандидаты, что грустно.

Как вы перешли от "не согласен платить выше приносимой пользы авансом (т.к. он уйдёт)" к "план платить ниже рынка"?

Приведите цепочку рассуждений пожалуйста. Она мне сильно не очевидна.

Благодаря известным событиям 22 года бизнес лишился возможности проводить хоть какое-то дообучение

Возможности обучать у бизнеса есть. А вот резона нет.
Взял вкатыша, назначил ему ЗП авансом на будущее, дообучал его 6 месяцев...
А через год (а этот год он получал ЗП выше чем стоит) - он решил что достоин лучшего грейда (ты же его дообучил, т.е. он теперь лучший специалист) - и ушёл в другую кампанию.

Работодатели, - люди которые умеют считать деньги, - считают, что этот план такой себе, не очень.

Да как хотите обращайтесь риски на вас.

А вот когда пришли по гарантии к производителю - там и смотрят на шарик.
Шарик не на месте - негарантийный случай.

Ответа на вопрос как отсеять вкатунов-врунов (и не повыкидывать нормальных кандидатов) вы не дали. Подозреваю, что его у вас нет.

Приведите факты, что кто-то ворует код джунов в продакшн. Вместе посмеёмся.

Типичная ситуация:
1. разместили джуниорскую вакансию
2. получили 200-1000 резюме от людей 90% которых:
- а) программистами не являются и на вакансию не подходят;
- б) о своём опыте программирования, изученных технологиях и т.д. банально наврали в резюме - чтобы пройти формальный фильтр.

Т.е. получили 200 - 1000 резюме, людей, которых формально надо бы отсобеседовать.


Это минимум человеко-месяц миддл-разработчика (если верить тому, что написано в резюме).

Кампании пошли простым путём - поставили фильтр, который чуть сложнее подделать "тестовое задание".

Если у вас есть лучшие предложения для кампаний : как не тратить 300_000 - 1_000_000 рублей на просмотр кандидатов - поделитесь пожалуйста, также учтите что решение должно быть устойчиво к обоим видам "ошибок":
- уверенно врущий вкатун без знаний;
- боле-менее знающий но честный самоучка;

Я сомневаюсь, что ваше "хорошо" - совпадает с целевой функцией людей проводивших тест.

Вот только что посмотрел в вики метод (ну в принципе основная идея ясна, хоть и мельчить ближе к листам не всегда полезно) и... мне трудно придумать реальную задачку на van Emde Boas tree кроме как "реализуйте van Emde Boas tree".

Вообще человек пробовал много разного - и маркетинговый буллщит в виде чеклистов не подошёл, а помогли просто правильные подходы:
- думать, читать документацию, планировать, общатсья с командой (в примере как часть планирования).

Как я понял помогли 3 вещи:
1. Начал думать - силы думать появились после того, как начал высыпаться.
2. Стал читать документацию
3. Стал уделять больше времени планированию (в случае автора больше 0).

- У нас есть плохой программист, к тому же неуживчивый (ошибается и отказывается признавать свою неправоту), что с ним делать?
- Давайте сделаем менеджером
- Давайте, но чур в другом отделе

Человека, который не понимает концепции вычислительной сложности и написания "алгоритмического" кода в целом - я бы не взял знание конкретных терминов не так важно (автора статьи, по некоторым звоночкам, скорее всего тоже).

Разумеется при любой работе (скажем у меня в бытность написания компилятора) разные алгоритмы занимали не более 10% времени. Но горе тому, кто их не знает - ваш уровень определяется не "медианной" решаемой задачей, а самой сложной задачей, которую вы можете решить самостоятельно.

Опять же человек плохо понимающий программирование - не только n^2 vs n*log(n) походя путает, а спокойно и не задумываясь выдаёт код с экспоненциальной сложностью если задача становится минимально сложнее и хоть чуть-чуть нестандартной (особенно остро это у людей, любящих заучивать паттерны проявляется).

Ну и про сравнение "алгоритма" с прерыванием потока исполнения - вы же понимаете, что этим примером побеждаете соломенное чучело и прерывание потока исполнения на условный SQL-запрос / execve / whatsoever - точки о которых безусловно надо помнить.

Напоследок (к комментарию ниже): паттернам уровня "x === null" можно же научиться за 1 день, а вот если выяснилось, что "программист" не умеет писать алгоритмы - ваш уровень проблем сразу превращается "мы наняли писать код человека, программистом не являющегося".

Ещё раз про главное: моя мысль, с конкретным примером, что говорить "active loop" отстой - это крайне поверхностное суждение.

0.
смотреть лучше не futex, а: https://en.wikipedia.org/wiki/PREEMPT_RT - теперь этот режим основной в linux Kernel.

1.
Про futex есть два понятия: "Computer Science примитив futex" и "linux/futex.h :: futex". Вот первый я имел в виду когда говорил во что spin_lock развернётся - забыв что вы из мира Win и по контексту не поймёте.

2.
Сейчас spin_lock (примитив ядра), разворачивается через 10 слоёв абстракций в очередь ждущих воркеров и снимается с CPU (в режиме PREEMT_RT который сейчас включен по-умолчанию, разумеется там ещё 100500 действий типа повышения приоритета и т.п.).

3.
Т.е. по-сути сейчас:
- spin_lock (примитив ядра) - покрутится на active loop и уйдёт в preemption (*)
- mutex (примитив pthread) - покрутится на active loop и уйдёт в preemption


*) В реализации по-умолчанию, если вы не заблокировали irq && preemption......

Теперь уже практически любой лок работает так:1. Некоторое время T ждём на спинлоке (это фактически active pooling)2. Потом снимаемся с процесса и ждём на примитиве ядра.

> Это если вы используете какой-нибудь язык с навороченной средой выполнения, типа C#, или библиотеку. На голом C(++) надо или самому делать такие вещи, или пользоваться тем, что в ОС есть.

Слушайте вы даже не поняли, что это описание работы spin lock (из linux kernel) и mutex (из pthred).
Рассказываете "как на самом деле" работают блокировки.

А им там просто ничего не остается,

Остаётся, и я это явно описал в своём ответе.
Спин лок через какое-то время просто кладёт просит кладёт воркер в очередь фьюекса.
Мьютек тоже сначала крутится на спин-локе, а потом кладёт pid в очередь фьютекса.

В том-то и дело, что из-за существования временной локальности (ровно то, благодаря чему кэши приносят пользу) - идея "покрутиться на спин-локе" / "чуть-чуть поделать active pooling" - достаточно разумная.

И очень быстро в описанной Вами ситуации наткнёмся на феномен, который без вмешательства бога не объяснить.

Вы можете это утверждение доказать?

Информация

В рейтинге
2 028-й
Зарегистрирован
Активность