Category: фантастика

Category was added automatically. Read all entries about "фантастика".

усы2

Фронтендеры не на маках

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

miketansky: Фронтендеры не на маках с чувствами вкуса и хорошего дизайна — это редчайшее исключение. Хотите резко повысить вероятность найма хорошего фронтендера? Жестко и безжалостно дискриминируйте по этому признаку.

А вот реплаи:

flashader: Ни одна статусная (а тем более — зашкварная) вещь не заменит исполнителю мозг и умение думать.

Как будто кто-то с этим спорил. Утверждение было в обратную сторону — если умение уже есть, есть тенденция к переходу на маки.

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

Опять развернули утверждение. Речь же не о том, что дебилы (что бы это ни значило) тоже могут купить мак. Речь о том, что Хорошие Фронтендеры (что бы это ни значило) переползают рано или поздно на мак.

orsinium: Я воспринял этот твит как «Для того, чтобы делать хороший UI, нужно пользоваться хорошим UI». И отметил, что UI в маке хорош, а UX — нет. А навыки в UX я считаю не менее важными для фронтендера и дизайнера.

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

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

На эту тему у меня есть шикарный же пример. Сидел я как-то на докладе про какой-то кросс-мобильный фреймворк, из серии write once — run anywhere, и на одном из слайдов, продающих его, был график выручки компаний от приложения по количеству платформ. Грубо, компании, выпускающие приложение только на одной платформе, там, айос или андроид, зарабатывают условно $1000 в мес на нем. Компании, выпускающие на двух, зарабатывают допустим $2000. На три платформы (+windows phone) уже $5000. Ну и самый пик там что-то типа те, кто выпустили приложение аж на 11 платформ (хз, что это за платформы), гребут уже там, например, $500 000 — непропорционально больше, короче. Ну и показывалось это под таким соусом, типа, за этим вам и нужен наш фреймворк — выпустите под больше платформ, заработаете больше денег. Для презентации кросс-платформенного фреймворка очень удобный аргумент. На самом деле всё объясняется гораздо проще, конечно — если у вас есть приложение, зарабатывающее $500 000, у вас найдутся деньги, чтобы портировать его на 11 платформ. А если приложение херовое, то запускай хоть на 11 платформах, денег не соберешь. Вроде бы банальная мысль. График можно было прочитать и так, и так, а понять его правильно можно только через понимание механики, которая его формирует.

усы2

Не Vim-ом единым

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

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

Итак.

Для начала давайте оспорим тезис, что набор текста — редкая операция. По моим оценкам, набор и трансформации делятся скорее как 50%/50%, т.е. набор далеко не редкая операция. Грубо, каждому переносу соответствует редактирование (т.к. код редко когда переносим без изменений), а каждому удалению — вставка (статистически, по GitHub, обычно графики вставок/удалений очень симметричные). Т.е. бегать между режимами приходится достаточно часто, чтобы записать необходимость их переключения в некую дополнительную ненулевую «нагрузку».

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

Так вот, не хочу никого расстраивать, но система команд получилась такой не из-за какого-то великого инсайта, а просто потому, что у автора был тормозной модем и он «хотел печатать быстрее, чем обновлялся экран». Ну, представили ситуацию, да? Набрал «выделить текст, от кавычки до кавычки, заменить, ввести „абырвалг“, выйти», послал голубиной почтой и пошел пить кофе. Более того, даже в момент создания подход Vim не имел смысла для локального редактирования, где задержки нет. 

В современном мире у нас давно есть гораздо более продуктивные и удобные инструменты: визуальное выделение, непосредственное манипулирование и мгновенная обратная связь. Это значит, что ты видишь в реальном времени, что и где ты выделил и что сейчас произойдет. Кроме того, выделение можно подкрутить, опять же, в реальном времени. В примере из статьи, «выделить всё вплоть до кавычки», а потом подвигать курсор плюс/минус один-два символа в зависимости от нужды. В мире Vim выделить до кавычки и выделить до кавычки минус один символ — две разных задачи, в современном мире — одна, решающаяся одним инструментом — двиганием курсора. Не происходит операционного перегруза мозга и комбинаторного взрыва (какой инструмент выбрать для вот этого частного случая?).

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

Еще раз. Vim намеренно не использует однозначно удобные и полезные методы визуальной коммуникации только потому, что их было нереально использовать через очень медленный модем на 300 бод. Это единственная причина. Количество причин, почему современные люди должны так же себя ограничивать — ноль. Такую цену имеет смысл платить, если альтернатива — потратить полминуты на непосредственное выделение текста (помните тормозной модем?), но это давно уже не проблема. Это же практически шахматы по переписке. Зачем себя мучать?

It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.

9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore.

The people doing Emacs were sitting in labs at MIT with what were essentially fibre-channel links to the host, in contemporary terms. They were working on a PDP-10, which was a huge machine by comparison, with infinitely fast screens.

So they could have funny commands with the screen shimmering and all that, and meanwhile, I'm sitting at home in sort of World War II surplus housing at Berkeley with a modem and a terminal that can just barely get the cursor off the bottom line.

It was a world that is now extinct. People don't know that vi was written for a world that doesn't exist anymore.

Но зато в Vim удобные «шорткаты» (команды, окей) и их много! Да, но в современных редакторах их не то чтобы сильно меньше. Даже стандартные системные (!) справляются с перемещением текста весьма неплохо (Cmd+←→ == начало/конец строки, Alt+←→ == прыгать по слову, Cmd+↑↓ начало/конец документа, Alt+↑↓ вверх/вниз на страницу). Окей, на Винде чуть похуже.

Плюс команды в Vim всё-таки немного более избыточны, чем хотелось бы. Проще жить, когда один инструмент решает две-три задачи (даже так: работает в двух-трех разных ситуациях), чем когда у тебя на каждый специальный случай отдельная кнопка. Вот например специальная команда для вставки в конец строки («a»), это что вообще? В обычных редакторах туда можно просто поставить курсор, а тут отдельная «команда». Или «r» (заменить одну букву и выйти), тогда как в обычном мире просто Backspace (кнопка «забой» :), которая и удаляет, и заменяет, если на месте удаленного набрать новую букву.

Ну и самая большая цена, которую вы платите сегодня, пожалуй, это то что подход Vim не совместим ни с чем вообще. Vim работает только в Vim, поэтому во всех остальных местах вы будете постоянно чертыхаться, пытаясь нажать «i», «Esc» и ходить по тексту через «hjkl». Везде: в браузере, в календаре, документах, эверноте, чатах, спотлайте, везде ваши так долго тренировавшиеся привычки идут лесом.

Здесь еще я мог бы пожаловаться на архаичность и несовместимость Vim с современным миром. У него, например, два буфера обмена ¯\_(ツ)_/¯ и оба внутренние. Ни один из них не попадет в ваш системный, т.е. скопировать текст внутри Vim и вставить его еще куда-то не получится. Он не умеет различать вставку текста и набор, поэтому если вы скопировали какой-то кусок кода (скажем, со StackOverflow) и вставляете, он его будет набирать посимвольно, что медленно, смешно и хреначит все отступы к чертям. Да, только из-за этого есть специальный режим «paste mode» и да, его-то как раз легко забыть включить/выключить. Часть этих «особенностей» пофикшена в графических клонах, скорее всего, но все равно, знакомство с ними было забавным и это тот случай, когда «через свежую покраску все равно проглядывали признаки старого, очень старого материала».

Ну и немного про достижения Vim. Хочу еще раз заметить, что Vim такой, какой есть, потому что так получилось. За ним не стояло какого-то гранд дизайна или проверенных научных моделей, система команд не то чтобы какая-то особенно логичная или удобная. Он ни подо что не оптимизировался, кроме модема и клавиатуры автора, у которой Esc был на месте Tab, а физических стрелок не было, зато уже были картинки стрелок на «hjkl»). Да-да, именно поэтому всем поголовно вимерам приходится маппить Esc на Caps Lock.

Зацените кнопку «рубля», кстати

Так вот. Первое великое (и случайное) достижение: стрелки на home row. Действительно, тянуть руку в правый нижний угол очень далеко, а перемещение по тексту очень частая операция. Процентов 50% успеха Vim я отдаю тому, что люди просто осознают всю идиотскость расположения стрелок в правом нижнем углу на клавиатурах, а Vim — наиболее доступный способ эту проблему хотя бы частично решить.

Но это откровение никак особо Vim не принадлежит и в идеале неплохо бы сделать его отчуждаемым. Стрелки не становятся вдруг удобнее, когда ты выходишь из Vim и переходишь, скажем, в браузер. Я решаю это маппингом Caps Lock + IJKL (да, не HJKL) на стрелки. Очень удобно и главное: работает везде.

Вторые 50% успеха я отдаю высокому порогу входа. Тут надо объяснить. В устройстве человека есть такой баг (ну или фича): люди не начинают лучше владеть инструментами/навыками/привычками со временем просто так, сами по себе. После того, как они научились делать задачу как-то (неважно, как, лишь бы получался результат), они будут продолжать делать её именно так. Если не прикладывать осознанных усилий, через год пользования Idea, например, ты будешь пользоваться ей так же, как через первую неделю. Горячие кнопки сами себя не разучат, удобные фичи не найдутся. Нужно тренировать себя, читать обучающие материалы, смотреть, как пользуются другие.

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

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

Спорим, для условного «Ворда» вы никогда бы даже не подумали гуглить такую табличку?

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

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

усы2

Принципиальный недостаток Git CLI

Есть простой способ использовать Git: работаем только в ветке, мержим только в мастер. Если все идет хорошо, то выстраивается простой и понятный ритуал: branch, commit, checkout, merge, push, повторить. GitFlow называется, да?

Для такого сценария Git CLI достаточно. Для всего остального — недостаточно. Странно, что люди до GitFlow вообще пытались как-то по-другому с Git работать через CLI. Ну невозможно это.

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

В таких случаях важно понимать, что происходит. Я, например, читаю историю ветки и пытаюсь воссоздать ход мыслей и направление изменений автора, с которым у меня возник конфликт. Чтобы решить конфликт правильно и осмысленно, мне надо пересмотреть всю историю ветки, прочитать диффы, посмотреть что вообще происходило и в какой последовательности. Просто смотреть на бесконтекстный 3-way diff — не вариант.

Простой и красивый вывод легкозапоминающейся команды git log --pretty=format:"%h - %an, %ar : %s" --graph:

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

К сожалению, CLI в этом никак не помогает. Ты находишься в полной темноте. Единственное, что понятно: что-то сломалось. Сообщение совсем неадекватное, или вообще нет сообщения, просто «конфликт» и предлагается выбрать между двумя непонятно откуда взявшимися альтернативами. Я много раз наблюдал, как люди просто впадали в панику и ступор и не понимали, что делать дальше. У таких случаев всегда есть объяснение, и оно обычно совсем несложное, объяснимое, логичное даже, но только если разобраться. Не ситуация сложная, сложно её понять, сидя в CLI. Черт, во всех компаниях, где я работал, я очень быстро становился негласным экспертом по таким вот нестандартным разбирательствам ¯\_(ツ)_/¯

Итак, Git CLI работает только когда четко понимаешь, что происходит. Отсюда нужда в GitFlow: он сильно ограничивает пространство возможных ситуаций, поэтому когда shit hits the fan, у тебя ограниченное количество гипотез о происходящем. Паники меньше, шансов угадать и принять правильное решение больше.

Типичный репозиторий, разрабатываемый по GitFlow

Вообще-то все git-овые best practices оттуда же: не юзать rebase, бояться force push, всегда создавать merge commit, не переписывать историю. Если их нарушать, мир не рухнет, ничего страшного не случится. Но — проблема — коллеги не поймут, что происходит. Если бы они в таких ситуациях видели, что происходит, то разобраться с ними — раз плюнуть. Проблема только в том, чтобы их идентифицировать.

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

Макклейн мёржит крупными мазками

Проблемы:

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

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

Поэтому я так скептически отношусь Git CLI: он устроен так, что пытается «уберечь» вас от сложных ситуаций прямо сейчас, но каждым своим действием усложняет ситуацию на потом. Скажем, git pull по-умолчанию будет мержить, если обнаружит, что ваша ветка разошлась с удаленной. Это «прячет» от вас сложный факт того, что ветки могут расходиться, но мир устроен именно так — они могут и будут расходиться, это нормально. Абстракция, которая пытается это скрыть — дырявая. Зато упрощает ваше существование, потому что у вас якобы всегда будет одна «главная» версия.

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

Фрагмент истории LightTable. Это ещё по-божески

Как тогда жить?

  • Визуальное представление графа коммитов. Многие GUI клиенты неплохо справляются
  • Fetch вместо Pull
  • Не бояться amend, rebase и вообще двигать историю

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

Бывает, люди путают git log с личным дневником и записывают свои мысли, настроения, погоду на улице

История должна быть осмысленной, атомарной (по еденицам решаемых проблем), аккуратной. Это всё окупится сто раз, когда с репозиторием придется по-настоящему работать. Git, его история — это не просто safety net, это еще один инструмент, еще одна форма существования кода, часть продукта. Вы же следите за кодом? Вот и за историей надо следить.

А практика непереписывания история имеет смысл только если у вас нет инструмента понять, что происходит вокруг, и вам лень разбираться. Сама по себе она безобидна и в целом работает на упрощение истории.

усы2

Ненаучная логика

Илья Бирман в своем блоге разоблачает людей, не умеющих в логику. Собственно, весь пост:

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

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

Решили? Уверены в решении? Смешно?

В самом факте ошибки ничего страшного нет. Он показывает лишь поспешность, но не степень владения логическим аппаратом. Ошибаются все.

Так вот, первая задача — про способность найти трюк, а не про способность рассуждать логически. Проверить просто: достаточно объяснить решение тому, кто дал неправильный ответ. Когда объясняешь трюк, никто с ответом спорить не будет. Т.е. с логикой всё в порядке, ну а то что не все видят трюк — на то он и трюк.

Сам факт спешки с ответом тоже ни о чем специальном не говорит. Это устройство человека (любого!), экономить мозговую энергию. Похожий пример из книги «Thinking fast and slow»:

Бейсбольная бита и мяч вместе стоят $1.10. Известно, что бита ровно на 1 доллар дороже мяча. Сколько стоит мяч?

Первый пришедший на ум ответ — $0.10 — неверный — говорит только о том, что ум любит срезать углы и экономить на полноценных вычислениях там, где встречается знакомый паттерн. Еще раз: получить $0.10 в качестве самой первой гипотезы, интуитивно — нормально, естественно. Так устроен мозг. Любой мозг, не мозг каких-то специальных глупых людей. Это так же естественно, как иметь две ноги и два глаза. Ошибочность ответа говорит только о том, что интуицию можно обмануть, подложив ей специально сформированный паттерн, но не говорит ничего о том, что человек тупой или еще что-то. Мозг ошибается у всех примерно одинаково.

Насчет второй задачи есть несколько интересных моментов. Напоминаю:

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

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

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

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

усы2

30 советов 30-летним от тех, кому за 40

  1. Определись. 30 лет — возраст, когда пора сказать себе: определись!
  2. Не дай провести себя на мякине. Вообще по возможности обходи стороной мякину.
  3. Старайся уделять больше внимания. Внимание — твой самый ценный ресурс. Уделяй его.
  4. Составь план. Хороший план очень сложно выполнить, но составить — легко.
  5. Ходи на работу. Многие люди потеряли свою работу после того, как перестали ходить на нее.
  6. Спорт — это важно. Старайся чаще думать о нем.
  7. Сфокусируйся. Расфокусируйся. Вообще, потренируй глаза. Ты можешь добиться в жизни большего, если потренируешь глаза.
  8. Старайся рисковать, но в меру. Будь безрассудным, но рассудительным. Ты еще не молод, но уже не стар.
  9. Привыкай к тому, что многие привычки привычно входят в привычку.
  10. Помни, что то, что тебе сейчас кажется важным, может оказаться на самом деле важным, и может не оказаться. Попробуй угадывать, хоть это и бесполезно.
  11. Старайся жить так, будто каждый день твоей жизни — 10957-ой.
  12. Не откладывай развитие. Если кто-то предложит тебе заняться развитием — не отказывай ему сразу. Подумай.
  13. По возможности не разговаривай на улице с незнакомцами.
  14. Используй ноги при ходьбе. Постоянно дыши. Ешь ртом. Это простые вещи, но они могут кардинально изменить твою жизнь.
  15. Найди время и научись пользоваться интернетом. В 21-м веке без интернета никуда, даже если тебе уже 30 лет. Особенно если тебе 30 лет. На 30 лет у многих приходится пик использования интернета. Будет обидно пропустить его.
  16. С возрастом все труднее вспоминать прошлое. Так что расслабься, больше фантазируй.
  17. Старайся меньше полагаться на свою память. Не надейся запомнить вещи, лучше запиши их на бумажке и запомни, куда положил бумажку.
  18. Начни планировать бороду. К 80-ти годам пышная седая борода не вырастет сама, если ты не начнешь закладывать фундамент уже сейчас. Многие 40-летние жалеют о том, что не начали думать об этом в 30 лет.
  19. Помогай людям стать лучше. Совершённое добро всегда возвращается с лихвой. Говори «я преподал вам урок» вместо «извините».
  20. Научись ценить свое время. Научись ценить время близких тебе людей. Чаще напоминай друзьям, сколько времени ты потратил на них впустую.
  21. Почаще спрашивай себя. Если не услышишь ответа — задумайся.
  22. Купи барабан. В 30 лет это звучит глупо, но поверь мне, через 10 лет ты скажешь мне спасибо за этот совет. К сельдерею тоже присмотрись.
  23. Жизнь это ручей. Чем старше ты становишься, тем яснее видишь аналогию. Ее можно перейти на коне, в ней можно помыть ноги или увидеть свое отражение. После дождя в ней лучше клюет, а посторонний мужчина может в нее помочиться.
  24. Избегай идиотских советов. Тебе не нужна чужая мудрость, чтобы заниматься своими глупостями.
  25. Больше внимания уделяй здоровью. Ешь здоровую еду, пей здоровую воду, носи здоровую одежду, общайся со здоровыми людьми.
  26. Перед началом любого дела подумай, будешь ли ты считать его таким же важным через 10 лет? Если да, то можешь не торопиться.
  27. Оптимизируй свое время. Ложись пораньше, вставай попозже. Ты успеешь сделать больше, если будешь спешить.
  28. Обязательно выдели 30 минут в день, чтобы смотреть на ковер. Если ковра нет, стена тоже подойдет. В это время тебя не должны беспокоить.
  29. Главное в жизни — это баланс. Обязательно научись ходить по канату, стоять на руках и сидеть на табурете с одной ножкой.
  30. Не трать время на споры с дураками. Ты можешь узнать неприятную правду о себе.

усы2

Get that job at XXX

Тут Саша Алексеев рассуждает про найм, и мне тоже захотелось поделиться опытом.

Во второй половине 2013 года мы провели успешную кампанию по расширению штата Эхо. Успешной она оказалась благодаря следующим принципам:

  1. Убрать кота в мешке
  2. Зацепить
  3. Сократить дистанцию
  4. Отфильтровать

«Кот в мешке» — это любая компания, повесившая объявление на hh.ru/moikrug/куда-там-еще. С точки зрения кандидата совершенно непонятно, куда он попадет. Что там за люди (есть ли там люди?), чем они занимаются, от чего у них горят глаза, насколько всё плохо/хорошо/тоскливо. Эта неизвестность очень мешает. У всех написано «интересная работа, молодой коллектив, печеньки» — это ни о чем, стоп-слова на самом деле. Сайты айтишных контор сами знаете, как выглядят.

В Эхо было несколько сотрудников, пишуших в ЖЖ на рабочие темы, у нас был корпоративный блог, из которого кое-что можно было понять, мы выступали на конференциях в Ульяновске и в Новосибирске, какой-никакой гитхаб с опенсорсом. Благодаря усилиям Льва Валкина и ульяновской команды Эхо была очень заметной в ИТ-тусовке Ульяновска и среди студентов. Мы звали к себе на хакатоны, лекции и скайп-посиделки на около-ФП темы.

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

«Зацепить» это примерно про то же самое — кандидат (потенциальный! Он пока даже не думает о смене работы) должен представлять, а что же такого интересного он будет у вас делать. О том, что надо будет работать, догадываются все — а вот чем именно будет эта работа радовать, надо рассказать обязательно. Вместо «у нас на кухне есть кулер» пишите лучше, что у вас есть: горячие темы (облака, high load, ML), свобода в выборе инструментов, 20% side project, etc. У нас, например, даже тестовое задание «цепляло», его хотелось сделать.

Тут еще важно не забыть «сократить дистанцию» — приложить все усилия, чтобы инженеры разговаривали с инженерами. Это намного понятнее и ближе. Тексты вакансии/тествое задание/все коммуникации — это всё должен осуществлять тимлид. Нельзя перекладывать это на HR или составлять отписки, нет, коротких путей тут быть не может. Важно, чтобы человек чувствовал, что он разговаривает не со стенкой, не с черной дырой, не с официальной «компанией», а с живым инженером, таким же, как и он сам. Идеально, пожалуй, если под вакансией будет тупо стоять прямой емейл тимлида (мы так сделать не догадались).

По идее, на этом этапе к вам уже хочется. Дело-то сделано. Уже где-то есть N людей, которые хотят к вам и которых хотите вы. Осталось подписать бумаги.

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

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

Устное собеседование тоже было, но там ничего необычного.

В итоге: большой поток кандидатов по сравнению с предыдущим «пассивным» наймом и отсутствие ложно-позитивных срабатываний (все попавшие в Эхо оправдали ожидания на 100-110%). Благодаря этой схеме был почти полностью сформирован Новосибирский офис и серьезно расширен Ульяновский.

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

Закроем тему: Tabs vs spaces

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

    fun ({submit, …}) -> …;
        ({count, …}) -> …;

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

То же самое касается пустых строк в конце файла. Они волнуют только C/C++ девелоперов в конце h-файлов, остальные перестаньте поддаваться этому карго-культу.

И, конечно, UTF-8.

Эти вещи не надо думать или обсуждать. Нужно просто так делать. Вот и всё. Этим я закрываю многовековую дискуссию.

Лирический постскриптум для любопытных

В клетку сажают 10 обезъян. В центре клетки подвешен банан. При попытке подобраться к банану обезъян (всех) поливают холодной водой из шланга. Через некоторое время они перестают пытаться. Половину обезъян убирают и сажают пять новых. При попытке новичков подобраться к банану старые их бьют, потому что не хотят промокнуть. Когда новенькие оставляют попытки завладеть бананом, пятерых «старых» обезъян убирают и сажают пять совсем новых. Теперь никто в клетке не видел шланга или воды. Однако, когда новички пытаются завладеть бананом, их избивают. Потому что здесь так принято.

Git любит ругаться, потому что git делался для ядра линукса, а в ядре линукса пишут на C и патчи до сих пор пересылают в теле письма. Почтовые программы, которые это обслуживают, съедают висячие пробелы, и у них потом то ли патчи не применяются, то ли хэши не сходятся у коммитов. Интересно, насколько такая очень конкретная деталь определила и до сих пор определяет форму такого казалось бы универсального инструмента, как git. Еще интересно, сколько людей этому верят, считают это «хорошим стилем», энфорсят, делают настройки в редакторах, плагины, тулзы, создают из этого проблемы и решают их, но никогда не пытаются докопаться до первопричины.

усы2

(no subject)

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

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

Здесь одна из кнопок удаляет скрытый комментарий как спам, а другая раскрывает его публике. Я до сих пор не запомнил (livejournal.com):




Здесь на эту тему уже три(!) кнопки, плюс иконка freeze для функции, которая сама по себе непонятно что делает, и иконка понять не помогает (там же):




Эти иконки Newsfeed нужны раз в жизни, т.е. на запоминание они не работают. Угадаете, в чем разница? (bitbucket.org):




Старый gmail все еще в сто раз понятнее нового: у переноса в архив, спама и перемещения в папку нет устоявшихся метафор (gmail.com):






Аналогичная ситуация (Safari):




Здесь получилось нарисовать прямо противоположное задумке: отсутствие перечисленных фич (chicagoboss.org):




Отобранный у пользователя Интернет (Firefox):




Разумеется, нарисовано должно быть то, что имеется в виду — мозг человека с трудом воспринимает абстрактные связи. Классика (habrahabr.ru):




Из-за поиска формы пострадал смысл: сначала возврат, потом вылет (ozon.travel):




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




Вместо кнопки «вернуться назад», как у всех, кнопка «развернуться на месте» (Android):




Отдельного круга ада заслуживают люди, рисующие абстрактные, не имеющие отношения в объекту иконки (источник неизвестен):

Пять изобретений, которые изменят мир будущего

1. Телепортация
Перемещение в любую точку земного шара без затрат времени и денег. Туристические путешествия «на выходных», экскурсии в самые труднодуступные места земного шара во время обеденного перерыва. Купание в Черном море перед сном.

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

3. Машина времени
Personal favorite. Любой самый спорный исторический вопрос можно разрешить. Все наслоения вранья и домыслов снять. Утерянные навсегда материалы получить. Как жили люди посмотреть. Умершим зубрам задать вопрос.

4. Очки, показывающие реальную цену вместо ее. ..9,99 эквивалента
Надеваешь очки и видишь, что товар, который стоит 14 999,99, на самом деле обойдется тебе не в 14 ну там с чем-то тысяч, а в 15.

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