Дружба

Забыл опубликовать, поэтому появляется только сейчас.

Нельзя пожать друг другу руки со сжатыми кулаками.

Индира Ганди

Как приятно с утра, когда на улице стоит отличная погода предаться мечтаниям! Вот и Леша, заварив себе чашку превосходного зеленого чая, уселся поудобнее в большое кожаное кресло, которое ему подарили друзья на 25 летие, и стал думать о том, как он потратит заработанные деньги. Если знать Лешу недостаточно долго, то можно сложить о нем впечатление поверхностного и в большой степени эгоистичного человека, для которого материальная выгода стоит выше духовного богатства. Но это лишь отчасти правда. Леша любил тратить деньги. При этом он редко когда задумывался о других и спускал свои сбережения со скоростью пули в основном лишь для собственного увеселения. Однако делал он это исключительно из-за своей простоты деревенского парня, в один прекрасный день перебравшегося в столицу. Он никогда не думал о других не потому, что ему было все равно. Такие мысли вообще не могли посетить его головы так же, как сложно себе представить литератора решающего дифференциальные уравнения.
Помимо прочего, Леша очень любил играть в карты. Нередко он полностью проигрывался, надеясь, что на следующей раздаче ему уж точно повезет. Вот и сейчас, Леша сидел , мечтая о том, как он отыграется, купит себе дом, машину и больше никогда не будет ни в чем нуждаться. К сожалению, как это часто бывает, Леша никогда не умел вовремя остановиться и даже выигранные изредка деньги, не могли у него задержаться надолго. Но мечты! Мечты уносили Лешу далеко в те места, где у него была своя прислуга, одетая в кружевные наряды, как это было принято в эпоху Ренессанса, конюшня с прекрасными жеребцами и несколькими большими хаундами, охранявшими его дом от посягательства чужаков.
Внезапно раздался телефонный звонок, который выдернул Лешу из его мечтаний и вернул к суровой действительности. Немного расстроившись, Леша поднял телефонную трубку и услышал уже привычные вопли начальника о новой партии товара, которую срочно нужно доставить на склад. Осознавая, что у него сегодня выходной, Леша тем не менее не решился спорить и согласился через час подъехать к заводу, чтобы забрать товар. А как было не согласиться, когда сверхурочные оплачиваются по двойному тарифу, а Леша был должен своему другу Саше еще с прошлого месяца после крупного проигрыша.
Выйдя из дома, Леша сел в грузовик и вырулил на шоссе по направлению к заводу, где его фирма закупала весь товар для дальнейшей продажи. В компании дела шли не важно, и ситуация не собиралась улучшаться. Но так как зарплату не задерживали и не заставляли, за редким исключением, работать больше положенного, Леша и не думал жаловаться. Многие из его друзей находились в гораздо худших условиях, боясь остаться без заработка.
За стеклом сияло солнце и мысли Леши постепенно вернулись к его мечтам о сказочном богатстве, которое он в один прекрасный день обязательно выиграет в карты.
На автомате управляя автомобилем, Леша не заметил, как на пешеходном переходе на дорого вышел молодой парень. К реальности его вернул глухой удар головы парня о лобовое стекло грузовика. Капли крови, брызнув из раны стали образовывать причудливые узоры на стекле, расходясь, словно лучи солнца, в разные стороны. Застывшая улыбка на лице парня так и не успела смениться на другую эмоцию, которая лучше бы подходила под ситуацию. Глаза его уже ничего не видели, лишь только внутренности, распоротые какой-то из деталей автомобиля вываливались из его живота, будто какие-то живые организмы, представляя собой ужасающее зрелище. Леша резко ударил по тормозам, но так и не смог остановится до того, как грузовик переехал отброшенное ударом тело мальчика, перемалывая в кровавое месиво то, что осталось от его лица.
Сказать, что Леша был расстроен - не сказать ничего. Он вряд ли скоро сможет поиграть в карты. И лишь одна мысль немного успокаивала его - уже не придется отдавать карточный долг Саше. Это событие стало началом конца их крепкой дружбы.

О зарплате программистов

Сегодня беседа с одной своей знакомой программисткой навела меня на рассуждения о том, как же все-таки надо оценивать затраты труда программиста. Вот я и решил поделиться своими соображениями. Сразу оговорюсь, что я не являюсь экспертом в этой области (имею ввиду оценки производительности), и все нижесказанное является плодом моего воображения, критику к которому я с удовольствием приму в комментариях.
Для меня производительность - это характеристика, показывающая, насколько эффективно один человек работает. Сама по себе эта характеристика бесполезна ввиду того, что никак не позволяет влиять на "цену" этого сотрудника. Если существует всего один программист, то его цена никак не связана с его производительностью. Поэтому интереснее рассматривать производительность как способ влиять на цену труда программиста в контексте рынка, когда конкуренция устанавливает цены. Здесь гораздо важнее становится относительная производительность, показывающая насколько один программист лучше другого. Так как же можно измерить эту величину?
Я считаю, что за некоторыми исключениями, никак. Рассмотрим различные способы, которые я нашел в интернете:

• Количество строк кода. Наверное самый идиотский способ, которые едва ли применяется где-либо на практике. Эта характеристика не показывает вообще ничего, что не является секретом для любого, кто сталкивался с программированием.
• Количество реализованных сценариев (use cases). В теории это могло бы считаться адекватным способом измерить производительность, поскольку опытный программист может оценить сложность одной задачи относительно другой. Но появляется сразу несколько нюансов: задачи могут зависеть друг от друга, некоторые задачи могут иметь низкую сложность, но занимать много времени (пример - однотипный рефакторинг под уже запрограммированную архитектуру в противовес разработке архитектуры даже небольшого участка системы). В итоге становится непонятным, как сопоставлять сложность и длительность работы над задачами. Как оценить, что один человек работает производительнее другого?
• Гипотетический случай, когда программисты делают одну и ту же задачу, а затем сравниваются результаты. Даже в этом случае нельзя судить о производительности, если только вы не намереваетесь платить за конкретно эту задачу. Выбор подхода, например, чаще всего является субъективной категорией для более менее больших систем.

Наверняка есть и другие способы цифрами оценить, насколько один программист лучше другого. Я считаю, что ни один из них нельзя использовать как достоверный. Это связано с тем, что написание кода представляет собой творческий процесс, который уникален (очень часто, хотя и не всегда) для различных задач. В связи с этим программисты будут вести себя по разному в зависимости от поставленных целей. Здесь я даже не пытаюсь учесть влияние внешних факторов, которые тоже могут менять ситуацию.
Но как тогда можно решить. кому сколько платить? Я бы выделил 2 варианта для относительной оценки производительности программиста:

1. В силу опыта и знаний, один программист может выполнить работу, которую второй выполнить в принципе не в состоянии, либо не сможет сделать этого за какое-то разумное время. Например, я не представляю себе, чтобы я смог спроектировать операционную систему даже в общих чертах. У меня банально не хватит опыта решения архитектурных задач, чтобы это сделать. Я бы назвал этот пункт единственно возможным способом объективно разделить программистов. Это я и имел ввиду под исключением. Но здесь идет деление на "уровни", на каждом из которых по-прежнему много людей.
2. В каждой команде есть менеджер. И этот человек является ключевой фигурой в оценке производительности. Очевидно. что его суждения всегда носят субъективный характер. Но он  руководствуется двумя вещами: ситуацией а рынке и в команде. Программисты так или иначе представляют уровень зарплат коллег, а значит могут оценивать затраты и отдачу в работе. Если в команде нет по этому поводу конфликтов, значит менеджер держится хорошо в плане оценки производительности. А корректировать стартовую точку ему вполне может помогать ситуация на рынке. Иначе команда может распасться ( это тоже упрощение, конечно) из-за неадекватной оценки  в целом. В принципе рынок можно было бы не рассматривать, а обобщить пример в том смысле, что все представляют зарплаты всех, а задач менеджера дать тебе оценку относительно рынка, с которой ты был бы согласен.

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

Как я ходил на первый митап по MongoDB

О MongoDB я услышал уже достаточно давно. Услышать-то я услышал, но что это такое никогда особо не интересовался. Мои знания всегда ограничивались тем, что это такая NoSQL база, с которой можно общаться на JS.
И тут вдруг появляется юзер группа, а сразу за ней митап по этой самой базе данных. Такого, я, естественно, не мог пропустить, причем сразу по двум причинам. Во-первых, давно хотелось познакомиться с чем-нибудь подобным, а во вторых мне всегда хотелось посетить встречу, где я буду настолько не в теме, что даже вступительный доклад позволит узнать мне много нового. Второе продиктовано тем, что на стандартных конференциях по .NET рассказывают в основном стандартные вещи, которые чаще всего мне и так известны.
Накануне встречи я решил, что нужно ознакомиться хотя бы с основами, чтобы понимать, о чем вообще мне будут рассказывать. И вот, вооружившись компьютером и желанием узнать что-то новое, я пошел на mongodb.org и несколько часов пытался экспериментировать с первой в моей жизни NoSQL базой данных. Стоит признать, что я действительно очень впечатлился и получил нужный заряд мотивации для дальнейшего изучения.
Придя на митап, я сразу же узнал две новых вещи: у эпама реально крутой офис на Независимости 186, а еще то, что-кто-то все таки пользуется Google Hangout (мы связывались с челами из Штатов, которые высказали свои поздравления в связи с созданием юзер группы).
Первый доклад, что вполне логично, был введением в то, что же из себя MongoDB представляет. Сначала было много положительного относительно возможностей, которые, к слову, впечатляют. Когда начались вопросы, оказалось, что все не так уж и гладко. Две самых главных вещи, которые меня расстроили - это проблемы с надежностью и тот факт, что MapReduce отрабатывает в одном потоке. С другой стороны, это в очередной раз навело меня на мысль, что не стоит применять традиционные подходы к решению задач, к инструменту, который работает по-другому. Похожее ощущение у меня было, когда я знакомился с Erlang. Вроде возможности схожи с объектно-ориентированными языками, но надо понимать, что эффективно позволяет работать именно правильный подход.
Следующим докладом нам рассказали о проблемах на реальных проектах и о том, как такие проблемы можно решать. На самом деле для меня оказалось важным, что по сути мое первое знакомство с MongoDB не было просто рекламой этой базы данных. Естественно, я не в курсе всех нюансов, но подход, когда видны не только положительные, но и отрицательные стороны позволяет изначально настроится на то, что для использования придется не просто изучить API, а проникнуться идеологией что ли. Что-что, а проникаться новой идеологией я очень люблю :)
По факту получился отличный митап, где даже не монго было самым главным. Гораздо важнее то, что предоставилась отличная возможность познакомиться с людьми, которые полны энтузиазма и рвения изучать что-то новое и делиться своими знаниями.  Очень рад, что сходил, даже если в итоге мои пути с MongoDB разойдутся.

P.S. Ах да, чуть не забыл. Когда после митапа мы сидели за пивом и пиццей, то немного попугали одного студента по поводу того, насколько же уныла и ужасна работа программиста в Беларуси. Дима, на самом деле главное - это проект, куда ты попадешь, так что не надо думать, что все так уж плохо. С хорошим менеджером и интересной задачей абсолютно не важно в какой компании ты работаешь, как не важно это и в случае плохого менеджмента/проекта.