Pzz>Никогда не понимал, зачем отлаживать один код два раза — сначала в дебаговом билде, который никому не нужен, а потом в релизном.

Просто удобней. Отлаживать код под x64 после обработки его оптимизатором — удовольствие ниже среднего. Локальные переменные, аргументы функций хрен поймешь где. И приходится действительно лезть в дизасм, чтобы понять, что на самом деле происходит. Во время разработки — трассировать код приходится часто, зачем самому себе руки ломать? И кстати, если код пишется нормально, то он потом просто в релизный перекомпилируется и работает. Как правило, ошибки которые проявляются только в релизе — косвенный признак кривых рук. То же самое по поводу перехода x86 -> x64. Если код писали нормальные люди, то ошибки возможно только на вроде тех, что ув. Linger описал да и фиксится они за 5мин.

Здравствуйте, Pzz, Вы писали:

GIV>>При устройстве сразу обговариваешь, что имеешь планы\билеты\путевку на "с-по". По моему опыту всем пофиг, соглашаются без проблем. Три последних раза у меня менее полугода от устройства до первого отпуска, миннимум 1 неделя.

Pzz>Устройство на работу — это эквиавалент договора купли-продажи себя, любомого, за зарплату и некоторое количество дополнительных плюшек. И если вы выторговываете себе что-то в одном месте (например, возможность сразу умотать в отпуск), вы неизбежно теряете в другом месте. А оно вам надо?

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

Здравствуйте, Аноним, Вы писали:

А>Просто удобней. Отлаживать код под x64 после обработки его оптимизатором — удовольствие ниже среднего. Локальные переменные, аргументы функций хрен поймешь где. И приходится действительно лезть в дизасм, чтобы понять, что на самом деле происходит. Во время разработки — трассировать код приходится часто, зачем самому себе руки ломать? И кстати, если код пишется нормально, то он потом просто в релизный перекомпилируется и работает. Как правило, ошибки которые проявляются только в релизе — косвенный признак кривых рук. То же самое по поводу перехода x86 -> x64. Если код писали нормальные люди, то ошибки возможно только на вроде тех, что ув. Linger описал да и фиксится они за 5мин.

Я второй раз уже слышу жуткую историю про то, как у венды хидер разъезжается между дебаговой и релизной версиями, причем это разные по содержанию истории. К чему этот геморрой? Плюс, баги компилятора, если вылезут, то вылезут в разных билдах по-разному. Плюс, aliasing всякий — он вылезет только в релизе, да и то, если повезет. Зачем удваивать себе работу?

Pzz>Я второй раз уже слышу жуткую историю про то, как у венды хидер разъезжается между дебаговой и релизной версиями, причем это разные по содержанию истории. К чему этот геморрой? Плюс, баги компилятора, если вылезут, то вылезут в разных билдах по-разному. Плюс, aliasing всякий — он вылезет только в релизе, да и то, если повезет. Зачем удваивать себе работу?

Удваивать работу — это отлаживать релизный билд. А баги компилятора — это обычно на нестабильных версиях gcc бывает. При использовании cl я не встречал ситуаций еогда требовались бы воркараунды для Си компилятора.

Здравствуйте, sobko, Вы писали:

А>>А можно я тебя поспрашиваю?

S>Да без проблем, только я не разработчик, а руководитель отдела (ресурсный руководитель). По файловым драйверам еще что-то помню но уже могу что-то ляпнуть не то. В качестве примера могу сослаться на код в http://code.google.com/p/accessch/, писал как-то по просьбе.

Начальник отдела, звучит солидно. Не хухры мухры.

Но тем не менее, коли вам надо код делать и качественный, дык давай я подвежусь, чай уже чуть ли не 10 лет так работаю. Я вообще не дорого беру.

Здравствуйте, Аноним, Вы писали:

А>Удваивать работу — это отлаживать релизный билд. А баги компилятора — это обычно на нестабильных версиях gcc бывает. При использовании cl я не встречал ситуаций еогда требовались бы воркараунды для Си компилятора.

Баги бывают у любого компилятора. Хотя и достаточно редко — слишком редко, чтобы сваливать на них непонятные баги в собственной программе

Здравствуйте, sobko, Вы писали:

А>>>Если кто стесняется писать в HR или не хочет светиться может написать мне директом на andrey.sobko@kaspersky.com. Тайну гарантирую
А>>скажите пожалуйста, правда ли у вас считается совершенно нормальным в рабочей переписке использовать термины типа "дебила кусок" ?

S>Специально сделал поиск по всей своей почте — слово "дебил" не найден ни разу.

Не смог удержаться...

а "дИбил" есть ? Так же было бы любопытно глянуть на результаты поиска в почте и в коде других интересных слов (за которые тут банят).

Здравствуйте, VeronikaNovik, Вы писали:

VN>Мне как рекрутеру очень нужен ваш совет, у нас размещена здесь вакансия Разработчик драйверов — http://www.rsdn.ru/forum/job.offers/4713288.aspx

Автор: VeronikaNovik
Дата: 23.04.12

, но откликов на неё практически нет. Пожалуйста, посоветуйте, что с вакансией не так? может инфы какой не хватает или ещё чего-либо?

нет — потому что никто не хочет работать в ЛК
продукты в ЛК, так себе
а утекшие в прошлом году исходные коды, показали что в ЛК работают говнокодеры

Здравствуйте, sobko, Вы писали:

VN>>>мы указали средний уровень зп (100 000 руб).
А>>Дам вам совет — тут деньги не помогут. Либо только в разы больше рынка.
А>>Причем тут деньги, если вам нужны какие-то неведомые люди. Специалистом в данной области становятся только через 10 лет конкретной пахаты после института и причем ТОЛЬКО в данной области. Где такие могли бы народиться в России, и ТЕМ более в Москве? Вы как себе развитие и формирование такого человека представляете? Вот типа взял пару книг прочитал, и готово. Да тут только навыки и ОПЫТ помогают писать проги которые не валят систему.

S>Есть такие люди, в отделе есть ОДИН коренной москвич, причем ОЧЕНЬ высокой квалификации.

Насчет квалификаци не кто не спорит, просто сейчас ехать в Москву не выгодно при любом раскладе.

Здравствуйте, Аноним, Вы писали:


Pzz>>Я второй раз уже слышу жуткую историю про то, как у венды хидер разъезжается между дебаговой и релизной версиями, причем это разные по содержанию истории. К чему этот геморрой? Плюс, баги компилятора, если вылезут, то вылезут в разных билдах по-разному. Плюс, aliasing всякий — он вылезет только в релизе, да и то, если повезет. Зачем удваивать себе работу?

А>Удваивать работу — это отлаживать релизный билд. А баги компилятора — это обычно на нестабильных версиях gcc бывает. При использовании cl я не встречал ситуаций еогда требовались бы воркараунды для Си компилятора.

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

Здравствуйте, sobko, Вы писали:

L>>Помнится пробегали тут люди, с лозунгами что драйвер девелоперам платят по 200К. За эти деньги, хотя бы в краткосрочной перспективе, переехал бы в Москву не задумываясь.
L>>К слову сейчас работаю на антивирусную компанию из Австрии, только удаленно, и все довольны.

S>Теоретически можно получить з.п. и 200 тыс (ttcc). Но придется подтвердить свою квалификацию, как минимум ответить на все мои вопросы.

Позвольте подготовится Какие вопросы будут?

А>а утекшие в прошлом году исходные коды, показали что в ЛК работают говнокодеры
Утечка исходных кодов любого популярного продукта, известной компании это показывает.
Не разу не слышал и не читал "видел выложенный исходный код %toolname%, там отличный код, программисты в %companyname% гении!"

Здравствуйте, sobko, Вы писали:

S>>>Теоретически можно получить з.п. и 200 тыс (ttcc). Но придется подтвердить свою квалификацию, как минимум ответить на все мои вопросы.
А>>А можно я тебя поспрашиваю?

S>Да без проблем, только я не разработчик, а руководитель отдела (ресурсный руководитель). По файловым драйверам еще что-то помню но уже могу что-то ляпнуть не то. В качестве примера могу сослаться на код в http://code.google.com/p/accessch/, писал как-то по просьбе.

Так это ваш код. Очень понравился, спасибо )

Здравствуйте, Свиридов Роман, Вы писали:

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

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

_>дебаг билд можно посмотреть только если ошибка настолько странная, что ее никак не удается починить. А так — все тесты и отладка должна идти на том коде, который будет проставлятся в продакшн.

Очень согласен! Если хочется во время разработки поддерживать себя в тонусе, то естественно, нужно отлаживать только релизные сборки и только под amd64. В исходной код смотреть особо смысла не будет, всякие там локальные переменные смотрят только нубы. Все это не нужно! Хороший разрботчик по дизасму сразу найдет причину. Говорил Суворов: "тяжело в учении — легко в бою". За время отладки выучишь всесь ассемблерный код своего проекта и когда придет баг из продакшена без всякой отладки найдешь причину.

Здравствуйте, licedey, Вы писали:

S>>Теоретически можно получить з.п. и 200 тыс (ttcc). Но придется подтвердить свою квалификацию, как минимум ответить на все мои вопросы.
L>Позвольте подготовится Какие вопросы будут?

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

Обычно начинаю спрашивать про объекты синхронизации, разницу в быстродействии и применении. Если кандидат писал файловые системы начинаю спрашивать про интеграцию с кешменеджером, варианты доступа к данным (типа через секции, пейджинг, IRP_MN_COMPLETE_MDL). Если занимался контролем доступа или содержимого начинаю спрашивать про идентицикацию пользователя или объекта, люблю спрашивать как определить что запрос из сетевого редиректора пришел от локального пользователя. Если писал шифрование могу спросить про различные варианты реализации шифрования, спрошу про спрарс файлы. Для редиректором буду спрашивать про name provider-ы или опцию OPEN_NO_RECALL...

В общем, если человек знает то про нюансы он будет помнить

ps. Да, если кто писал серверные продукты начинаю спрашивать про масштабирование, кластеры и нуму... Но такие мне не попадались, серверные продукты у нас что, никто в России не пишет?

Здравствуйте, Аноним, Вы писали:

_>>дебаг билд можно посмотреть только если ошибка настолько странная, что ее никак не удается починить. А так — все тесты и отладка должна идти на том коде, который будет проставлятся в продакшн.
А>Очень согласен! Если хочется во время разработки поддерживать себя в тонусе, то естественно, нужно отлаживать только релизные сборки и только под amd64. В исходной код смотреть особо смысла не будет, всякие там локальные переменные смотрят только нубы. Все это не нужно! Хороший разрботчик по дизасму сразу найдет причину. Говорил Суворов: "тяжело в учении — легко в бою". За время отладки выучишь всесь ассемблерный код своего проекта и когда придет баг из продакшена без всякой отладки найдешь причину.

Да, да, и такие уникумы сразу детектят bit change ошибки из-за сбоя памяти!

Здравствуйте, izl3sa, Вы писали:

S>>Да без проблем, только я не разработчик, а руководитель отдела (ресурсный руководитель). По файловым драйверам еще что-то помню но уже могу что-то ляпнуть не то. В качестве примера могу сослаться на код в http://code.google.com/p/accessch/, писал как-то по просьбе.
I>Так это ваш код. Очень понравился, спасибо )

Да, я всегда интересуюсь есть ли у человека хобби и можно ли посмотреть его код в паблик репозитории. Это позволяет посмотреть на тщательно скрываемое и предпочтения по кодестайлингу.

Здравствуйте, sobko, Вы писали:

СР>>Насчет квалификаци не кто не спорит, просто сейчас ехать в Москву не выгодно при любом раскладе.
S> Увы, сам бы жил где-нибудь подальше от Нерезиновой, да не получается. Ты вот в свое время убежал и наверное не жалеешь.

S>Лично я не против удаленной работы, но своему опыту работы с людьми — не все могут стабильно и качественно удаленно работать. Наверное поэтому компанию минимизирует такие риски.

Дык, опять же — вот мне уже даже не 40 И я смею вас уверить, я ну совсем не похож, на безответственного чудика , который все бросит и запьет. Да и опыта руководства у меня например думаю не меньше чем у вас ( хрен знает может и даже больше, тут не суть в этом конкретно ), так что с одной стороны ваши опасения понятны. Но опять же мы же ищем таланты, так что тут нужен индивидуальный подход.

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

Вот например одна компания из Москвы, опубликовала вакансию, я на нее откликнулся, они тоже не хотели удаленки, но в итоге мы же договорились, точнее они после того как в течении года не могли найти специалиста, они сами предложили так работать.

Ясно и понятно, что не конкретно вы определяете политику компании в этом вопросе, но результат то просят от вас. И вы объективно и убедительно объясняете руководству что вот такие получаются сроки так как людей нет.

То есть все правильно и объективно, но результат хуже чем мог бы быть.

Кто тут виноват? Да никто. Но в чем причина замедленного движения? Их две — ваше не желание брать на себя риски, и нежелание руководства вникать в суть проблемы — ну и так все не плохо. Ну не прет руководство уже от процесса. Ну так не попрет еще лет пять и будет тоже что и бывает со всеми компаниями которые не правильно относятся к кадровой политике. Так же МС кстати тому некоторый пример — набрали индусов в руководство и вот что мы имеем, при условии что компания была единственным лидером буквально пять-семь лет назад.

Так что надо помогать друг другу. И нанимать меня в качестве опытного само-организующегося перца.

Мы тут все друг друга знаем. Так что какие там ЕЩЕ нужны резюме.

Здравствуйте, Аноним, Вы писали:

А>Так что надо помогать друг другу. И нанимать меня в качестве опытного само-организующегося перца.
А>Мы тут все друг друга знаем. Так что какие там ЕЩЕ нужны резюме.

Есть такое понятие "процесс" и резюме это точка входа. Гораздо проще его разослать в смежные отделы чем рассказывать голосом про человека. Вдруг твои данные заинтересуют отделы амр, грейт или антируткитовцев?

ps. Присылай, почитаем обсудим. В самом плохом случае — просто очно познакомимся и составим личное мнение!