Я вот на Rust не пишу, а вот на С++ пишу. И всё же у меня всегда возникает вопрос: а оно мне точно надо, этот кастомный deleter? Почти всегда это костыль.
Программа как минимум могла бы напечатать "Out of memory".
Или просто поможно было посмотреть в диспетчер задач, Process Monitor, Event Viewer, Performance Monitor, тысячи их. Без всякой выездной бригады. За неумение диагностировать проблемы приходится платить.
Да и толку особо нет. Я проверю, я молодец, а кто-нибудь из моих зависимостей - не проверит, опять упадём, что делать будем? Опять бригаду высылать?
P.S.
Вообще я всеми руками за то, чтобы всё проверять и писать сообщения об ошибках везде, где только можно. Включая malloc. Просто для malloc это имеет наименьший из всех смыслов.
P.P.S.
Вообще, при анализе проблем в закрытых системах, "выездные бригады" неизбежны. Я не видел еще никого, кто бы смог уйти от этого при работе над такими системами.
Не очень понятно зачем это было на хабр-то писать? Тот объём информации, что тут представлен гугл/GPT расскажет одним запросом. Открывая статью я ожидал увидеть какую-то глубину погружения хотя бы на уровень "смотрите как оно реализовано в коде GCC".
Для таких публикаций на хабре придуманы посты.
P.S.
Ваша картинка со стрелочками плоховата. По ней можно заключить будто об объект oth в move-конструкторе всегда умирает при выходе из move-конструктора.
Это справедливо для временных объектов, но в общем случае не является верным.
Для С++ это более чем возможно, т.к. в имени функции есть вся информация о типах. Вы всегда можете извлечь эту информацию с помощью любого доступного "де-манглера" (не знаю как demangling перевести корректно). Хоть бы и онлайн.
В многоуровневой поддержки есть одна очень большая проблема, которую непонятно как решать: кадры.
Посадить разработчика на поддержку можно только в качестве наказания. А для оказания действительно квалифицированной помощи нужен человек с экспертизой даже большей, чем рядовой разработчик, тут скорее нужен прям настоящий DevOps, если речь о сложной системе.
Представляете стоимость такой поддержки? Но даже не стоимость главное, главное то, что человек способный такие функции выполнять - никогда не пойдет заниматься такой ерундой, как поддержка.
Звучит занятно. Я не музыкант, конечно, но кривизна в уши бросается. Хотя ощущается она всё равно довольно "гармонично". Получается, что кривизна-то - художественная!
но решал только типовые задачи в большой команде с наличием рядом гуру, который всегда знал ответы на сложные вопросы, значит ли что он опытный?
Так всё просто: спросите у человека как у них был выстроен процесс разработки на предыдущем месте: откуда ему поступали задачи, как распределялись, как решались, как контролировался процесс исполениня, какие были методы по контролю качества работы.
Опытные люди без проблем хоть по шагам расскажут каждый пункт и ответят на уточняющие вопросы. Несамостоятельные люди крайне редко вникают в процессы и обычно сразу заваливаются тут.
нужно как-то объективно сравнивать кандидатов. А это важная часть процесса
Вы декларируете эту важность, но никак не обосновываете. Я не вижу никакого смысла в "общей линейке", я вижу смысл лишь в том, внушает ли кандидат доверие или нет. Излишняя субъективность отсекается коллегиальной оценкой.
это один и тот же вопрос для каждого кандидата?
Список "стартовых вопросов" для всех одинаковый. Дополнительные вопросы для рассуждения - ситуативны.
вы уверены что вопрос проверяет именно то что нужно?
Все мои вопросы так или иначе вытекают из кодовой базы на моём проекте. Да, есть ряд базовых скрининг-вопросов по самому базовому синтаксису языка (которые естественно используется в проекте), но в остальном вопросы так или иначе относятся к бизнес-части проекта.
Вам нужен лишний стресс от кандидата? А зачем?
Какой, простите, стресс? Человек общается с двумя людьми всегда. И видит только двух человек. Иногда может подключиться 1, максимум 2 человека, кандидат их не видит, не слышит и вообще никак не контактирует.
как вы считаете подсказки, если вы даже заранее не знаете в какую сторону пойдет разговор
Я - никак не считаю. Мы не размер черепной коробки по линейке измеряем, мы просто общаемся с человеком))) Как я и упомянул - финальная оценка - это просто согласие двух (редко - трёх) человек по части того, проходил ли кандидат или нет.
Субъективно - как бы да. Выбираем ли мы в итоге кандидата, который похож на нас нравится как человек, т.е. исходя из его личных качеств - ну, отчасти да. Мы же не робота в команду ищем, а человека, с которым будет комфортно работать и при этом он подходит технически. В чём проблема с этим подходом?
Я не заметил, а где вы код пишете? Не пишите?
Вы тут только что про стресс говорили, а теперь предлагается под пристальным взглядом заставлять человека писать код, решать какие-то замороченные задачки за полчаса, хотя на реальной работе у него НИКОГДА не будет таких задач. У нас никогда не бывает "почини за 30 минут, а я буду за спиной стоять". Нет у нас такой херни.
Вместо у это у нас есть небольшая задачка на кодревью, где кандидату предлагается просто взглянуть на код, найти ошибки и сказать/написать исправление в редакторе. Ведь подобная рутина и есть каждодневная задача программиста: смотреть на код, исправлять, дополнять. Иногда будут задачи по написанию чего-то "с нуля", но это "с нуля" всегда будет в рамках какой-то готовой архитектуры, так что здесь проблем нет.
"Собес ровно один, длится часа полтора максимум" - это очень мало, особенно в вашем стиле собеседования.
На чём основано ваше "очень мало"? Наша статистика говорит, что вполне норм, большинство нанятых людей проходят испытательный и успешно справляются с работой в дальшейнем. В моей команде проблем не было вообще ни разу. В других - ну, я могу припомнить только 2 случая за последние 5 лет.
Даже больше скажу, когда-то в компании были многоэтапные собеседования. В них просто не оказалось никакой нужды. Потому как определяющим всегда было техническое интервью, а все остальные "для галочки".
HR в курсе такого стиля и без кода? Если нет, то почему? Если да, то как результативность оценивается?
HR в курсе. Вышестоящее начальство в курсе. Вообще все в курсе. Жалоб не поступало. Результативность чего вы хотите знать?
Я пока не видел ни разу определение, что значит "думать".
Почему меня это должно волновать? :) Я знаю что значит "думать", мои коллеги знают, что значит "думать") Остальное меня мало волнует)
а значит это только ваше субъективное ощущение мало имеющее отношение к реальности.
Реальность нам дана в ощущениях))) Реальность субъективная) Но опять же - я не вижу ни одной причины, почему мне не должно быть пофигу? В конечном итоге, как я и сказал, я не роботов нанимаю "работу работать", а людей, с которыми буду взаимодействовать на ежедневной основе. Я не занимаюсь конвейерным наймом "куда-то там". Зачем мне в команде люди, которые мне субъективно не по душе?
Я оценку оставляю прежней "детский уровень"
Мне ваши рассуждения тоже кажутся подростково-идеалистическими. Так и живём)
Занятно то, что я за последние 5-6 лет не словил вообще ни одной проблемы при обновлениях.
С одной стороны, да - личный опыт нерелевантен. С другой - срок наблюдений довольно длинный, так что какая-то статистическая значимость у этих наблюдений имеется.
Я ни разу ничего не откатывал, ничего не падало, ничего не начинало тормозить.
Ну это прям детский уровень собеседования. Как вы кандидатов между собой сравниваете при таком подходе?
А какие тут проблемы? Если нужны чиселки, тот тут шкала крайней простая.
1. Ответил на вопрос и не утонул в ответах - ставим плюсик что в данной теме разбирается, молодец.
2. Не ответил: считаем количество данных подсказок на вопрос. Чем больше потребовалось, тем меньше условных баллов человек получает. Если не смог ответить вовсе и вообще думал не туда, ну тут да, ставим нолик за вопрос. Если думал куда надо, но всё равно не смог прийти к нужному ответу, ставим условную единичку: "думать умеет, но нужен наставник".
Дальше можно проссумировать и там посчитать какие-то объективные циферки, но у меня на проекте нет такого потока кандидатов, чтобы была необходимость в какой-то сложной процедуре. Типа собеседование в лучшем случае раз в неделю.
Финальная оценка у нас - это просто "коллегиальное субъективное". Собес ведут 2 человека, некоторые еще могут подключаться чисто послушать (без видео), но в собесе они не участвуют. По итогу оффер выкатывается только если все присутствующие согласны с тем, что кандидат подходит.
У нас нет никаких многоэтапных собесов. Собес ровно один, длится часа полтора максимум.
ХЗ. Я на собесах вообще не смотрю правильно ответил человек или неправильно.
Если человек говорит правильные слова, я лишь раскручиваю его на разговор, чтобы проверить, понимает ли он вообще то, о чем говорит или просто заучил ответ.
Если человек говорит что-то совершенно неправильное, я его останавливаю, говорю что он не прав, потом даю несколько дополнительных подсказок и смотрю сможет ли он прийти к правильному ответу самостоятельно, т.е. просто оцениваю сколько в целом нужно будет тратить время на вводные для человека, чтобы он решал задачи ответ на которые не знает.
Сам по себе ответ - вообще не важен.
Оставшийся кусок времени Team lead закрывает собесами. Команда живёт сама по себе
Печально, но да, так и есть. Но если вы думаете, что тимлиды сильно рады такому положению вещей - эт точно не так. Я не рад)
Опять же, если они такие большие, то зачем вообще нужна IT ипотека?
Для того, чтобы застройщики не разорились? Огромные площади жилья стоят невостребованными. Нужно влить бабла в отрасль. У кого есть бабло? У айтишников! Внезапно именно ипотека и есть показатель того, что в IT зарплаты больше. Ну и то, что нужны какие-то стимулы, чтобы привязать разработчиков территориально, не без этого.
Моё описание было далеко от алгоритмического и ChatGPT меня всё равно понял. Да, оно было плюс/минус последовательным, но я специально писал не очень понятно. Например, про поворот линии с этим "клетка-за-клеткой" при перечитывании даже у меня появились вопросы, но ChatGPT даже в условиях такой лютой неоднозначности понял что он него хотят.
Ничто не ново под луной. В любой корпорации с большой кодовой базой, много задач решаются методом "комбинирования готовых кубиков". Да, в общем доступе этого кода нет, но корпорации могут иметь свои локальные GPT-модели, обученные на их коде. И эти модели, очевидно, из "готовых проприоретарных кубиков" смогут лепить нечто более или менее внятное.
Нормальная история, если я где-то до этого 10 работал и меня не увольняли) Ну, не верите, могу дать контакты бывшего работодателя, отзывы оставит)
Неожиданно удобная схема, правда?)
А что до джунов - им платят обычно настолько копейки, а самостоятельности у них настолько мало, что не так уж и важно, может он развернуть nginx или нет. Если они понимает как это делать в теории и не плавает при ответах на вопросы - это уже 80% успешности.
Ну, потупит пару недель человек, да освоится) Даже если придётся попрощаться на испытательном - по бюджету это сильно не ударит.
Я вот на Rust не пишу, а вот на С++ пишу. И всё же у меня всегда возникает вопрос: а оно мне точно надо, этот кастомный deleter? Почти всегда это костыль.
Или просто поможно было посмотреть в диспетчер задач, Process Monitor, Event Viewer, Performance Monitor, тысячи их. Без всякой выездной бригады. За неумение диагностировать проблемы приходится платить.
Да и толку особо нет. Я проверю, я молодец, а кто-нибудь из моих зависимостей - не проверит, опять упадём, что делать будем? Опять бригаду высылать?
P.S.
Вообще я всеми руками за то, чтобы всё проверять и писать сообщения об ошибках везде, где только можно. Включая malloc. Просто для malloc это имеет наименьший из всех смыслов.
P.P.S.
Вообще, при анализе проблем в закрытых системах, "выездные бригады" неизбежны. Я не видел еще никого, кто бы смог уйти от этого при работе над такими системами.
Не очень понятно зачем это было на хабр-то писать? Тот объём информации, что тут представлен гугл/GPT расскажет одним запросом. Открывая статью я ожидал увидеть какую-то глубину погружения хотя бы на уровень "смотрите как оно реализовано в коде GCC".
Для таких публикаций на хабре придуманы посты.
P.S.
Ваша картинка со стрелочками плоховата. По ней можно заключить будто об объект oth в move-конструкторе всегда умирает при выходе из move-конструктора.
Это справедливо для временных объектов, но в общем случае не является верным.
@oktonion
Для С++ это более чем возможно, т.к. в имени функции есть вся информация о типах. Вы всегда можете извлечь эту информацию с помощью любого доступного "де-манглера" (не знаю как demangling перевести корректно). Хоть бы и онлайн.
http://demangler.com/
Но есть и локальные, c++filt например. Для Си, ясное дело, простого решения этой проблемы нет.
Не могу припомнить каких-то других киллер-фич у винды 11. Хотя признаться, я ей пользовался всего неделю, так что распробовать не успел.
Лол. Вообще, это единственная фича из W11, которой мне хватает в W10. И получается, что снова Microsoft делает всё, чтобы похоронить W11.
В многоуровневой поддержки есть одна очень большая проблема, которую непонятно как решать: кадры.
Посадить разработчика на поддержку можно только в качестве наказания. А для оказания действительно квалифицированной помощи нужен человек с экспертизой даже большей, чем рядовой разработчик, тут скорее нужен прям настоящий DevOps, если речь о сложной системе.
Представляете стоимость такой поддержки? Но даже не стоимость главное, главное то, что человек способный такие функции выполнять - никогда не пойдет заниматься такой ерундой, как поддержка.
Звучит занятно. Я не музыкант, конечно, но кривизна в уши бросается. Хотя ощущается она всё равно довольно "гармонично". Получается, что кривизна-то - художественная!
А у Генеральной прокуратуры и, прости господи, Роскомнадзора есть полномочия "снимать требования?".
Долго я не мог понять, почему печка идёт до нанесения тонера на бумагу, в потому понял, что кто-то очень добрый сделал схему справа-налево)
Ну, вы недооцениваете способности ChatGPT к парсингу криво поставленных задач.
Вот недавно как раз в комментариях проверял его возможности на этот счёт
https://habr.com/ru/companies/sberbank/articles/796181/comments/#comment_26554975
Так всё просто: спросите у человека как у них был выстроен процесс разработки на предыдущем месте: откуда ему поступали задачи, как распределялись, как решались, как контролировался процесс исполениня, какие были методы по контролю качества работы.
Опытные люди без проблем хоть по шагам расскажут каждый пункт и ответят на уточняющие вопросы. Несамостоятельные люди крайне редко вникают в процессы и обычно сразу заваливаются тут.
Вы декларируете эту важность, но никак не обосновываете. Я не вижу никакого смысла в "общей линейке", я вижу смысл лишь в том, внушает ли кандидат доверие или нет. Излишняя субъективность отсекается коллегиальной оценкой.
Список "стартовых вопросов" для всех одинаковый. Дополнительные вопросы для рассуждения - ситуативны.
Все мои вопросы так или иначе вытекают из кодовой базы на моём проекте. Да, есть ряд базовых скрининг-вопросов по самому базовому синтаксису языка (которые естественно используется в проекте), но в остальном вопросы так или иначе относятся к бизнес-части проекта.
Какой, простите, стресс? Человек общается с двумя людьми всегда. И видит только двух человек. Иногда может подключиться 1, максимум 2 человека, кандидат их не видит, не слышит и вообще никак не контактирует.
Я - никак не считаю. Мы не размер черепной коробки по линейке измеряем, мы просто общаемся с человеком))) Как я и упомянул - финальная оценка - это просто согласие двух (редко - трёх) человек по части того, проходил ли кандидат или нет.
Субъективно - как бы да. Выбираем ли мы в итоге кандидата, который похож на нас нравится как человек, т.е. исходя из его личных качеств - ну, отчасти да. Мы же не робота в команду ищем, а человека, с которым будет комфортно работать и при этом он подходит технически. В чём проблема с этим подходом?
Вы тут только что про стресс говорили, а теперь предлагается под пристальным взглядом заставлять человека писать код, решать какие-то замороченные задачки за полчаса, хотя на реальной работе у него НИКОГДА не будет таких задач. У нас никогда не бывает "почини за 30 минут, а я буду за спиной стоять". Нет у нас такой херни.
Вместо у это у нас есть небольшая задачка на кодревью, где кандидату предлагается просто взглянуть на код, найти ошибки и сказать/написать исправление в редакторе. Ведь подобная рутина и есть каждодневная задача программиста: смотреть на код, исправлять, дополнять. Иногда будут задачи по написанию чего-то "с нуля", но это "с нуля" всегда будет в рамках какой-то готовой архитектуры, так что здесь проблем нет.
На чём основано ваше "очень мало"? Наша статистика говорит, что вполне норм, большинство нанятых людей проходят испытательный и успешно справляются с работой в дальшейнем. В моей команде проблем не было вообще ни разу. В других - ну, я могу припомнить только 2 случая за последние 5 лет.
Даже больше скажу, когда-то в компании были многоэтапные собеседования. В них просто не оказалось никакой нужды. Потому как определяющим всегда было техническое интервью, а все остальные "для галочки".
HR в курсе. Вышестоящее начальство в курсе. Вообще все в курсе. Жалоб не поступало. Результативность чего вы хотите знать?
Почему меня это должно волновать? :) Я знаю что значит "думать", мои коллеги знают, что значит "думать") Остальное меня мало волнует)
Реальность нам дана в ощущениях))) Реальность субъективная) Но опять же - я не вижу ни одной причины, почему мне не должно быть пофигу? В конечном итоге, как я и сказал, я не роботов нанимаю "работу работать", а людей, с которыми буду взаимодействовать на ежедневной основе. Я не занимаюсь конвейерным наймом "куда-то там". Зачем мне в команде люди, которые мне субъективно не по душе?
Мне ваши рассуждения тоже кажутся подростково-идеалистическими. Так и живём)
Если не печатаешь в промышленных масштабах, есть подозрение, что вред здоровью будет очень тяжело нанести этими испарениями.
Занятно то, что я за последние 5-6 лет не словил вообще ни одной проблемы при обновлениях.
С одной стороны, да - личный опыт нерелевантен. С другой - срок наблюдений довольно длинный, так что какая-то статистическая значимость у этих наблюдений имеется.
Я ни разу ничего не откатывал, ничего не падало, ничего не начинало тормозить.
Да блин, если бы ко мне приходили на проект люди с патчами моих проблем - я бы только спасибо говорил и подарки всем на новый год им рассылал)
А какие тут проблемы? Если нужны чиселки, тот тут шкала крайней простая.
1. Ответил на вопрос и не утонул в ответах - ставим плюсик что в данной теме разбирается, молодец.
2. Не ответил: считаем количество данных подсказок на вопрос. Чем больше потребовалось, тем меньше условных баллов человек получает. Если не смог ответить вовсе и вообще думал не туда, ну тут да, ставим нолик за вопрос. Если думал куда надо, но всё равно не смог прийти к нужному ответу, ставим условную единичку: "думать умеет, но нужен наставник".
Дальше можно проссумировать и там посчитать какие-то объективные циферки, но у меня на проекте нет такого потока кандидатов, чтобы была необходимость в какой-то сложной процедуре. Типа собеседование в лучшем случае раз в неделю.
Финальная оценка у нас - это просто "коллегиальное субъективное". Собес ведут 2 человека, некоторые еще могут подключаться чисто послушать (без видео), но в собесе они не участвуют. По итогу оффер выкатывается только если все присутствующие согласны с тем, что кандидат подходит.
У нас нет никаких многоэтапных собесов. Собес ровно один, длится часа полтора максимум.
ХЗ. Я на собесах вообще не смотрю правильно ответил человек или неправильно.
Если человек говорит правильные слова, я лишь раскручиваю его на разговор, чтобы проверить, понимает ли он вообще то, о чем говорит или просто заучил ответ.
Если человек говорит что-то совершенно неправильное, я его останавливаю, говорю что он не прав, потом даю несколько дополнительных подсказок и смотрю сможет ли он прийти к правильному ответу самостоятельно, т.е. просто оцениваю сколько в целом нужно будет тратить время на вводные для человека, чтобы он решал задачи ответ на которые не знает.
Сам по себе ответ - вообще не важен.
Печально, но да, так и есть. Но если вы думаете, что тимлиды сильно рады такому положению вещей - эт точно не так. Я не рад)
Для того, чтобы застройщики не разорились? Огромные площади жилья стоят невостребованными. Нужно влить бабла в отрасль. У кого есть бабло? У айтишников! Внезапно именно ипотека и есть показатель того, что в IT зарплаты больше. Ну и то, что нужны какие-то стимулы, чтобы привязать разработчиков территориально, не без этого.
Да, это правда, но тут есть два важных НО!
Моё описание было далеко от алгоритмического и ChatGPT меня всё равно понял. Да, оно было плюс/минус последовательным, но я специально писал не очень понятно. Например, про поворот линии с этим "клетка-за-клеткой" при перечитывании даже у меня появились вопросы, но ChatGPT даже в условиях такой лютой неоднозначности понял что он него хотят.
Ничто не ново под луной. В любой корпорации с большой кодовой базой, много задач решаются методом "комбинирования готовых кубиков". Да, в общем доступе этого кода нет, но корпорации могут иметь свои локальные GPT-модели, обученные на их коде. И эти модели, очевидно, из "готовых проприоретарных кубиков" смогут лепить нечто более или менее внятное.
Нормальная история, если я где-то до этого 10 работал и меня не увольняли) Ну, не верите, могу дать контакты бывшего работодателя, отзывы оставит)
Неожиданно удобная схема, правда?)
А что до джунов - им платят обычно настолько копейки, а самостоятельности у них настолько мало, что не так уж и важно, может он развернуть nginx или нет. Если они понимает как это делать в теории и не плавает при ответах на вопросы - это уже 80% успешности.
Ну, потупит пару недель человек, да освоится) Даже если придётся попрощаться на испытательном - по бюджету это сильно не ударит.