мне за 25 лет проф карьеры только 1 раз случилось проект вообще с нуля писать. Кайф жуткий. Думать, обсуждать, предлагать. Как хорошо, что тогда LLM всяких не было...
После прочтения упомянутого выше комментария у меня сразу появляются неприятные ощущения, после которых хочется оглянуться вокруг и задуматься: а чем ты вообще занимаешься и на что тратишь свою жизнь.
Прошу прощения, что ненароком навеял неприятные мысли о бренности существования...
А по сути вопроса - каждый выбирает сам, что ему ближе, работать "на дядю" (и следовать правилам того дяди), или основать своё и работать на себя, принимая иные стрессы и риски. В том числе и выгорания, кстати, особенно в начале.
Первое, нужно понять, зачем вашей текущей компании performance review?
потому что есть у всех, значит и нам тоже нужно
механизм движения внутри компании
В первом случае - таки да, шум и активность, особенно накануне ревью, может помочь. Во втором случае - у менеджеров должны быть чёткие метрики оценки и градации, иначе это не работает.
Например в Airbnb такой процесс (по крайней мере был 5 лет назад): в период ревью менеджеры команд, работающих вместе, калибруют своих инженеров на соответствие уровню, сравнивая их друг с другом по проделанной работе, по весьма чётким границам какая работа относится к какому уровню. (конечно, стараясь отстоять своих инженеров и их работу).
Поэтому я сам вёл учёт того, кто и над чем работал и с каким успехом. Self-review и peer-reviews служили доп. подтверждением объективности оценки.
для меня один из неявных маркеров - выдержка стиля. Человеку сложно в большом тексте придерживаться одного стиля. Обычно это некий микс (если говорить о средней "журнальной" статье). Нейронка же выдерживает стиль и нередко фальшивит в "интонации".
if (true.ToString().ToLower() == "true") {...} тоже делает, то, что автор хочет. Вопрос - "зачем"?
Я честно попытался прикинуть, в каком случае может понадобится ваш костыль - но ничего так и не придумалось. Можете дать пример, когда ваш костыль даёт хоть какую-то пользу перед другими сериализациями?
Немного поработав с ко-пилотом, я сделал простой вывод - с ним также как со стажером - дай конкретное ТЗ, убедись, что тебя поняли - и получи результат, близкий к ожидаемому.
Когда задают такой вопрос на собеседовании, это не на "подумать", это на понимание того, что у вас обозначено "Как-то работает под капотом". И правильный ответ (вне зависимости, как он сформулирован) - это "всё зависит от реализации IEnumerable в конкретной коллекции".
Стало любопытно проверить теорию из статьи на нашей компании. Компания большая, всегда где-нить кто-нить требуется. Вот например в один офис ищут и сеньёра и мидла и джуна. (называются вакансии чуть иначе, у нас лычки дают легко, часто авансом). Но сильного топологического разлёта не увидел.
Факт №1. Парадокс стажера: от новичков требуют невозможного
Почему так? Это визуализация «рыночного маркетинга» или «wishlist-а рекрутера». В вакансии Intern/Junior вписывают всё подряд — от SQL до Microservices — просто чтобы отсеять тех, кто боится сложных слов. Типичный стажер .NET в 2026 году должен знать Kubernetes, квантовую физику и уметь варить кофе из зерен, собранных лично Биллом Гейтсом. Зарплата при этом — печеньки и «огромный опыт».
В нашей компании (Квебек, Канада) традиционно есть бюджет на стажёров. Когда мы публикуем вакансию на стаж, там указано всё, с чем стажёр может столкнуться. Вот студент пришёл и я ему предлагаю несколько вариантов, где он может поработать. Объясняю перспективы и ценность для команды.
В итоге, (на примере прошлого года), парень за три месяца практики поработал и с юнит тестами (всё руки не доходили оптимизировать их). И с реализацией несложной бизнес-логики (следуя похожим примерам из кода) и в деплоймент (azure devops, yaml, bisep, gitops) окунулся. На второй стаж позвали его же, но уже в команду embedded программирования. Там вообще .NET нету.
Рынок считает их «неявными знаниями». Если Senior пишет в резюме, что знает HTML — это как если бы пилот хвастался, что умеет открывать дверь в самолет. Это подразумевается по умолчанию, и писать об этом — только место тратить. Аналогично и с базовыми навыками – linq, ef core и тп.
Можно я немного не соглашусь? Во-первых, чем ниже грейд - тем шире спектр задач. А во-вторых, ."Знать HTML/linq/что угодно" можно совершено по разному. От сеньёра обычно никто не ждёт работы с примитивным HTML. Поэтому и не пишут. Но если нужно глубокое понимание технологии, она будет указана.
Сдаётся, что да, процесс будет где-то близко к этому. Когда-нибудь.
Как только появятся боле-менее универсальные шаблоны для построения такой структуры и по разумной цене.
И то, всегда будет соблазн стартовать с чем-то более дешевым и быстрым в развёртывании, где десяток условных "молодых специалистов + подписка на LLM" за условную "чашку риса" будет дешевле и эффективнее, чем парк локальных агентов со сложными взаимосвязями.
Но тем не менее, главный критерий оценки кода - работает ли он, именно за это платят деньги, а все остальное вторично.
Бизнесу вообще с высокой колокольни на стандарты, пайплайны и тесты, Ему главное чтоб код работал и решал целевую функцию.
По-моему хабр-сообщество совершенно несправедливо накинулось на это утверждение.
Бизнес терпит неизбежные накладные расходы на поддержку кода, в том объеме, который считает допустимым (на базе мнений своих инженеров в том числе).
А второе - это определение "работающего кода", особенно в формате подкаста.Вряд ли он имел в виду минимальный proof of concept, скорее код, близкий к тому, что написал бы человек, который работает, в том числе и граничных и пиковых нагрузках.
work-life уважается далеко не везде. В смысле на деле и где нет профсоюзов. И сильно зависит и от менеджмента и от текущей ситуации и от её интерпретации.
Это обычная удалёнка в разных часовых поясах. Я так работаю уже много лет.
переезжая в разные пояса раз в месяц?
Мой посыл в том, что при постоянной удалёнке все процессы отлажены, временной сдвиг известен до начала работы. Краткосрочные отпуска-командировки, при неизвестном временном сдвиге, приходится планировать и координировать уже в процессе, а это дополнительные накладные расходы и в управлении и в работе..
у нас в одном здании и производство (в 2 смены) и офисы со всякими типа белыми воротничками (хотя почти все ходят в футболках без воротничков).
Так вот, весь приоритет по отдыху (у нас общие столовые и другие места общего пользования) имеют именно работники производственных цехов. То есть да, неравенство в условиях труда (строго нормированный график, перерывы по часам и т.п.) пытаются как-то компенсировать.
отличается сломом привычного темпа и графика работы в команде. Внезапно меняются часы работы, сбиваются митинги, зачастую увеличивается время всевозможных согласований.
Плюс все понимают, что человек там больше отдыхает, чем работает, поэтому стараются не беспокоить, если не сильно важно.
(дисклеймер - у нас официальных воркейшнов нет, но практикуется "задержаться в отпуске" или "съездить на родину по семейным обстоятельствам")
У меня скорее складывается подозрение, что у вас ошибочное представление о том, что такое required и зачем он нужен.
В новых проектах, возможно, контракты на обязательность (кроме DTO) будут через required. А может быть так и останемся во тьме конструкторов с параметрами и прочими фабриками вместо продвинутого ключевого слова. "There are different ways to skin a cat", как говорит мой коллега.
мне за 25 лет проф карьеры только 1 раз случилось проект вообще с нуля писать. Кайф жуткий. Думать, обсуждать, предлагать. Как хорошо, что тогда LLM всяких не было...
Основная проблема применения "недавних улучшений" - это вспомнить о них в процессе работы.
Вроде читал, и не раз, старался запомнить. А потом смотришь, - код опять близок к тому, что SharpLab показывает...
Прошу прощения, что ненароком навеял неприятные мысли о бренности существования...
А по сути вопроса - каждый выбирает сам, что ему ближе, работать "на дядю" (и следовать правилам того дяди), или основать своё и работать на себя, принимая иные стрессы и риски. В том числе и выгорания, кстати, особенно в начале.
Первое, нужно понять, зачем вашей текущей компании performance review?
потому что есть у всех, значит и нам тоже нужно
механизм движения внутри компании
В первом случае - таки да, шум и активность, особенно накануне ревью, может помочь. Во втором случае - у менеджеров должны быть чёткие метрики оценки и градации, иначе это не работает.
Например в Airbnb такой процесс (по крайней мере был 5 лет назад): в период ревью менеджеры команд, работающих вместе, калибруют своих инженеров на соответствие уровню, сравнивая их друг с другом по проделанной работе, по весьма чётким границам какая работа относится к какому уровню. (конечно, стараясь отстоять своих инженеров и их работу).
Поэтому я сам вёл учёт того, кто и над чем работал и с каким успехом. Self-review и peer-reviews служили доп. подтверждением объективности оценки.
для меня один из неявных маркеров - выдержка стиля. Человеку сложно в большом тексте придерживаться одного стиля. Обычно это некий микс (если говорить о средней "журнальной" статье). Нейронка же выдерживает стиль и нередко фальшивит в "интонации".
я вот только не понял, а статья-то о чем?
if (true.ToString().ToLower() == "true") {...}тоже делает, то, что автор хочет. Вопрос - "зачем"?Я честно попытался прикинуть, в каком случае может понадобится ваш костыль - но ничего так и не придумалось. Можете дать пример, когда ваш костыль даёт хоть какую-то пользу перед другими сериализациями?
Немного поработав с ко-пилотом, я сделал простой вывод - с ним также как со стажером - дай конкретное ТЗ, убедись, что тебя поняли - и получи результат, близкий к ожидаемому.
Когда задают такой вопрос на собеседовании, это не на "подумать", это на понимание того, что у вас обозначено "Как-то работает под капотом". И правильный ответ (вне зависимости, как он сформулирован) - это "всё зависит от реализации IEnumerable в конкретной коллекции".
Стало любопытно проверить теорию из статьи на нашей компании. Компания большая, всегда где-нить кто-нить требуется. Вот например в один офис ищут и сеньёра и мидла и джуна. (называются вакансии чуть иначе, у нас лычки дают легко, часто авансом). Но сильного топологического разлёта не увидел.
Уметь работать с чем-то? От стажёра никто не ждёт практических познаний. Главное - интерес к профессии и желание учиться.
В нашей компании (Квебек, Канада) традиционно есть бюджет на стажёров. Когда мы публикуем вакансию на стаж, там указано всё, с чем стажёр может столкнуться. Вот студент пришёл и я ему предлагаю несколько вариантов, где он может поработать. Объясняю перспективы и ценность для команды.
В итоге, (на примере прошлого года), парень за три месяца практики поработал и с юнит тестами (всё руки не доходили оптимизировать их). И с реализацией несложной бизнес-логики (следуя похожим примерам из кода) и в деплоймент (azure devops, yaml, bisep, gitops) окунулся. На второй стаж позвали его же, но уже в команду embedded программирования. Там вообще .NET нету.
Можно я немного не соглашусь? Во-первых, чем ниже грейд - тем шире спектр задач. А во-вторых, ."Знать HTML/linq/что угодно" можно совершено по разному. От сеньёра обычно никто не ждёт работы с примитивным HTML. Поэтому и не пишут. Но если нужно глубокое понимание технологии, она будет указана.
Сдаётся, что да, процесс будет где-то близко к этому. Когда-нибудь.
Как только появятся боле-менее универсальные шаблоны для построения такой структуры и по разумной цене.
И то, всегда будет соблазн стартовать с чем-то более дешевым и быстрым в развёртывании, где десяток условных "молодых специалистов + подписка на LLM" за условную "чашку риса" будет дешевле и эффективнее, чем парк локальных агентов со сложными взаимосвязями.
По-моему хабр-сообщество совершенно несправедливо накинулось на это утверждение.
Бизнес терпит неизбежные накладные расходы на поддержку кода, в том объеме, который считает допустимым (на базе мнений своих инженеров в том числе).
А второе - это определение "работающего кода", особенно в формате подкаста. Вряд ли он имел в виду минимальный proof of concept, скорее код, близкий к тому, что написал бы человек, который работает, в том числе и граничных и пиковых нагрузках.
work-life уважается далеко не везде. В смысле на деле и где нет профсоюзов. И сильно зависит и от менеджмента и от текущей ситуации и от её интерпретации.
переезжая в разные пояса раз в месяц?
Мой посыл в том, что при постоянной удалёнке все процессы отлажены, временной сдвиг известен до начала работы. Краткосрочные отпуска-командировки, при неизвестном временном сдвиге, приходится планировать и координировать уже в процессе, а это дополнительные накладные расходы и в управлении и в работе..
у нас в одном здании и производство (в 2 смены) и офисы со всякими типа белыми воротничками (хотя почти все ходят в футболках без воротничков).
Так вот, весь приоритет по отдыху (у нас общие столовые и другие места общего пользования) имеют именно работники производственных цехов. То есть да, неравенство в условиях труда (строго нормированный график, перерывы по часам и т.п.) пытаются как-то компенсировать.
отличается сломом привычного темпа и графика работы в команде. Внезапно меняются часы работы, сбиваются митинги, зачастую увеличивается время всевозможных согласований.
Плюс все понимают, что человек там больше отдыхает, чем работает, поэтому стараются не беспокоить, если не сильно важно.
(дисклеймер - у нас официальных воркейшнов нет, но практикуется "задержаться в отпуске" или "съездить на родину по семейным обстоятельствам")
В новых проектах, возможно, контракты на обязательность (кроме DTO) будут через
required. А может быть так и останемся во тьме конструкторов с параметрами и прочими фабриками вместо продвинутого ключевого слова. "There are different ways to skin a cat", как говорит мой коллега.