Гарна реалізація цієї ідеї = −40% маркет капа гугла
Бімба

Гарна спроба, мейт академі -_-

Допоки маю цікаві задачі/челенджі та мовливості/досвід, допоки вірю у ідею того, що роблю і кайфую від продукту. Вже більше 5ти років в одній конторі працюю(Люкс скіпнув за рік)
Як база, ще те, що компанія пиплачує ринкову зарплатню. Хоча, я декілька років працював з ЗП нижче ринку(по моїх позиціях), але я був молодий(в 20 років складно отримувати умовні 5к на ринку), кайфував від роботи та розумів, що я отримую безцінний досвід

Да, тут важный момент — степень выполнения, например, как часто в дедлайны не попадает, или как часто качество хромает, что потом нужно что-то переделывать
Последний абзац как раз про это

По своему лидовскому и менеджерскому опыту, то лоу перформер — это тот, который не выполняет хотя-бы одно из следующих условий:
1. Работа выполнена с ожидаемым качеством.
Тут у каждого проекта/команды свои DoD, для меня:
a. Нужные требования покрыты и проверены
б. Материалы/информация для быстрого внедрения и проверки результата приложены(зависимости и доказательства работоспособности)
в. Лучшие практики/правила команды использованы(тут нужно иметь хорошее код ревью)
2. Работа выполняется в оговоренные сроки.
а. Важно прививать культуру коммитментов, чтобы инженер подтверждал, что он действительно ожидает, что за это время выполнит задачу, иначе, если есть неучтенные риски, то он скажет, что займет больше времени и вы на этом сойдетесь. Потому что, в обратном случае, задачи просто будут переноситься и план будет липовым, так как мы не контролируем его выполнение на фундаментальном уровне — инженером
б. Задачи могут выполняться дольше, чем у других и это необязательно значит, что инженер лоу перформер, например, у меня в команде был инженер, в котором я уверен на 100%, что он решит любую задачу и выполнит качественно, но ему на это нужно было потратить больше времени, так как он должен осмыслить задачу полностью, думать, как задача, стать ею и такого точно не назовешь лоу перформером, просто у него больше предрасположенность к такому типу решения задач и важно иметь таких инженеров, помимо скоростных джунов/мидлов
3. Работа выполняется на ожидаемом уровне автономности.
а. Автономность подразумевается в том виде, что инженер не будет задавать вопросы на каждый чих, а будет стараться сам разбираться и не тратить время коллег, но при этом, если уже в тупике, то задаст вопрос, так как это позволит задачу выполнить в срок. Для этого вывел простое правило: «Если за пол часа нет никаких продвижений в проблеме — задавай вопросы», что в свою очередь держит баланс между тем, чтобы инженер сам учился решать проблемы и был самостоятельным и тем, что задачи не будут зависать, от чего все дедлайны будут завалены
б. Со стороны лида, в данном случае, следует делать инструкции и треннинги, в которых будут описаны все основные проблемы/задачи, как их решать или где найти решение
в. Для меня это главный фактор профессионализма
Так что, если хотите получить повышение зарплаты, в рамках текущей компании — решайте задачи, не делая проблем, доверие вам и ваша важность будут расти(будут давать более сложные и интересные задачи) и у компании не останется выбора не повышать вам зарплаты(если они не идиоты, конечно)

Это каркас формулы, дальше, если хотим рассматривать конкретные примеры, чтобы давать поблажки в определенных пунктах или наоборот требовать больше в других, то мы должны учитывать:
1. Опыт
2. Опыт в текущей команде/проекте
3. Ситуация внутри команды/проекта(например, на домен лиде куча всего и он не может постоянно поддерживать, то автономность становится важнее)

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

Насколько я помню, по разным книжкам, Нейронные сети — это подмножество Машинного обучение, что в свою очередь подмножество ИИ
ospreydata.com/...​dels-101-what-is-a-model

Покупал бренд, видимо

Да, никто не спорит с этим, виновата в любом случае росия
Я про человеческие реакции, что даже с учетом того, что мы пытались сбить руские ракеты, люди могут негативно отреагировать в сторону Украины, что в итоге может уменьшить помощь Украине

Похоже, все идет к тому, что ракеты были запущены со стороны Украины, видны были осколки С300 ракет, которые используются для ПВО
Это грустно и ужасно:( Но все понимают, что это произошло из-за бомбежек со стороны росии
Наверное, это все таки ударит по нашей репутации и поставки могут уменьшиться:..(

projecteuler.net

Классика!

«Проект Аве Мария» крутейшая книга, думаю, через пол года-год перечитаю
Пожалуй, лучший сайнс фикшн, что я прочел

Сейчас читаю: Форд «Моя жизнь мои достижения» — не со всеми мыслями согласен, но много интересной информации, он был гением
На днях прочел Васильев «В списках не значился» — сильная книга, она про защиту Брестской крепости, не понравилось только возвеличивание совка

Да да, согласен, тут уже зависит от приоритетов, лично для меня драйвово, когда постоянно есть какой-то вызов, какие-то проблемы и их нужно решить, я часто переходил по ролям, даже без какого-то оговоренного повышения ЗП, просто в голове понимал, что чем больше будет мой вес в конторе, тем больше мне будут платить в скором времени, так и вышло.
Так что, да, у каждого свои мотивации, приоритеты и желания, главное, чтобы каждому нравилось, чем он занимается

Никто не спорит, что инженеры дают результат и что без инженеров остальные специалисты не нужны, но одним разработчикам, без менеджера, будет трудно сделать большой проект самим.
Для себя я вывел, следующее:
Разработчики в основном смотрят на проект в разрезе спринта, максимум нескольких
Тимлиды в разрезе спринта и итерации
Менеджеры в разрезе итераций и целого проекта

Когда ты имеешь несколько ролей и следишь, например, за спринтом, итерацией и проектом, то мозг начинает вскипать, потому что на каждом уровне разные инструменты и способы мышления

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

Поэтому должны быть люди, которые направляют, в какую сторону все должны двигаться, чтобы достичь долгосрочную цель, люди, которые сфокусированы на этом, замотивированы, иначе все будут просто решать интересные задачки, которые необязательно дадут большое продвижение до главной цели.
Нужны люди, которые высокоуровнево могут решить конфликты между командами, кто что должен делать.

Если проект движется в неправильном направлении — то разработчики не смогут этого исправить, просто потому что они не имеют нужных инструментов, да это и не их обязаности.

Он сказал «больше платят», тут скорее нужно создавать тренинг по инвестициям

Подскажите, а вы налоговый резидент Британии? Или есть какой-то формальный способ не платить налоги

Аж противно читать

Вы крутейшие!!

Меньше денег будут получать:)