Кадры в брендовых компаниях

Все-таки интересно, откуда такие компании как Гугл берут людей? Ведь их продукт - это их технологии, а значит нельзя просто найти людей с опытом работы с этими технологиями.
Думаю, политика при наборе кадров примерно следующая.
1. Безоговорочно покупаются люди с именем, уже зарекомендовавшие себя. Частенько эти люди покупаются вместе с их компаниями. Эти люди двигают идеи и мысли, занимаются исследованиями, строят концепты, ездят по конференциям и пиарятся.
2. Набирается и обучается свеженькая молодежь. Это инвестиция в будущее, залог успеха и востребованности технологии.
3. Ну и наконец, помимо крутых интересных инноваций, есть и куча рутинной работы. Ее, я полагаю, выполняют обычные середнячковые программисты с рынка труда. То есть что в гугле, что в любой другой компании эта работа приблизительно одинаковая, и никакой рокет сайенс тут не нужен. Тем не менее, компания пытается поддерживать имидж высокотехнологичной и требует от соискателей решения непростых задач. Хотя со временем, конечно, средний уровень понижается, как и в любой крупной организации.

C# decimal

Нарвался на проблему с точностью представления чисел с плавающей точкой. Вот уж не думал, что это может случиться.
Сначала для представления денежных величин начал использовать decimal. Все бы хорошо, но тут я уперся в требования по времени работы программы. Аналитические вычисления занимали по три дня. Прошелся профайлером, обнаружил, что операции работы с decimal, даже такие простые, как, скажем, инкремент на 1, занимают в общей сложности около 15% времени. Ужаснулся. Я понимаю, что decimal реализован программно и не поддерживается инструкциями процессора, но чтобы настолько медленно, я не ожидал! Попробовал пописать простые тесты, делающие в цикле много примитивных арифметических операций с разными типами - decimal оказался медленнее в десятки раз!
Ну и ладно, подумал я, заменю все на double. Это же не расчет зарплаты, в конце-то концов, а аналитические вычисления, порядка точности должно хватить. Но после очень приблизительных прикидок получилось, что погрешность самого математического метода, да погрешность округлений, накопленная за несколько тысяч операций, в денежной интерпретации дает не такие уж и малые величины.

Блин, что делать? Судя по всему, такие проблемы тривиально не решаются.. То есть надо менять математику вычислений. А это явно за рамками разрабатываемого проекта.

деньги

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

проваленные проекты

Интересно, сколько проектов начинается без четких осознанных целей? У меня постепенно складывается впечатление, что чуть ли не большинство. На ITBlogs, кажется, было обсуждение на эту тему - приводилась статистика причин неудачи проектов. Так вот, неопределенность целей побеждает с большим отрывом.

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

Вот так вот. Имеем - разочарованного инвестора с одной стороны и заработанные деньги с другой. Разработчики при этом относятся либо к разочарованной стороне (если они ответственно и с душой подходили к проблеме), либо к другой, если работали просто за деньги.

Some thoughts on modern job market

I acquired some more experience lately both as interviewer and as interviewee :) While interviewing candidates in my company I applied to some companies myself.

1. Lots of programmers look for a job but almost all of them are not good. The percent of the developers I would compare to myself - and I am not the best programmer ever - is very small. The most part of the candidates cannot even pass a quick yes/no test about their preferred technology. I am not even telling about the overall culture of development, about mathematical or computer science skills. It's really hard to find a good developer that is able to solve tasks and make things work.

2. The average salary level is undefined. You can get two absolutely similar offers with the same requirements but the salary will differ twice.

3. 99% of companies are making web sites. I mean just user interface and a very thin layer of business logic. There is a small number of companies that make really interesting and complicated things. And you know what? They don't need standard mainstream developers that have huge experience in popular technologies. They just need good smart people that are able to think. And even if I was very smart while studying in the university - I would forget all of this stuff working as a mainstream developer! And I can't do anything about this - only self-education. This scares me actually - I feel I'm growing foolish. Mainstream is not always good.

4. I have just realized that the first thing the potential employer does after the first glance to your CV is googles -Hi there, guys! - your name, nickname or mailbox account and gathers any information about you. Anyone is able to find a blog of yours, a couple of forums, communities, networks where you spend your time. They can get a pretty good overview of your interests. This is both good and bad.

Задачка

Задали вот мне леххкую задачку на сообразительность. Сколько пятниц 13 бывает в году? Причем ответ должен быть легким, не сложнее, чем поделить одно число на другое. Почему-то мне не показалось, что это такая уж простая задача. Как бы понятно, что если сделать кучу предположений и считать распределение дней по неделям равновеорятным, а каждый месяц - независимым друг от друга, то ответ будет относительно простой. 13 число одного выпадает на пятницу с вероятностью 1/7, а таких событий в году 12 штук, то вероятность выпадения 13 числа на пятницу во всем году 12/7. Или 12 раз в 7 лет. Но так считать ведь неверно! Месяцы не независимы! Если в одном из них выпало какое-то событие, то во всех остальных достоверно известно, что именно выпадет! То есть нельзя просто умножать на 12. Да и вообще, есть же еще вискососные годы.. Полагаю, что просто так не посчитаешь, надо тупо высчитывать по очереди все дни в пределах одного периода, где период - общий для периодов недель и високосности. То есть надо знать, какие там годы вискосносные, а какие нет.. Короче, вообще нетривиально. В уме не посчитаешь.

П.С. Решение я нашел. У мирового разума.

What sex is computer system?

Я почему-то всегда думал, что компьютер - это "она". Ну как будто бы это не "компьютер", а "машина". Да и вообще, это получается как-то случайно: "Что она пишет?", "И что это она сейчас делает?". Это настолько естественно, что я даже не задумывался на эту тему. Типа как в английском, все корабли и судна, в том числе очень большие воздушные или космические - "she". Из уважения, что ли? Или, как бы это так сказать, позыв души выразить, как много сил уходит, чтобы, мм, добиться от этой штуки ожидаемого?

А тут вот появилось еще одно наблюдение - девушки имеют тенденцию говорить "он".

Что-то за этим все-таки стоит. Надо Фрейда почитать.

Compile-Time Attributes

Вот ведь е-мое, это все только в разработке, оказывается.

http://research.microsoft.com/specsharp/papers/krml135.pdf

Compile-Time Attributes

Я вот тут вдруг подумал, что валидацию параметров методов надо бы делать декларативно.

Самая большая ерунда в том, что самому такую ерунду написать проблематично - ведь для разбора атрибутов придется лазить в рефлекшн, да еще и писать что-то вроде менеджера вызовов, который будет применять логику до вызова метода и после него. Тем более такие штуки, вроде бы, уже есть: http://www.codeplex.com/ValidationFramework. Не думаю, что они очень быстрые, эти штуки.

Надо чтобы компилятор сам впихивал в начало метода соответствующий код. Неужели такого еще нет? Вот блин.

WTF?

private const FileOptions requiredOptions =
FileOptions.Asynchronous | FileOptions.DeleteOnClose | FileOptions.Encrypted |
FileOptions.RandomAccess | FileOptions.SequentialScan | FileOptions.WriteThrough;

private void someMethod(FileOptions options)

{

if ((options & ~requiredOptions) != FileOptions.None)

throw new ArgumentOutOfRangeException("options");

}

Нашел еще один интересный performance-bug

1000 объектов DateTime в Hashtable, обрабатываются раза в 3-4 медленнее, чем 1000 объектов в Generic Dictionary. Вот такая ерунда. Время экономится на операциях boxing-unboxing.

Автоматизация тестов

Как же часто нормальное юнит-тестирование спасало проект и сохраняло мне часы и дни героических боев с багами! Сейчас тесты, наряду с любимым инструментом для рефакторинга, кажутся такими естественными, неотъемлемыми атрибутами процесса программирования, что без них чувствуешь себя буквально без рук. Невероятно раздражаешься, когда приходится лишний раз открывать тормозной отладчик. Гадость в том, что не все поддается автоматическому тестированию. Базы данных еще более-менее побеждаются всяческими там фейками (fake), моками (mock) и прочими ухищрениями, но вот при интерфейс пользователя - полностью ручная работа.

Есть много проблем, которые возникают при попытках автоматизировать UI. Перво-наперво, почему это надо делать?

1. Заказчик, в подавляющем большинстве случаев, мыслит именно в категориях интерфейса. То есть все, что он себе представляет - это внешний вид системы и ее реакцию на действия пользователя. Естественно желание сделать нечто, что сразу же говорит разрабочтику, соответствует результат работы этим требованиям или нет.
2. Если все нижние слои системы покрыты тестами, то UI получается самым слабым звеном. В нем чаще всего появляются и сложнее всего ищутся ошибки. А тратить 20 минут и лезть в какой-нибудь ASP.NET-отладчик, который съест полтора гига оперативки, ради того, чтобы узнать, что какой-нибудь там дропдаун (dropdown) не восстановил состояние из вьюстейта (viewstate), согласитесь, раздражает.

Теперь, какие же все-таки возникают проблемы, помимо самой технической нетривиальности?

1. Там приходится программировать. Это утверждение не кажется таким уж глупым, если учесть, что отделы QA укомплектованы не программистами. QuickTestPro предлагает писать скрипты на бейсике, различные NUnit-библиотеки для ASP используют прямо C#. Кроме того, для каждого теста надо готовить исходные данные, для чего может понадобиться соответствующий навык, чаще всего SQL.
2. Эти тесты ужасно долго работают. В большинстве случаев системы тестирования позволяют записать примитивный макрос - последовательность движений и кликов мышки, нажатия клавиш и т.п. То есть для тестирования веб-приложения система открывает браузер, ходит там по нему, кликает и т.п. Таким образом, это не дает немедленного фидбека разработчику так, как это делают юнит-тесты.
3. Соответственно, тестирование нельзя запустить в фоновом режиме на рабочей машине. Приходится еще и выделять отдельный компьютер. Иногда бывает проблемой.
4. Поддержка написанных тестов в рабочем состоянии - головная боль тестеров. Интерфейс пользователя меняется быстро. В ASP.NET, скажем, стоит положить контрол на страничке в другой контейнер, как его клиентский ID кардинально изменится. Тест поломается, а выполняется он долго, то есть чинить его тоже достаточно долго и неприятно. В итоге все сведется к тому, что тестер плюнет на все, самостоятельно пробежится по страничкам и на глаз посмотрит, что "вроде все правильно".
5. Чувствуется большой недостаток в общении между разработчиками и тестерами. То есть по идее, исходя прямо из тербований заказчика, можно было бы изначально договориться о том, какие элементы управления понадобятся на данном экране. Потом на экран попросту сверху вниз слева направо добавляются все необходимые кнопки, которые пока ничего не делают. На этом этапе тестеру уже есть над чем работать.

Надо сказать, мне кажется, что большинство проблем было бы решено, если посадить за тестирование программистов. Причем не каких-нибудь интернов, а полноценных. Больших технических знаний там не потребуется, но культуры программирования надо не мало. Я ни в коем случае не говорю, что "в топку тестеров", поле деятельности для неавтоматизируемой работы все равно огромно.

Оптимизация

Вчера нашел в приложении интересный перформанс-баг. Ситуация следующая. Есть некий Hashtable и некий набор объектов. В определенных случаях объекты бывают почти одинаковыми, и их достаточно много (больше 1000 штук). Все они пихаются в этот Hashtable, где ключи - специальные объекты, у которых переопределены Equals и GetHashCode.

После этого обнаруживается, что работа с Hashtable занимает какое-то нереальное время. Даже если пробежать по всем ключам и для каждого просто сказать Assert.IsTrue(Hashtable.Contains(key)) - потратим несколько секунд!

Баг в том, что реализация GetHashCode ключа почти всегда возвращала одинаковые значения. Hashtable, по идее, должен строить бинарное дерево по хэш-кодам своих элементов. Если хэш-коды для каких-то объектов совпадают, то в соответствующий узел дерева кладутся все такие объекты в простом связном списке. А если разных хэш-кодов всего-то, скажем, два, то получаем два списка по 500 значений в каждом, поиск в которых выполняется тупым перебором.

Agile documents

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

Мы пробовали уже много разных способов фиксации требований и обсуждений.

1. Самый экстремальный подход - только устное общение, либо общение по различным мессенджерам - очень хорошо действует в начале разработки, когда у проекта еще нет истории, нет наследованного кода, и поэтому все решения принимаются легко и единогласно. Бизнес приблизительно знает, чего он хочет. Мы приблизительно знаем, как мы это будем делать - вот и делаем наиболее простым и понятным способом. Со временем, когда из проекта получается нечто работающее, бизнес начинает конкретизировать свои желания, у них появляются идеи о новом функционале или просто новых бантиках, которые им не приходили раньше в голову. Иногда они видят, что то, что они хотели, на самом деле не так удобно и не так красиво, как им там мнилось, что на самом деле можно и так, и эдак. Вот тут при устном общении начинаются проблемы. Частенько совершенно не понятно, какое из принятых ранее решений сейчас в силе. Более того, со стороны бизнеса начинаются разногласия, и чаще всего они возникают уже после того, как разработчик реализовал какое-то решение. А все потому, что беседа велась по аське с одним человеком, когда остальные были на обеде. И потом, далеко не каждый мессенджер обладает нормальной функцией поиска по истории.

2. Результаты обсуждений в почте - вообще неприемлемо. Там постоянно образуется по нескольку версии одного документа, и далеко не всегда понятно, кто кому на какой вопрос отвечал.

3. Просто документы с контролем версий - это формализм. Ведение вордовых и экселевых документов - это не "гибко". Это не двусторонее общение, это не коммуникации - это постулирование и констатация требований. В теории, если правильно вести документы, то все будет, казалось бы, отлично. Но тут сыграет свою роль человеческий фактор. Кто будет фиксировать в документе все изменения и следить за актуальностью? Специально выделенный человек? Он не будет этого делать. Чтобы делать это, надо хорошо разбираться во всем проекте. А тем людям, которые хорошо разбираются во всем проекте, обычно не до этого. Чаще всего таким человеком назначают ("назначают" - опять какое-то слово из не-agile лексикона) либо самого младшего со стороны бизнеса, который и в самой предметной области проекта не очень-то шарит, либо бизнес-аналитика, который будет заниматься только ведением документов, то есть станет единственным бюрократом в проекте. За это его перестанут любить и начнут игнорировать. И вообще, формальность отношений в команде противоречит религии "agile" :).

4. Вероятно, wiki очень неплохо зарекомендовала бы себя, но для нашего бизнеса wiki в новинку. Кроме того, в вики достаточно удобно фиксировать уже сложившиеся требования, но неудобно вести обсуждения. Вики хорошо подходит для энциклопедии, для хелпера - но не для коммуникаций.

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