[prog.work] Ох, чую, что ничего я не буду стоить на собеседовании

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

Почему-то вспомнилась шуточная фраза, которую на первом курсе универа нам высказал очень умный преподаватель: школа отличается от университета тем, что после школы ты можешь поступить в университет, а вот после университета поступить еще раз – уже не сможешь.

Вот и у меня уже на третьем десятке лет увлечения программизмом что-то похожее проявляется :)

А вообще, я снова авралю. Посему в блог пишу мало. Но обязательно что-нибудь постараюсь написать в ближайшее время. И о программировании тоже.

[life.sport] Склерозник: сетки турниров “двойное, тройное и т.д. дыхание”

На случай, если кому-нибудь понадобится проводить спортивные турниры по системе “двойное дыхание” вот интересный сайтик: http://www.tournamentdesign.org/

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

PS. На случай, если кто-то, как я совсем недавно, не знает, что такое “двойное дыхание” или “минуска”, или “двушка”. Это такая система игры на выбывание, при которой участник покидает турнир не после одного поражения, как в простой олимпийской системе “игры на вылет” (плей-офф), а после двух. Т.е. ведется как бы два параллельных плей-оффа – верхняя сетка виннеров (т.е. игроков, которые пока не проиграли ни одной игры) и нижняя сетка лузеров (т.е. игроков, которые проиграли одну игру). Проигравшие в сетке виннеров продолжают турнир в сетке лузеров. Проигравшие в сетке лузеров выбывают окончательно.
Подробнее в Wikipedia на русском и на английском.

[life.work] Интересно было бы узнать о дальнейшей судьбе хаскельных проектов в ПроСофте

Несколько месяцев назад я упоминал о необычной вакансии в компании ПроСофт. Не так давно проскакивала информация о том, что вакансия еще не закрыта (что, на мой взгляд, не удивительно). И вот теперь продолжение истории: Сергей Зефиров aka thesz упомянул в своем блоге, что он работает уже в Parallel Scientific.

Не знаю точно, ушел ли он из ПроСофта или нет. Но если ушел, то очень интересно было бы со временем услышать, какова оказалась дальнейшая судьба тех хаскельных разработок, которые Зефиров вел в ПроСофте. Ведь если та работа держалась на нем, то найти замену для дальнейшего развития проекта (да еще на таких финансовых условиях) будет непросто даже в Москве. Хотя еще большой вопрос, была ли эта разработка mission critical для компании, или же это был просто исследовательский pet project (ну или proof-of-concept, если сохранять политкорректность).

В любом случае интересно, но вряд ли до меня такая информация когда-нибудь дойдет.

PS. Почему я затрагиваю эту тему. А потому, что меня, как паталогического велосипедостроителя, волнуют два аспекта. Первый: есть ли смысл для компаний, закладываться на экспериментальные разработки, которые делают уникальные харизматичные программисты? Второй: каковы границы моральной ответственности самого “гениального разработчика”, который “подсаживает” работодателя на свой велосипед?

[life.wow] Завораживающе красивое разрушение моста взрывом

Взрыв моста Fort Steuben Bridge 21 февраля 2012. Кстати о нумерологии: вот таким вот числом оказалась вчерашняя дата для этого сооружения ;)

Снимок найден в очередном номере WSJ’s Photos of the Day.

На YouTube есть несколько роликов разного качества, которые показывают все это в динамике. Например, вот этот.

[life.numerology] 21022012

Таки сегодняшняя дата :) Симметрия, однако!

[prog.flame] Цитата из академика Крылова на тему веры в математику

После того как я прочел книгу академика Алексея Николаевича Крылова “Мои воспоминания” жаркие споры на профессиональных формах о том, что программисты недостаточно используют математику, что когда космические корабли бороздят программы будут записываться как доказательства теорем и т.д., я невольно вспоминаю большую главу из этой книги под названием “Служба в Военно-морской академии и в Академии наук” (и ее раздел “Значение математики для кораблестроения”). Процитирую оттуда один фрагмент для демонстрации:

Знаменитый английский натуралист лет 70 тому назад сказал: «Математика подобно жернову перемалывает лишь то, что под него засыплют». Вы видели, что в строгой эвклидовой математике эта засыпка состоит из таких аксиом и постулатов, в справедливости которых инженер усомниться не может, а так как лишь эти аксиомы и постулаты «перемалываются» без добавления новых (а если что добавляется, то должно быть точно и ясно указано), то инженер и придает такую веру математическому доказательству. Но здесь необходимо постоянно иметь в виду следующее обстоятельство: когда конкретный вопрос приводится к вопросу математическому, то всегда приходится делать ряд допущений, ибо математика вместе с механикой оперируют над объектами идеальными, лишь более или менее близкими к объектам реальным, к которым инженер будет прилагать полученные математические выводы. Ясно, что сколько бы ни было точно математическое решение, оно не может быть точнее тех приближенных предпосылок, на коих оно основано. Об этом часто забывают, делают вначале какое-нибудь грубое приближенное предположение или допущение, часто даже не оговорив таковое, а затем придают полученной формуле гораздо большее доверие, нежели она заслуживает, и это потому, что ее вывод сложный.

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

[work] И вновь KPI: мою писанину обсуждают на Хабре

Оказалось, что ссылку на мою довольно старую заметку о KPI дали в обсуждении статьи на Хабре. На данный момент интересующая меня цепочка комментариев выглядит так:

• Malenkov 19 февраля 2012, 01:13
  Есть мнение, что если сотрудник знает критерии оценки своей деятельности, то будет всячески стремиться улучшить свои показатели. В том числе способами, которые негативно скажутся на результате деятельности.
  
  Как-то так.
• JuliyaErina 19 февраля 2012, 01:27
  Malenkov, cпасибо за статью! Очень в тему!
• safright 19 февраля 2012, 09:11
  Если критерии подобраны именно что формально, а оценка может вихлять в отрыве от противоречивых требований — то да, лучше этот мрак не показывать, взломают и используют.
  
  В приведенном примере KPI взят из пальца в потолке: количество строк кода слабо влияет на правильность работы программы, а кроме исполнимости сроков есть еще время, затраченное на проект определенной сложности (оно, конечно, может внезапно вырасти и т.п., но ведь на то и начальник сидит).
  
  ИМХО: параметры должны быть качественно завязаны на реалии предметной области и, в ряде случаев, могут и должны быть противоречивы.
• kibitzer 19 февраля 2012, 11:50 
  Вы правы, тогда стремление соответствовать адекватным критериям (зная их заранее), будет только на пользу общему делу.

Вот комментарии от safright и kibitzer откровенно доставляют. Идеалисты, однако.

Не буду заострять внимание на “KPI взят из пальца на потолке”. Хотя навскидку могу насчитать всего три критерия оценки работы программиста, которые выражаются количественно:

• время на разработку;
• количество строк (кода|комментариев|тестов|…);
• количество дефектов.

Сделать же акцент хочется на совершенно убийственном фрагменте из комментария safright: параметры должны быть качественно завязаны на реалии предметной области и, в ряде случаев, могут и должны быть противоречивы.

Противоречивые параметры оценки производительности сотрудника – это как вообще?

Например, красиво обещает, но нихуя не делает – это в тему? Скажем, “красота обещаний” – это первый критерий, а “полнота выполнения обещаний” – второй. И если по первому критерию набрать пять баллов из пяти, а по второму – два из пяти, то общий результат – семь баллов. И это лучше, чем один балл за “красоту” и пять за “выполнение”, ведь в итоге всего лишь шесть баллов, а не семь. Так получается, что ли?