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

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

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

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

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

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

Два шага назад и один вперед.

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

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

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

#китайскаякомната

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

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

#китайскаякомната

Собеседование на работу очень сильно похоже на первое свидание. И как на любом свидании, развиваться оно может по трём сценариям.

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

2. Когда кандидатов много и работодатель устраивает конкурс, вроде «а можно всех посмотреть» или «всем спасибо, у кого рост ниже 185 и грудь меньше третьего».

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

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

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

#экстрарекрутинг

Недавно личным сообщением мне написала подписчица Валерия, которая работает над проведением чемпионатов по программированию от мейлру (https://yangx.top/mrgchamps). У них много всяких соревнований проходит с призами и фондами. Предлагает новый вид развлечений в «Экстраполяции» — чемпионаты, задачки и всякие алгоритмические штуки. Я когда-то пытался что-то подобное сделать, но нужно что-то круче просто алгоритмических задачек, да?

Как вам идея Валерии? Устроим состязания какие-нибудь?

Внезапно Дмитрий напомнил о такой животрепещущей теме, как «микросервисная архитектура» шикарной цитатой из рабочей переписки:

«Ну ликвидируем мы свой монолит. Ликвидируем его месте с остатками понимания, ибо большие рефакторинги стоят долго и дорого. И что дальше? Не нравится слово "Монолит", так будет у нас какая-нибудь другая "микросервисная архиектура". Какая разница? Мы-то останемся все теми же самыми...»

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

В общем, в эфире #перечитываяэкстраполяцию

——

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

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

Слепоту к изменениям тоже можно заметить гораздо проще, есть довольно много роликов в интернете на эту тему. Даже BBC снял передачу, посвященную этому феномену. В обычных условиях изменение наблюдаемой картины мгновенно обращает на себя внимание. Однако мы можем не замечать изменения, если они совпадают с коротким прерыванием наблюдаемой картинки. Это может быть кратковременное моргание экрана, монтажный стык видео или короткая помеха. В экспериментах по слепоте к изменениям обнаружилось, что почти 70% испытуемых не замечали подмены главного действующего лица, а изменения менее существенных деталей оставались проигнорированными почти в 100% случаев.

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

Жили-были в одном городишке два ассенизатора — синьор и джун. Канализации у них там не было, а просто ямы с этим самым. И они это самое вычерпывали ведром и заливали в свою бочку, причем синьор, как более опытный специалист, спускался в яму, а джун сверху подавал ему ведро. И вот однажды джун это ведро не удержал и обрушил обратно на синьора. Ну, тот утерся, посмотрел на него снизу вверх и сказал ему с горечью: «Чучело ты, — говорит, — огородное, тундра! Никакого толка в тебе не видно. Так всю жизнь наверху и проторчишь».

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

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

Я вот могу затолкать себе в голову большой объём легаси-кода, выполнить его в уме, просочетать в разных вариантах, понять, что происходит и найти, что и как надо сделать, чтобы исправить баг или добавить фичу. А, значит, с неизбежностью, я и буду это делать. Потому что такая работа на рынке есть, её умеют делать не все, и за неё платят чуть больше, чем за клепание контроллеров и моделек с нуля, рассуждая о модульной архитектуре, SOLID, KISS, DCI и таком прочем. Потому что второе может больше народа.

Причём, легаси-код в любом проекте появляется за полгода, так что, от него не спасут даже серьёзные попытки не браться за легаси, а плясать по "generate new projectname" стартапчикам. Легаси-код неизбежен, как всадники апокалипсиса — проект или обрастает легаси-кодом, или аннигилируется заказчиком. В этом месте можете возражать и доказывать, что это не так, и что я не очень, надо просто хорошо писать и всё такое. Вспоминается старый анекдот про «и вы тоже рассказывайте».

#dimoneverything

Ну, ладно, судя по отзывам, анекдот не такой уж и известный, хотя и бородатый. Пересказываю:

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

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

А вывод, увы, в том, что ну и что. Есть много приятных вещей в жизни — хорошие книги, фильмы и компьютерные игры, шашлыки, девушки и путешествия. То, что мы на работе игногда умудряемся тоже получить пару дней в месяц удовольствие от красивого решения сложной проблемы — уже благословение.
Конечно же, существуют разработчики, которые свою компенентность действительно смогли конвертировать в интересную работу и у них rocket science каждый день. Но их мало, сильно меньше, чем сеньоров и чем архитекторов тоже. Так что, крутейте, ныряйте, а то так всю жизнь наверху и проторчите.

#dimoneverything

Минутка ложной слепоты и код-ревью.

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

Есть два разных подхода к код-ревью. Не, есть ещё больше, но я про нормальные, а не превращающие его в бюрократию с профанацией.

Первый — это открыть пулл-реквест и промотать его сверху донизу (или в каком-то другом разумном порядке, от тестов к коду или так, как рекомендует написавший этот код в текстовом описании пулл-реквеста), тщательно его прочитав, что-то выполнив в уме, прочитав тесты и убедившись, что они проверяют код. Потом взять в левую руку Фаулера, в правую Макконнела и указать на возможные косяки, плохие имена, выделите класс, заинлайните метод, тут же N+1 у вас, хватит мокать тесты, это не REST, вы забыли authorize, не надо писать собственный map, он в стандартной библиотеке уже есть, и всякое такое. Или сказать «молодец». В общем, побыть сильно продвинутым Code Climate.

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

Мы с моим коллегой расходится в мнениях по этому вопросу и применяем разные подходы.

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

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

#dimoneverything

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

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

Но дело в том, что как только какой-нибудь инструмент становится Серебряной Пулей, к нему перестают относиться, как к серебряной пуле и считают стандартом де-факто. Этот инструмент становится чем-то таким естественным и общепринятым, что разработчики даже не задумываются о выборе между этим и другими Медными и Бронзовыми аналогами. Никто не рассказывает о преимуществах Пули перед другими инструментами, никто не спорит о неуниверсальности, и никто не обзывает Пулю и не хвалит Штык.

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

#перечитываяэкстраполяцию

Мнения по поводу целей пулл реквестов разделились, значит подбросим ещё дровишек в огонь.

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

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

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

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

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

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

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

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

Сегодня пост по-субботнему, ссылка, причём на перевод. Очень хорошо написано и не менее хорошо переведено.

https://habr.com/ru/post/450508/

Совершенно очевидно, что за работу программиста нужно платить. Уже менее очевидно, но все ещё достаточно понятно сколько конкретно нужно платить тому или иному программисту. И совершенно неочевидно и совсем запутанно с тем, что же ещё влияет на желание работать и продуктивность разработчика.

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

Главными же побудителями хорошего настроения на работе является то, что составляет подавляющую часть рабочего процесса.

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

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

«Я все, конечно, понимаю, но вы представляете себе праздник, организованный разработчиком? Ящик пива, мешок чипсов и турнир по третьему квейку — это максимум», пишет нам читатель «Экстраполяции» с крайне неочевидной отсылкой. Он, безусловно, прав. Программисты не умеют организовывать праздники, они умеют программировать.

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

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

Из отзывов к посту об пулл реквестах:

«А у нас борясь с херовыми кодревью решили, что кодревью станет лучше, если потребовать по два аппрува на пулл-реквест, вместо одного»

В телеграме работа с публичными каналами кардинально отличается от привычных площадок. В ютубе, например, все блоггеры, как один, начали просить нажимать на колокольчик, чтобы мгновенно узнавать о новой публикации, новостные ресурсы начали добавлять бесячую браузерную нотификацию о новых постах. А в телеграме же с точностью до наоборот. Пользователей просят нажимать «mute», чтобы новые посты не раздражали. Даже тем, кто не убрал звук оповещений, сообщение не приходит благодаря особому тихому режиму отправки сообщений. Попробуйте отжать «mute» на недельку на канале и убедитесь сами — появится значок непрочитанного сообщения, но форсированное уведомление приходить не будет. За другие каналы ручаться не могу :-)

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

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

Хочу попросить вас, мои любимые, рассказать о моем канале вашим друзьям. В телеграме ли, на фейсбуке ли. Может даже при личном контакте. Особенно приятно мне будет, если вы вместе со ссылкой на «Экстраполяцию» опубликуете понравившийся пост у себя на соц.страничке.

Люблю, целую, ваша «Экстраполяция».

Ссылка для ответственных, но ленивых: https://yangx.top/itextrapolation

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