Wesha

Томас резко вывернул руль влево, все восемь колёс его «крабика» протестующе заскрипели, впиваясь в грунт.

— Даю тебе пять минут, — раздалось в наушниках. Голос Джулии с трудом пробивался через помехи — он отъехал от станции чересчур далеко.

— Мне достаточно трёх.

— Уверен?..

— Ты издеваешься? — завопил он в микрофон.

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

Дж. Пол Гибсон начал преподавать программирование тинейджерам от досады. Преподаватель информатики в Государственном университете Ирландии, к 1998 году он был по горло сыт невежеством своих студентов. «Я наблюдал 18- и 19-летних, с трудом усваивающих элементарные концепции программирования, которые я освоил в 12 лет, — вспоминает Гибсон, самостоятельно научившийся программировать на Sinclair ZX81. — Я осознал, что до сих пор не видел программирования в школьной программе, и подумал, что, может быть, одна из наших проблем состоит в том, что мы подходим к нему слишком поздно.» Когда молва о курсе Гибсона распространилась, начальные школы в окрестностях Дублина тоже заинтересовались его услугами.

К началу 2000-х Гибсон использовал задачки из области разработки игр для обучения восьми- и девятилетних детей основам Java. Его успех в этой возрастной группе вызвал к жизни вопрос: а в каком, собственно, возрасте чересчур рано программировать?

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

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

Недавно я прочёл запись в блоге одного парня, который жаловался, что на интервью его попросили написать функцию, которая должна скопировать файл. Нет, я понимаю, как можно взъесться на такое задание, но если бы в подобной ситуации оказался я… уж я бы оторвался по полной:

---

Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Ну… создать новый файл, содержимое которого является копией содержимого исходного файла.

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

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Автор имеет в виду игру слов: «when you assume, you make an ass of you and me» — «когда вы (что-то) подразумеваете, вы делаете /./удака из себя и из меня»]

И обнаружил кое-что занимательное: почти все регулярные выражения, представлены в интернете как «проверяющие корректность email-адреса», излишне строги.

(начало статьи здесь)

Управление рисками при инвестировании в программистские таланты

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

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

От переводчика

Почитывая несколько лет назад журнал "Форбс", я наткнулся на статью, которую нашёл крайне интересной. Ну, знаете как бывает — читаешь, читаешь, и на каждом абзаце воскликаешь: «О! Це ж про меня!». Не мог поверить, что я один такой, и никто не сподобится уж если не перевести, то хотя бы сослаться на неё в русскоязычной прессе. Однако за четыре года этого так и не произошло. Ну что ж, «хочешь сделать что-то правильно — сделай это сам», посему предоставляю вниманию почтенной публики первую половину статьи. (Стараюсь переводить художественно, поэтому работа двигается небыстро; размер оригинала — больше 30 килобайт, и, «земную жизнь пройдя до половины», я понял, что держаться нету больше сил.)

P.S. Так и не смог разобраться, как поставить в заголовке тег «перевод».

Восход разработчикономики

^{Статья Венкатеша Рао опубликована в декабре 2011 года в журнале «Форбс».}

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

В последнее время я размышлял над этой идейкой в контексте человеческого богатства. Если только вы не являетесь профессиональным инвестором (а даже если и являетесь), в настоящее время находить места для хранения избытка капитала, где он бы был в безопасности и не амортизировался слишком быстро (не говоря уже о принесении дохода) становится всё сложнее и сложнее. Фондовый рынок всё чаще навевает мысли о кровавом пиршестве “медведей”. Волатильность и неожиданные кратковременные ралли делают игру с короткими позициями небезопасной. Даже хранение активов в долларах, похоже, таит свои опасности — благодаря угрозе девальвации и всяким новомодным словечкам вроде «количественного смягчения», которые мы, среднестатистические инвесторы, слышим впервые. Евро сейчас тоже не смотрится как радужная альтернатива. Решение инвестировать в золото — и вообще в любое сырьё — кажется, требует несколько апокалиптического взгляда на мир, и размышлений о том, как вы планируете получить доступ к собственно предмету владения в случае, если всё и правда полетит в тартарары (хочется отметить, что в настоящий момент не могу назвать такой взгляд на мир так уж неоправданным).

Но есть одна тихая гавань — если вы знаете, как в неё вложиться: разработчики ПО.

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