Хорошие IT-статьи

Как положить спасибо в карман

Tue, 20 Mar 2012 20:32:00 +0600

Эссе Джоэля Спольски (Joel Spolsky) о мотивации, о денежных премиях и о том, что делать с сотрудником, если его идея принесла вашей компании миллион долларов. Оригинал статьи на английском языке можно прочитать здесь.

Джоэль Спольски — один из создателей сайта stackoverflow.com и ведущий блога joelonsoftware.com.

Два года назад студент по имени Ноа Вайс (Noah Weiss), проходивший летнюю стажировку в нашей фирме Fog Creek, поделился со мной отличной бизнес-идеей. Он обратил мое внимание на то, что довольно много сайтов IT-тематики размещают платные объявления о вакансиях, и предложил мне делать то же самое на страницах моего блога Joel on Software. По словам Ноа, написать систему показа таких объявлений будет проще простого («Это же просто еще одна таблица в базе!»). А для других продуктов у нас уже были готовые модули для приема банковских карт и генерации платежек, так что проект действительно выглядел несложным.

Но я колебался. До этого я не размещал рекламу в своем блоге, и, честно говоря, вовсе не планировал переводить его в коммерческое русло.

Однако Ноа настаивал на своем: «Ребята из 37signals каждый месяц показывают на своем сайте 50 новых вакансий. За размещение каждой вакансии они берут с работодателя 250 долларов, и…»

«Подожди-ка, 250 долларов за одно объявление в месяц? Я думал, что размещение вакансии должно стоить, ну я не знаю, доллара четыре?»

«Так точно, 250 долларов. Более того, размещение вакансии — это не то же самое, что размещение рекламы. Это помощь людям, а не желание нажиться на них.»

Но к этому моменту я уже перестал его слушать. В моей голове закрутились маленькие шестеренки: 250 долларов за одно объявление, 50 объявлений в месяц, 12 месяцев в году… Да на эти деньги я смогу нанять еще одного программиста в команду! И я согласился. Мы немедленно начали добавлять показ вакансий на мой сайт. Ноа написал основной код за две недели, и еще две недели я исправлял мелкие недочеты и доводил систему до ума. В итоге, весь проект стоил нам около месяца работы.

Цена в 250 долларов нас не устроила, и мы выставили ценник в 350 долларов. Действительно, почему бы и нет? Я решил, что мы можем вывести себя в премиум-сегмент очень простым образом — задрав цену до премиум-уровня. В отсутствии дополнительной информации покупатель чаще всего судит о качестве товара по его цене. Так пусть наш сайт станет Лексусом среди сайтов с вакансиями! (Стоит отметить, что спустя несколько месяцев после запуска нашей системы 37signals подняли свою цену с 250 до 300 долларов.)

К сегодняшнему дню этот крохотный проект, на который мы потратили месяц работы, принес нам миллион долларов — почти 100% всей нашей прибыли.

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

Но мы решили не жадничать и как-то отблагодарить Ноа. Но как? Купить ему Xbox 360? Выдать ему денежную премию? Вручить ему красивую благодарственную грамоту, распечатанную на плотной бумаге? Подарить ему футболку с надписью «Моя идея принесла нашей компании миллион долларов, и все, что я получил взамен — эту дурацкую футболку»? Куча вариантов, но ни один не показался нам достойным.

А как насчет остальных наших сотрудников? Они тоже выполняют свою работу, и ничуть не хуже, чем Ноа. Тот факт, что идея одного сотрудника принесла нам миллион, вовсе не означает, что вся остальная команда внесла меньший вклад в наш бизнес. В то время, когда Ноа реализовывал систему размещения объявлений, наша команда заканчивала новую, шестую версию нашего багтрекера Fogbugz, которая удвоила нашу выручку практически сразу после релиза.

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

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

Тем не менее, психологи считают, что в некоторых условиях внешняя мотивация все-таки может подавлять внутреннюю. Тот факт, что вы премируете ваших сотрудников за хорошо сделанную работу, приучает их к мысли, что они занимаются своим делом только ради денег. Если премии не ожидается, то стимула хорошо работать тоже нет: внутренняя установка «делать свою работу хорошо» вытесняется осознанием того, что качество работы не будет оценено материально.

Кроме того, как только вы начнете отмечать хорошую производительность сотрудников премиями, они немедленно начнут сравнивать себя с коллегами: почему я получил меньше, чем он? И такие вопросы вполне правомерны. Как вы определите, что ценнее в денежном эквиваленте: баг, который Дэвид пофиксал во вторник, или фича, которую Тэд реализовал в среду? Если бы у нас был цех по пошиву мужских трусов, то все было бы гораздо проще: Дэвид сегодня сшил пять трусов, а Тэд — семь; значит, Тэд получит на 40% больше денег.

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

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

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

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

Ноа был польщен этим подарком, и мы надеялись, что это побудит его продолжить работу в нашей компании, но… он решил не оставаться у нас. Google сделал ему более интересное предложение. Кстати, вот и еще один недостаток пропорциональных премий: на любую, даже достаточно серьезную сумму денег, которую вы выплачиваете сотруднику, богатый конкурент может просто ответить большей суммой — и забрать человека себе.

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

Почему я не провожу собеседования

Tue, 21 Feb 2012 14:48:00 +0600

Перевод статьи Джейсона Фридмана (Jason Freedman) “Everyone Sucks at Interviewing. Everyone.” Оригинал статьи можно прочитать здесь.

Идея проведения собеседований при приеме на работу кажется мне порочной и бессмысленной. Каждый работодатель слепо идет по стандартному пути, состоящему из публикации вакансий, обработки резюме и собеседований с кандидатами, ни разу не подумав, действительно ли это именно то, что ему нужно. Я считаю, что этот стандартный путь совершенно неприменим в сегодняшних реалиях.

Последние несколько лет я с большим интересом изучаю все, что связано с отбором и наймом сотрудников. Найти хорошего специалиста безумно сложно, и я вряд ли смогу назвать много фирм, у которых это хорошо получается. Даже у самых успешных в этом отношении компаний есть страшный секрет, заключающийся в следующем: как бы хорошо ни был организован процесс отбора, он все равно не может гарантировать, что нанятый сотрудник преуспеет на новом месте. Ходят слухи, что даже сложнейшие системы оценки кандидатов, применяемые HR-отделом Google, не в состоянии точно предсказать эффективность будущего сотрудника. Некоторые компании отмечают, что единственный показатель, который хоть как-то корреллирует с успешностью молодых разработчиков, — это их результаты в тесте SAT (американский аналог ЕГЭ).

По словам Пола Инглиша (Paul English), техдиректора фирмы Kayak, разрабатывающей интернет-платформу для бронирования отелей и авиабилетов, ему приходится увольнять каждого третьего нанятого сотрудника — и он считает это довольно хорошим показателем!

То есть руководитель компании, имеющий многолетний опыт работы с кандидатами, все равно ошибается в 33 процентах случаев? Плохо дело! Но при этом не стоит забывать, что Kayak – крупная и стабильная компания, и расставание с одним-двумя работниками, как правило, не создает ей особых проблем. А вот многие стартапы, в силу нестабильности ситуаций, в которых они работают, не могут так просто уволить неэффективного сотрудника.

«У нас на носу первый релиз, мы не можем позволить себе выкинуть одного человека из команды…»
«Инвесторы как раз начали финансирование, увольнение вызовет много вопросов…»
«Давайте дадим ему еще три месяца и посмотрим, что получится…»

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

Я не провожу собеседований. Совсем.

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

Если кандидат завершает свой проект на «отлично», то он получает от нас предложение о приеме на работу. К этому моменту мы уже не задаемся вопросами о том, какая квалификация у этого человека и какие задачи можно ему давать: мы уже проверили его в деле. Кандидат к этому моменту тоже знает все плюсы и минусы нашей компании и стиль работы нашей команды. И он примет (или не примет) наше предложение о работе, прекрасно представляя себе все наши особенности.

А бывает, что кандидат не справляется с проектом. Тогда мы желаем ему всего наилучшего и в придачу даем ему пару советов, как найти ту позицию, которая ему больше всего подойдет. И мы благополучно пропускаем всю бюрократию, связанную с увольнением человека из штата, не тратим по полгода на бесплодные попытки сработаться или «подтянуть» сотрудника и избегаем неудобных разговоров о его судьбе за закрытыми дверями.

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

Но мы никогда, никогда не проводим нудных собеседований с задачками на сообразительность и вопросами по алгоритмике. Почему? Да потому что ни то, ни другое не пригодится человеку при работе у нас.

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

Джоэль Спольски: перестаньте делать бэкапы

Wed, 15 Feb 2012 13:11:00 +0600

Перевод небольшой заметки Джоэля Спольски (Joel Spolsky) “Let’s Stop Talking About Backups”. Джоэль — один из создателей stackoverflow.com и ведущий блога joelonsoftware.com.

Вы бэкапите данные со своей рабочей машины?

А с производственных серверов?

Вы храните бэкапы на том же диске, или переносите их на другую машину?

Переносите ли вы серверные бэкапы в другой дата-центр?

Всё это — стандартный набор вопросов для проверки квалификации системного администратора.

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

Ведь в этом случае выясняется, что:

Вы шифровали бэкапы симметричным ключом, а единственная копия этого ключа хранилась именно на том диске, который сгорел
Вы бэкапили только содержимое ваших веб-сайтов на ASP.NET, а огромную IIS metabase оставляли без внимания
Ежедневный дамп вашей базы данных делался на FAT32-раздел, где он автоматически обрезался до 2 Гб без сообщения об ошибке
Ваш хостер автоматически бэкапил данные со всех серверов на ленточные носители, но именно ваша кассета затерялась на складе, и ее поиски заняли три дня
а также множество других, не менее интересных историй, которые полностью перечеркивают тот факт, что вы делали бэкапы.

Просто делать бэкапы недостаточно. Нужно быть уверенным, что в случае необходимости вы сможете их восстановить.

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

И если вы можете восстановить свой сайт в таких условиях — значит вы правильно делаете бэкапы.

Так что перестаньте просто делать бэкапы. Начните их восстанавливать.

Почему в нашей компании нет менеджеров

Tue, 07 Feb 2012 14:30:00 +0600

Перевод статьи Джейсона Фрида (Jason Fried) “Why I Run a Flat Company”. Джейсон — один из основателей компании 37signals и соавтор книг “Getting Real” и “Rework”.

Несколько месяцев назад в компании 37signals, которую я возглавляю, случилось необыкновенное событие: мы расстались с одним из наших сотрудников. Казалось бы, что в этом необычного? Но дело в том, что в нашей компании подобное происходит крайне редко. За 11 лет работы мы потеряли всего лишь пять человек, причем один из них вернулся к нам семь лет спустя.

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

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

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

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

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

Схема горизонтального роста превосходно работала не один год, но с ростом компании (сейчас у нас уже 26 сотрудников) начала давать сбои. Многие предприниматели знают, что как только бизнес дорастает до определенного размера, его владельцу приходится думать о вещах, о которых он раньше и не задумывался. В нашем случае такими вещами оказались термины из мира HR: отделы, менеджеры и названия должностей.

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

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

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

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

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

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

Огромное преимущество такого подхода в том, что он позволяет избавиться от вечного непонимания между менеджерами и исполнителями, когда ни те, ни другие толком не представляют, что происходит по другую сторону баррикад. В нашей ситуации каждый сотрудник знает, что вскоре ему самому придется оказаться в кресле руководителя, поэтому к своему текущему руководителю он относится с большим пониманием. Это напоминает мне высказывание американского философа XX века Джона Ролза (John Rawles): «Самый справедливый свод правил — тот, с которым согласится каждый человек, не зная заранее, какой властью он будет наделен». Возвращаясь же к эффективности нашей команды — такая «карусель» оказалась чрезвычайно полезным приемом: команда стала работать гораздо слаженнее, и клиенты были довольны как никогда.

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

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

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

Обсудить статью можно здесь или на Хабре

Запоздалая оптимизация

Tue, 23 Aug 2011 12:11:00 +0600

Перевод статьи Дениса Форбса (Dennis Forbes) “The Sad Reality of Post-Mature Optimization”. Превосходные иллюстрации также взяты из оригинальной статьи.

Знаменитое утверждение «преждевременная оптимизация — корень всех зол» принадлежит перу Дональда Кнута. К сожалению, изначальный смысл этой фразы давно утерян, и в последнее время её используют лишь как отговорку, позволяющую отбиться от любых претензий к скорости работы программы.

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

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

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

Когда вы натравливаете профилировщик на проект, написанный под лозунгом «скажем “нет” преждевременной оптимизации!», вы ожидаете увидеть что-то в этом духе.

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

В большинстве случаев профилировщик нарисует вам вот что:

Эта ситуация абсолютно типична. Если вы не задумались об производительности с первых дней проекта — поверьте, вы не вспомните о ней до самого конца. Не надо тешить себя надеждами типа «мы найдем самую неэффективную функцию, быстренько ее оптимизируем, и всё сразу заработает быстрее!». При таком подходе зараженными окажутся все функции, и точечное лечение вам не поможет. Закон Мура тоже не придет вам на помощь: производительность отдельно взятого процессорного ядра практически не меняется вот уже несколько лет. Девять женщин никогда не смогут родить ребенка за один месяц; так и в вашем случае мечты о том, что рано или поздно хорошее железо позволит вашей программе работать быстро, разобьются о физические ограничения.

Хотите примеров из жизни? Пожалуйста. Минимальное время рендеринга одной страницы бизнес-портала SugarCRM — в районе 100 миллисекунд, даже на самом лучшем железе. В мире веб-приложенй такое положение дел никого особо не смущает (все уже давно привыкли к тому, что каждый клик на веб-странице обрабатывается по несколько секунд), но ситуация дошла до того, что малое время отклика стало для некоторых веб-сервисов серьезным конкурентным преимуществом. Мне очень нравится интернет-радио Rdio, но если я найду его аналог, который не будет доставать меня секундными задержками между переключениями страниц, то я немедленно перейду на него.

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

Подытожу вышесказанное: полезный принцип, высказанный Кнутом, был доведен до полного абсурда. Когда кто-то говорит о преждевременной оптимизации, он почти наверняка имеет в виду совсем не то, что имел в виду Кнут.

Пиши код блять!

Tue, 29 Mar 2011 13:20:00 +0600

Вольный перевод статьи Зеда Шоу (Zed A. Shaw) “Programming, Motherfucker!” (http://oppugn.us/posts/1300784321.html) под влиянием стилистики сайта http://fucking-great-advice.ru

Сегодня я расскажу вам об уникальной методологии разработки ПО. Уверяю вас, она произведёт настоящую революцию в нашей индустрии. Почему? Да потому что она разительно отличается от тех теорий, которыми вас досыта накормили заумные книжки и дурацкие статьи в интернетах. Существующие методологии заставляют вас запоминать сотни баззвордов, высчитывать какие-то непонятные метрики или даже (о ужас!) предлагают пустить работу на самотёк и сделать вашу команду самоорганизующейся.

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

Именно так. Пиши код блять!

Как мы добавляем фичи в проект? Мы блять пишем код!

Как у нас поставлено тестирование? Мы блять пишем автотесты!

Как мы умудряемся поставлять релизы в срок и в рамках бюджета? Мы блять пишем код качественно и быстро!

Почему наши программисты счастливы и с удовольствием ходят на работу? Потому что они блять пишут код и не отвлекаются на всякую херню!

Конечно, на деле не все так просто, Одной идеи совершенно недостаточно для того, чтобы перестроить всю вашу команду. Поэтому вот вам пошаговая инструкция для внедрения нашей замечательной методологии:

Выпишите список всей той хрени, которая должна входить в ваш продукт
Реализуйте всю эту хрень путем блять написания кода
Протестируйте написанное
Если что-то работает неправильно — то напишите блять правильный код!

После п.4 немедленно переходите к п.1. Повторять до достижения необходимого результата.

Здорово, правда? Помните, что написание кода — это блять самая важная вещь во всём процессе разработки! А все прочие идеи, которые вы могли видеть в конкурирующих методологиях, я предлагаю подытожить вот таким принципом:

Менеджер, твою мать, облегчи жизнь программисту!

Чтобы программисты могли блять писать код, менеджеры, мать их, должны по возможности облегчать программистам жизнь. Менеджер, мать его, должен делать всё возможное, чтобы код блять писался хорошо: отслеживать процесс написания блять кода, заботиться о том, чтобы заказчики вовремя платили за всю написанную нами хрень, и (самое главное!) вовремя пополнять запасы чая и блять печенек.

Короче говоря: менеджер, мать его, должен заниматься всем, что напрямую не относится к написанию блять кода.

Подробная пошаговая инструкция для, мать их, менеджеров, выглядит следующим образом:

Понять, что вообще хочет заказчик, и рассказать об этом программистам
Сделать всё, чтобы программистам было блять комфортно писать код
Если тот код, что мы блять написали — это не совсем то, что хочет заказчик, то нужно снова сказать об этом программистам

Уверяю вас, эта новая методология изменит жизнь вашей команды. Я искренне верю в неё и считаю её единственно правильной. Почему? Да потому что в нашей индустрии есть только одно действительно важное занятие: писать код блять!

P.S. Теперь у этой методологии есть еще и манифест: http://пиши-код-блять.рф

6 причин, по которым вам не стоит писать функциональные спецификации

Thu, 03 Feb 2011 00:00:00 +0600

Небольшое эссе из книги «Getting Real», написанной сотрудниками компании 37signals. Оригинал можно прочитать здесь.

Спецификация — это абстрактный документ, в большинстве случаев не имеющий ничего общего с готовым программным продуктом. Почему? С удовольствием объясним:

1. Спецификация — это фикция

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

2. Задача спецификации — угодить всем

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

3. Спецификация — лишь иллюзия соглашения

Множество заверяющих подписей под несколькими страницами спецификации — это не соглашение. Ваша команда прочитала один и тот же текст, но скорее всего каждый понял его по-своему. И это обязательно всплывет в дальнейшей работе. «Подожди-ка, я вовсе не это имел в виду!», «Стоп, я понимал это совершенно по-другому!», «Нет-нет, всё именно так, и вы все под этим подписались». Вы прекрасно знаете, как это бывает.

4. Спецификация заставляет вас принимать самые важные решения тогда, когда вы меньше всего знаете о проекте

Меньше всего о проекте известно в самом начале работы над ним. Чем дольше длится проект, тем больше вы узнаете о нем. Так почему вы должны принимать самые важные решения, даже не приступив к работе?

5. Использование спецификаций приводит к обрастанию ненужной функциональностью

На момент написания спецификации вас ничего не ограничивает, кроме вашей фантазии. Нет ничего легче, чем дописать абзац текста или добавить еще один пункт в список. Вам ничего не стоит добавить в проект чью-то идею, просто чтобы сделать её автору приятное. Что мы имеем в итоге? Вашим проектом начинает руководить не здравый смысл, а абзацы текста и нумерованные списки. Именно так на свет и рождаются сайты с тридцатью горизонтальными табами в панели навигации.

6. Спецификация не позволяет вам развиваться, меняться и оценивать пройденный путь

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

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

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

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

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

Напоследок — небольшая цитата из Линуса Торвальдса:

«… Они практически бесполезны. Я не видел ни одного крупного проекта, в котором спецификации полностью соответствовали реальности и при этом действительно помогали разработчикам.

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

Настоящие программисты, где же вы?

Wed, 26 Jan 2011 12:47:00 +0600

Это перевод статьи из блога компании RethinkDB — калифорнийского стартапа, который занимается разработкой MySQL storage engine, оптимизированного под SSD-диски. Оригинал статьи можно прочитать здесь.

В последние месяцы RethinkDB довольно активно нанимает новых сотрудников, и за это время мы твердо убедились в том, что Джеф Этвуд (Jeff Atwood) в своей статье о FizzBuzz ни на йоту не отошел от истины.

Без лишнего хвастовства могу сказать, что мы предъявляем очень высокие требования к соискателям вакансий. И мы совершенно не намерены снижать эту планку. Более того, мы уверены, что чем больше слабых программистов мы отфильтруем, тем лучше и сильнее в итоге окажется наша команда. Некоторые, впрочем, отмечают, что под наши требования скоро будут подпадать только обладатели PhD в computer science со вторым дипломом по квантовой механике.

Конечно, всё это гнусные инсинуации. Наше основное правило — не нанимать людей, которые не умеют программировать.

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

Мы не просим решать сложные алгоритмические задачи. Мы не заставляем кандидатов ломать голову над задачками на сообразительность. Мы не даем зубодробительные задания на арифметику с указателями. Задача, которая не под силу подавляющему большинству наших кандидатов, выглядит так:

Напишите на С функцию, переставляющую в обратном порядке элементы в односвязном списке.

Всё. Точка.

Среди не решивших эту задачу были люди, у которых в резюме было указано «писал патчи к ядру Linux» и «участвовал в разработке компиляторов». Обладателей PhD в computer science, споткнувшихся на этой задаче, тоже набралось довольно много.

Разумеется, это не единственный вопрос, который мы задаем. Еще нам интересно узнать, какова максимальная сложность вставки N элементов в vector (или в ArrayList, или как там в вашем любимом языке называется динамический массив). Если вы не знаете — не страшно, давайте попробуем подумать вместе! Мы с удовольствием объясним вам внутреннюю реализацию вектора. Черт возьми, мы даже зачтем O(N*logN) как правильный ответ!

Как бы вы реализовали read-write lock? Не обязательно писать код, объясните хотя бы основную идею. О, вы знакомы с понятием starvation? Это очень здорово! Нет? Да что ж такое, расскажите нам хоть что-нибудь!

Мы спрашиваем о различиях между кооперативной и вытесняющей многозадачностью. Мы спрашиваем об условных переменных (conditional variables) в межпоточном взаимодействии. В 19 случаях из 20 в телефонной трубке только тишина.

Смысл этих вопросов очень прост: они позволяют выяснить, насколько хорошо кандидат усвоил самые основные вещи, которым его учили в университете. Кроме того, все эти вещи так или иначе встречаются в нашей работе. Наш опыт в проведении собеседований показывает, что если вы знаете разницу между потоками и сопрограммами (threads vs. coroutines), если вы можете перевернуть односвязный список и если вы хоть немного знаете об условных переменных, то ваш уровень уже гораздо выше, чем у большинства соискателей программистских вакансий.

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

Мой коллега, впервые прочитав статью о FizzBuzz, спросил: «Если они не могут написать FizzBuzz, что они вообще могут?». Повторюсь: первоначальное отсеивание выкидывает 19 из 20 кандидатов. Каждое телефонное собеседование занимает у меня около 45 минут. Если не считать нескольких часов на предварительный просмотр резюме, то беседы по телефону с 20 кандидатами в сумме занимают около 15 часов. И всё это — только затем, чтобы найти одного(!) человека с базовыми навыками программирования, и только после этого переходить к личному собеседованию с ним.

Где же вы, настоящие программисты?

FizzBuzz, или почему программисты не умеют программировать

Fri, 14 Jan 2011 11:42:00 +0600

Автор этой статьи — Джеф Этвуд (Jeff Atwood), один из основателей stackoverflow.com. Сама же статья, несмотря на довольно приличный возраст (она написана в 2007 году) до сих пор популярна, а введенный в ней термин «FizzBuzz question» стал общеупотребительным. Оригинал можно найти здесь.

Я весьма скептически отнесся к следующему наблюдению Реджинальда Брейтвайта (Reginald Braithwaite):

«Меня немного удручает тот факт, что 199 из 200 соискателей программистских вакансий не умеют программировать. Повторю: они не умеют писать код. Вообще.»

Реджинальд ссылается на статью человека, ответственного за прием новых сотрудников, которому приходится отфильтровывать множество программистов, не умеющих писать код:

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

Я решил разработать набор вопросов, которые позволили бы мне быстро идентифицировать таких «недопрограммистов». Вопросам такого рода я дал название «FizzBuzz questions», в честь игры, в которую играют британские школьники. Типичный FizzBuzz question выглядит следующим образом:

Напишите программу, которая выводит на экран числа от 1 до 100. При этом вместо чисел, кратных трем, программа должна выводить слово «Fizz», а вместо чисел, кратных пяти — слово «Buzz». Если число кратно и 3, и 5, то программа должна выводить слово «FizzBuzz»

Нормальный программист должен написать такую программу на бумажке за пару минут. Но вот что интересно: многие люди с профильным образованием вообще не могут справится с этой задачей. Были даже случаи, когда кандидаты, подававшие резюме на вакансию «Senior developer» тратили на эту программу больше 15 минут.»

Дэн Кигель (Dan Kegel) рассказывает о похожих впечатлениях при приеме на работу начинающих программистов:

«Неожиданно много соискателей (в том числе имеющих магистерские степени и PhD по информатике!) затрудняются ответить на простейшие вопросы. Я сам видел, как люди на собеседованиях не могут написать цикл, итерирующий от 1 до 10 или не знают, какое число в шестнадцатеричной системе идет после F. Что до менее очевидных примеров, то довольно много кандидатов не знают, как применить рекурсию для решения какой-либо практической задачи. Согласитесь, всё это совершенно базовые вещи, и если человек затрудняется с ответом на подобные вопросы, значит у него попросту нет опыта программирования.

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

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

Известно, что между состояниями «я учусь программировать» и «я умею программировать» лежит огромная пропасть. Я полагал, что у каждого, кто хоть раз подавал резюме на вакансию программиста, эта пропасть уже позади. Но практика показывает, что это совсем не так. Более того, я прихожу к выводу, что предварительное отсеивание кандидатов вопросами типа FizzBuzz просто необходимо, иначе мы будем бездарно тратить кучу времени на собеседования с программистами, которые таковыми не являются.

Для тех из вас, кто считает задачу о FizzBuzz чересчур простой (она, впрочем, намеренно тривиальна), я приведу комментарий из поста о собеседованиях, на который мы ссылались в начале статьи:

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

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

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