SHIFU

Интересную мысль услышал у Токовинина (сооснователь AmoCRM) Хорошие сотрудники - это те о ком никто не помнит, их никто не трогает, так как они и так хорошо делают свою работу. Именно о них забывают, когда встает вопрос кого премировать. Токовинин предлагает другую схему. Постоянно повышать зарплату всем...

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

- Предстоит создать платформу, которая позволит гражданину получать все преимущества системы здравоохранения, получать онлайн-консультации специалистов ведущих медцентров. Задача сделать их массовыми. К 2030 году создать онлайн-платформы во всех отраслях. Это новый нацпроект «Экономика данных - В сфере ИИ мы тоже должны быть самодостаточны. Это должен быть настоящий прорыв. - Темпы роста инвестиций в IТ-решения «должны в два раза превышать инвестиции в экономику» - В условиях дефицита кадров надо повысить производительность труда, внедрять цифровые технологии - На это должны быть нацелены инженерные школы...

Важно - в данной статье речь о людях с опытом в ИТ, не о новичках. В процессе исследования об эйджизме в IT, пообщался с старым товарищем, он сейчас занимает руководящую позицию в Ozon, и вот вам его слова: - Лично знаю пару примеров таких людей. Но, мне кажется, что возраст тут практически не влияет у нормального руководителя. От себя хочу...

Сейчас нужно быстро учиться (с) хз кто Услышал эту фразу, и сильно она мне в душу запала, она полностью соответствует ощущению, которое не отпускает уже порядка года. Сейчас такой поток информации - количество книг, курсов и видосов на ютуб растет в геометрической прогрессии. В определенный момент появляется несколько мыслей: - Мне это все никогда не прочитать/изучить - А нужно ли изучать это все? Для первого тезиса - действительно, важна скорость, чтобы успеть перелопатить БЕСКОНЕЧНЫЙ информационный поток...

Сейчас многие беспокоятся по поводу вранья в резюме. И тут есть три позиции - тех кто врет, тех кто работает с их кодовой базой, и компании, в которые эти люди попали. В этом посте я не собираюсь давать оценку данному подходу, лишь напишу пару всем известных фактов. Факт 1: Коллеги из Индии делают это уже более 10 лет (из того что лично видел). У них это поставлено на конвеер. Способов как на*ать … убедить интервьюера масса...

Я частенько покупаю курсы по программированию, и тут есть два вида. Первый вид курсов: Платишь 30/40/50 тысяч, курс идет пару месяцев. Это объемные уроки с домашками и тп. Второй вид курсов: Покупаешь доступ за 15-20к на постоянно. Это просто набор предзаписанных материалов, мелкими кусками, причем в большом количестве (без домашек и прочего) Типа totaltypescript или epicreact. Второй тип, если честно, мне нравится больше. Дело в том, что времени как обычно ни на что не хватает. С такой подачей материала я смотрю видео по темам, которые меня больше всего беспокоят в данный момент. Получается этакий набор решений, которые можно изучать по необходимости...

А теперь квинт-эссенция ошибок… Когда разработчик пилит проект, он видит свою часть задач, когда тимлид смотрит на то как работает команда, он видит общий результат. А дьявол кроется в деталях, и вот пример: Фронтендеру сказали разверстать и прикрутить логику к интерфейсу. И задача кажется вполне понятной и простой - 3 дня на разработку. После изучения макетов и документации, он приступает к работе. Но, у него появляются вопросы, которые не очевидны в доках, или не были там учтены. Он обращается за консультацией к аналитикам. Получив информацию, выясняется что есть ошибки в макетах. Он обращается к дизайнеру...

Еще один момент, он не самый критичный (критичный будет дальше), но не могу не упомянуть… Программист в режиме разработки стартапа и в режиме поддержки - разная рабочая единица. Даже войти в этот режим (если он вообще соберется в него входить) - требует времени. И нет, не за день… И получается, что мы берем программистов, которые привыкли к определенному рабочему процессу: Кодревьюить, следить за архитектурой, выделять время на ресерч, тесты писать, ничего не делать, ой… неторопиться. И заявляем им - с завтрашнего дня пилим стартап, тесты нахрен, на архитектуру нет времени, качества кода жертвуем в угоду времени, и спрашивать за ваши результаты я буду каждый день...

Как формировалась команда? Нет, не было создано группы для штурма проекта из супер-скилловых замотивированных синьоров. Часто делают или связку из 1 синьора + 2-3 джуна-мидла на один стек. Иногда ставят мидлов, а синьора привлекают уже когда все плохо. Почему? Потому что в компанию не были набраны ресурсы для старта проекта. Людей снимали с текущих проектов, или по быстрому искали на рынке труда тех, кого можно быстро схватить (а схватить быстро хорошего спеца - это удача). Когда у руководства появляется...

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