Яндекс большой. Не припомню оплаты за переработки, а вот код ревью, пройденное в чпс ночи - вполне себе рабочая ситуация. Но и оценку на ревью, привязанную к переработкам тоже не припомню. Работать в любой время и день недели нормальная практика в разных командах. На счет 1,5-2 за переработки - встречал такой только раз в Luxoft и то далеко не везде и далеко не за регулярные пару часов после работы. И это за 28 лет.
А у нас в команде... Командные встречи занимают час по понедельникам и 5-20 минут ежедневно. Если приходит условнгый босс на дейлик, то сразу 30+ минут. Вот сижу думаю как вежливо послать или договориться о более редком посещении. Еженедельные статусы с продактами и смежными командами отменяю, если могу. Они нужны лишь чтобы забронировать время владельцев процессов и спонсора проекта. Часто меняю на 1x1 вместо статуса на 10 человек. Когда регулярно освобождаешь время людям с плотным календарём они становятся более отзывчивыми. По вопросам приветствуется приходить в личку. Можно парно покодить, просто попросить подсказать мелочь, если ты знаешь, что коллега имеет хорошие компетенции в этой области. Отладка и разбор инцидентов часто на двоих. Реже на троих. Переписка в чате на 5+ минут часто заменяется быстрой встречей с записью итогов. Отклик с месенджере ожидается в течение 10 мин. Если занят можешь просто написать попозже или завтра. Так было не всегда. Были и забитые на 35 часов в неделю календари. Очень сильно зависит от компании, клиента, твоей позиции, полномочий. Основные фичи для улучшения: 1. общаться напрямую минуя иерархию 2. можно пропустить регулярную встречу кроме дейлика, если не видишь в это ценности или тебя отдельно не попросили прийти
Я был студентом, зарабатывал на 1С и прямо мучился с дискетами. Такой привод был несбыточной мечтой. Как-то раз клиент приходил с таким в офис. Нам тогда даже в голову не приходило уломать шефа даже на один такой девайс.
1. Я думаю, что правительство США считает лидерство в ИИ стратегическим преимуществом и готово поддерживать развитие, притормаживать по возможности конкурентов. Поэтому и появились аналогии с холодной войной. Аля гонка за большие деньги. Кстати, что там с этой гонкой после 50-х в разгар холодной войны? Какие преимущества она приносила? Понятно, что пока за тобой бегут останавливаться нельзя. Именно лидер снимает все пенки. Так и тут. А где сравнение с ткацким станком и паровым двигателем? Или авиацией? Эффект огромный, инвестиции меньше на порядки. Так что аргумент про сумму не принимается, особенно без сопоставления ВВП, а он для США вырос в 6-10 раз с середины 1940-х. Смотря как считать.
Давайте сравним с интернетом, как последней технологией, которая существенно изменила мир. 1969 ARPANET
В целом отлично, но... При мелких правках руками в рамках файла в агентском режиме они потом часто затираются. Помогает описание правки в комментариях. Вот прямо написать какая ошибка исправлена или функционал дополнен. Ну и про МСP не хватает. Еслли для браузера встроенного агента добавили, то длля БД, figma и прочих радостей всё равно подключать надо. И бывают нюансы, если хочешь подключиться сразу к нескольким БД.
Формат, когда каждый ученик идёт в своём темпе отлично применим для 6-8 человек. С трудом для 12+. Я видел только одного педагога, у которого получалось делать это с 22-мя, но получалось так себе. Возможно, если заменить значительную часть вклада наставника интерактивным взаимодействием и предметом изучения получится немного лучше. Но пременимо мало где.
У меня родной Русский. Могу писать на немецком и Английском. Пробовал писать по испански. Меня не особо понимают. Слишколм много ошибок и не так быстро, как я ожидал. Условый вайбкодинг тоже требует определённых навыков. Управление контекстом, установка и использование MCP, разные роли для разных агентов, в код всё же нужно поглядывать, навыки применения TDD. Сам люблю почитать код, но всё чаще замечаю, что вычитавыаю внимательно лишь изменения в ключевых частях, а с остальным просто соглашаюсь и запускаю тест. Для продуктовых экспериментов этого достаточно, а до красивого продового состояния есть кому довести.
Немного по другому. Если ты отлично работал с 400+ людьми, то у кого-то их них найдётся место в команде. Ну или у его хорошего знакомого. И это будет не просто рефералка, а готовность поработать с тобой ещё раз. Пусть ты был хреновым работником на нескольких проектах, но и отличные тоже должны быть. Опыт совместной продуктивной работы и репутация огромный плюс. 85 этапов интервью такой фильтр не заменят. Вот у меня список и не маленький таких людей. Когда ищу кого-то в команду - обращаюсь прежде всего к ним. Когда ишу работу - к ним же.
Это внеоборотный актив. Его остаточная стоимость зависит не только от износа, но и ликвидной стоимости. Например, если производительность на доллар вырастет в 10 раз, то и ваш дата центр сильно подешевеет. Поэтому, производитьель может убить бизнес своих клиентов, выпустив более мощное оборудование. Для вычислительной техники в мире принято брать сроки от 3-х до 10-ти лет.
Вариант 4 из книги конечно красив, но точно не для обычной школы. Метод подобия по мне вполне нормален для школьников. Ньютон когда-то гравитационную и инерциальную массу прировнял доказывая закон всемирного тяготения, но большинство жителей планеты про это ни разу не слышали. С геометрией в школах нынче туго. Особенно со стереометрией. Связано с тем, что стали на порядки меньше рисовать. Те, кто ходят в художку, обычно на голову сильнее одноклассников в части геометрии. В таком контексте переход на алгебраические методы доказательства вполне уместен.
Про каркас аля как было принято в Паскале +1. Я с курсором попробовал в процелурное программирование сверху вниз с вкраплениями функционально. Получается отлично. Про автозапуск субагентов звучит прекрасно. Попробую. Сейчас запускаю руками.
Всё немного не так. Google за третий квартал 2025: Чистая прибыль (Net Income):$35.0 млрд (+33% г/г) Capex за Q3 2025:$24 млрд. Пока вложения в дата центры хорошо обиваются. Маржа Google Cloud 23,7%
Мне с ИИ помогает написание в процедурном стиле сверху вниз. Вот как раз начиная с архитектуры решения и заканчивая мелочами. Косячит на всех уровнях и это нормально. Субъективная оценка в 5-8% случаев. Помогают тесты. Наверное, в вашем случае архитектурных решений просто меньше, чем решений как написать что-то простое. С большинством простых задач справляется нормально, но иногда прямо дикие ляпы пролетают.
Пришлось нынче срочно искать работу при закрытии проекта. Ну такое себе. Отклики просто в пустоту. В личку пришла HR с вакансией ниже по грейду текущей на 2 ступеньки через месяц публикации. Один отклик за месяц! Реальные варианты которые сработали - запустить стартап, сходить в личку к всем контактам, с которыми продуктивно работал последние 4 года. Если по работе ваш круг общения ограничен вашей командой, то придётся существенно сложнее.
Занимаюсь доставкой во Вкусвилл и хорошие практики: 1. 4-5 дарксторов в тестовой группе и столько же, с похожими метриками, в контрольной. 2. Фича фриз по тестовой и контрольной группе на время проведения. Тест минимум 2 недели. Оперативность хромает. Когда делаешь MVP 3 месяца и из них 2 недели занимает A/B с фича фризом, то не сильно рад такому подходу. Больше нравится делить тестовую и контрольную группу не по магазинам, а по отдельным курьерам, или выкатить фичу только на часть зоны доставки дарка. Проходит в одно и то же время, в одинаковых погодных условиях, сборка заказов работает равномерно для обоих частей. Число контрольных метрик в таком случае сразу резко сокращается. А какие методики проверки продуктовых гипотез кроме A/B тестов вы ещё применяете?
Что-то я потерялся несколько раз, пока читал статью. Было 1. Команда не понимает контеста 2. Документация отсутствет (а вроде как должна появляться до разработки на этапе системного анализа) 3. Пинг-понг между тестированием и разработкой (DoD в задаче не фиксировался? Какой аретфакт на входе у тестировщика? Разраб базово не проверят что он сделал?) 4. Проблемы с документацией И при чём тут слово Agile, если базовый Delivery процесс сломан, вовлечённость хромает?
Я как-то с парашютистами - спортсменами летел. С их слов, без стабильного полёта не спасёшься. То есть, это как минимум достаточная высота, работающая механизация крыла и стабильный полёт, что не типично для катастрофы. Достаточно случаев, когда самолёт при прыжках парашютистов валился в штопор и они не могли из него выпрыгнуть. А вот практика general aviation, когда спускают самолёт целиком, вполне рабочая. Ну будет 5-6 парашютов вместо одного и что? Масса такой системы порядка 0,5-1,5% от взлетной.
Меня тоже такая мысль посещала при прочтении, но история с переездом с Оракла куда-то вполне закрывает этот вопрос. ПОдходит только то, что потребует меньше изменений и есть нормальные компетенции в команде. Ну и вариантов кроме OLTP to OLTP без серьёзных переработок не остаётся.
Пусть нормальная работа означает «делаю свое дело хорошо, расту, отдыхаю, заряжаюсь и получаю результат», а не «постоянно страдаю».
Я вот от работы заряжаюсь и вдохновляюсь. Понятно, что надо ещё спать, нормально питаться, двигаться, уделять время семье. Но отличный результат получается когда именно вдохновлённо и при этом осмыслено фигачишь. Условно если хочешь забраться на эверест, то не получится сделать это на чиле. И вспоминаться будет не только достижение, но и процесс. Потом обязательно надо буджет отдохнуть и восстановиться, не забыть, что надо оставить силы на спуск и пр. Это само с опытом приходит. Ну и жить на вершине - так себе история.
Яндекс большой. Не припомню оплаты за переработки, а вот код ревью, пройденное в чпс ночи - вполне себе рабочая ситуация. Но и оценку на ревью, привязанную к переработкам тоже не припомню. Работать в любой время и день недели нормальная практика в разных командах.
На счет 1,5-2 за переработки - встречал такой только раз в Luxoft и то далеко не везде и далеко не за регулярные пару часов после работы. И это за 28 лет.
А у нас в команде...
Командные встречи занимают час по понедельникам и 5-20 минут ежедневно.
Если приходит условнгый босс на дейлик, то сразу 30+ минут. Вот сижу думаю как вежливо послать или договориться о более редком посещении.
Еженедельные статусы с продактами и смежными командами отменяю, если могу. Они нужны лишь чтобы забронировать время владельцев процессов и спонсора проекта. Часто меняю на 1x1 вместо статуса на 10 человек. Когда регулярно освобождаешь время людям с плотным календарём они становятся более отзывчивыми.
По вопросам приветствуется приходить в личку. Можно парно покодить, просто попросить подсказать мелочь, если ты знаешь, что коллега имеет хорошие компетенции в этой области.
Отладка и разбор инцидентов часто на двоих. Реже на троих.
Переписка в чате на 5+ минут часто заменяется быстрой встречей с записью итогов.
Отклик с месенджере ожидается в течение 10 мин. Если занят можешь просто написать попозже или завтра.
Так было не всегда. Были и забитые на 35 часов в неделю календари. Очень сильно зависит от компании, клиента, твоей позиции, полномочий.
Основные фичи для улучшения:
1. общаться напрямую минуя иерархию
2. можно пропустить регулярную встречу кроме дейлика, если не видишь в это ценности или тебя отдельно не попросили прийти
Я был студентом, зарабатывал на 1С и прямо мучился с дискетами. Такой привод был несбыточной мечтой. Как-то раз клиент приходил с таким в офис. Нам тогда даже в голову не приходило уломать шефа даже на один такой девайс.
1. Я думаю, что правительство США считает лидерство в ИИ стратегическим преимуществом и готово поддерживать развитие, притормаживать по возможности конкурентов. Поэтому и появились аналогии с холодной войной. Аля гонка за большие деньги.
Кстати, что там с этой гонкой после 50-х в разгар холодной войны? Какие преимущества она приносила? Понятно, что пока за тобой бегут останавливаться нельзя. Именно лидер снимает все пенки. Так и тут.
А где сравнение с ткацким станком и паровым двигателем? Или авиацией?
Эффект огромный, инвестиции меньше на порядки. Так что аргумент про сумму не принимается, особенно без сопоставления ВВП, а он для США вырос в 6-10 раз с середины 1940-х. Смотря как считать.
Давайте сравним с интернетом, как последней технологией, которая существенно изменила мир.
1969 ARPANET
1984 NSFNET
1991 WWW
1992 - коммерциализация и развитие рынка по экспоненте года до 2012-го
В целом отлично, но... При мелких правках руками в рамках файла в агентском режиме они потом часто затираются. Помогает описание правки в комментариях. Вот прямо написать какая ошибка исправлена или функционал дополнен. Ну и про МСP не хватает. Еслли для браузера встроенного агента добавили, то длля БД, figma и прочих радостей всё равно подключать надо. И бывают нюансы, если хочешь подключиться сразу к нескольким БД.
Формат, когда каждый ученик идёт в своём темпе отлично применим для 6-8 человек. С трудом для 12+. Я видел только одного педагога, у которого получалось делать это с 22-мя, но получалось так себе. Возможно, если заменить значительную часть вклада наставника интерактивным взаимодействием и предметом изучения получится немного лучше. Но пременимо мало где.
У меня родной Русский. Могу писать на немецком и Английском. Пробовал писать по испански. Меня не особо понимают. Слишколм много ошибок и не так быстро, как я ожидал.
Условый вайбкодинг тоже требует определённых навыков. Управление контекстом, установка и использование MCP, разные роли для разных агентов, в код всё же нужно поглядывать, навыки применения TDD.
Сам люблю почитать код, но всё чаще замечаю, что вычитавыаю внимательно лишь изменения в ключевых частях, а с остальным просто соглашаюсь и запускаю тест. Для продуктовых экспериментов этого достаточно, а до красивого продового состояния есть кому довести.
Немного по другому. Если ты отлично работал с 400+ людьми, то у кого-то их них найдётся место в команде. Ну или у его хорошего знакомого. И это будет не просто рефералка, а готовность поработать с тобой ещё раз. Пусть ты был хреновым работником на нескольких проектах, но и отличные тоже должны быть.
Опыт совместной продуктивной работы и репутация огромный плюс. 85 этапов интервью такой фильтр не заменят.
Вот у меня список и не маленький таких людей. Когда ищу кого-то в команду - обращаюсь прежде всего к ним. Когда ишу работу - к ним же.
К тесрированию вопросы, но мой любимчик для кода Opus 4.5. На стадии планирования Gemini 3 Pro, для отладки Sonet 4.5
Это внеоборотный актив. Его остаточная стоимость зависит не только от износа, но и ликвидной стоимости. Например, если производительность на доллар вырастет в 10 раз, то и ваш дата центр сильно подешевеет. Поэтому, производитьель может убить бизнес своих клиентов, выпустив более мощное оборудование.
Для вычислительной техники в мире принято брать сроки от 3-х до 10-ти лет.
Вариант 4 из книги конечно красив, но точно не для обычной школы. Метод подобия по мне вполне нормален для школьников. Ньютон когда-то гравитационную и инерциальную массу прировнял доказывая закон всемирного тяготения, но большинство жителей планеты про это ни разу не слышали.
С геометрией в школах нынче туго. Особенно со стереометрией. Связано с тем, что стали на порядки меньше рисовать. Те, кто ходят в художку, обычно на голову сильнее одноклассников в части геометрии. В таком контексте переход на алгебраические методы доказательства вполне уместен.
Про каркас аля как было принято в Паскале +1. Я с курсором попробовал в процелурное программирование сверху вниз с вкраплениями функционально. Получается отлично. Про автозапуск субагентов звучит прекрасно. Попробую. Сейчас запускаю руками.
Всё немного не так.
Google за третий квартал 2025:
Чистая прибыль (Net Income): $35.0 млрд (+33% г/г)
Capex за Q3 2025: $24 млрд.
Пока вложения в дата центры хорошо обиваются. Маржа Google Cloud 23,7%
Мне с ИИ помогает написание в процедурном стиле сверху вниз. Вот как раз начиная с архитектуры решения и заканчивая мелочами. Косячит на всех уровнях и это нормально. Субъективная оценка в 5-8% случаев. Помогают тесты. Наверное, в вашем случае архитектурных решений просто меньше, чем решений как написать что-то простое. С большинством простых задач справляется нормально, но иногда прямо дикие ляпы пролетают.
Пришлось нынче срочно искать работу при закрытии проекта. Ну такое себе. Отклики просто в пустоту. В личку пришла HR с вакансией ниже по грейду текущей на 2 ступеньки через месяц публикации. Один отклик за месяц!
Реальные варианты которые сработали - запустить стартап, сходить в личку к всем контактам, с которыми продуктивно работал последние 4 года. Если по работе ваш круг общения ограничен вашей командой, то придётся существенно сложнее.
Занимаюсь доставкой во Вкусвилл и хорошие практики:
1. 4-5 дарксторов в тестовой группе и столько же, с похожими метриками, в контрольной.
2. Фича фриз по тестовой и контрольной группе на время проведения. Тест минимум 2 недели. Оперативность хромает. Когда делаешь MVP 3 месяца и из них 2 недели занимает A/B с фича фризом, то не сильно рад такому подходу.
Больше нравится делить тестовую и контрольную группу не по магазинам, а по отдельным курьерам, или выкатить фичу только на часть зоны доставки дарка. Проходит в одно и то же время, в одинаковых погодных условиях, сборка заказов работает равномерно для обоих частей. Число контрольных метрик в таком случае сразу резко сокращается.
А какие методики проверки продуктовых гипотез кроме A/B тестов вы ещё применяете?
Что-то я потерялся несколько раз, пока читал статью.
Было
1. Команда не понимает контеста
2. Документация отсутствет (а вроде как должна появляться до разработки на этапе системного анализа)
3. Пинг-понг между тестированием и разработкой (DoD в задаче не фиксировался? Какой аретфакт на входе у тестировщика? Разраб базово не проверят что он сделал?)
4. Проблемы с документацией
И при чём тут слово Agile, если базовый Delivery процесс сломан, вовлечённость хромает?
Я как-то с парашютистами - спортсменами летел. С их слов, без стабильного полёта не спасёшься. То есть, это как минимум достаточная высота, работающая механизация крыла и стабильный полёт, что не типично для катастрофы. Достаточно случаев, когда самолёт при прыжках парашютистов валился в штопор и они не могли из него выпрыгнуть.
А вот практика general aviation, когда спускают самолёт целиком, вполне рабочая. Ну будет 5-6 парашютов вместо одного и что? Масса такой системы порядка 0,5-1,5% от взлетной.
Меня тоже такая мысль посещала при прочтении, но история с переездом с Оракла куда-то вполне закрывает этот вопрос. ПОдходит только то, что потребует меньше изменений и есть нормальные компетенции в команде. Ну и вариантов кроме OLTP to OLTP без серьёзных переработок не остаётся.
Я вот от работы заряжаюсь и вдохновляюсь. Понятно, что надо ещё спать, нормально питаться, двигаться, уделять время семье. Но отличный результат получается когда именно вдохновлённо и при этом осмыслено фигачишь. Условно если хочешь забраться на эверест, то не получится сделать это на чиле. И вспоминаться будет не только достижение, но и процесс. Потом обязательно надо буджет отдохнуть и восстановиться, не забыть, что надо оставить силы на спуск и пр. Это само с опытом приходит. Ну и жить на вершине - так себе история.