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

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

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

Очень часто разрабочики забывают о том, что код программы пишется для людей, а не для компьютеров. Компьютер в состоянии выполнить код любой запутанности и сложности, а вот человеческий мозг нужно беречь и заботиться о нём. Почти всегда лучше пару раз нажать ctrl+c, ctrl+v и сделать код симметричным и декларативным, чем выписывать мапы и редьюсы с лямбдами.

Перефразируя Оккама:

Из двух одинаково работающих кусков кода лучше тот, который проще прочитать человеку.

Тупой начальник.

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

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

Касательно последнего поста, в чате появился очень правильный вопрос. Мол, как же в таком случае собеседовать человека, который как бы лучше тебя разбирается в том вопросе, в котором его надо собеседовать? Отметём очевидный способ приглашенного друга-эксперта и поговорим о небанальном.

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

Само собой, этот способ не будет работать в тех областях, где интервьюер дупля не отстреливает. Например, бренд-маркетолог собеседовать сеньорного программиста на кубернетосах будет крайне неэффективно.

Все побежали и я побежал.

Через тридцать минут мы будем в сами-знаете-в-чём осваивать разговорный жанр в рамках «Вечернего Лямбда Шоу». Назвали это «Lambda Talk Show #1» и я вообще понятия не имею как это название локализовать. Как оно пойдёт и попрёт ли я тоже не знаю, но надеюсь потом почитать ваши нетоксичные комментарии в чате.

https://joinclubhouse.com/event/MzE4E11R

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

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

Это правило бутерброда. Если что-то в макетах или документации можно понять неправильно, то оно обязательно будет реализовано неправильно.

Я тут прочитал охерительный критерий, как понять, легаси у тебя, или ещё нет.

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

#dimoneverything

Ребята, вакансия. Мне в команду нужен диджитал маркетолог. Колектив интересный, задачи дружные. Всё, как вы любите.

https://telegra.ph/Performance-Marketing-Lead-03-01

Задачи, о которых просят пользователи.

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

Есть две крайности, ударяться в которые будет очень плохо.

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

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

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

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

Природа уже настолько очистилась, что помимо маркетолога мы еще хотим усилиться руби разработчиком. Ищем уверенного мидла, в надежде доучить до восьмидесятого левела в процессе работы. Продукт, трэвел.
Третий руби, последний-распоследний рейлс, постгрес, реббит. Практически нет джаваскрипта, всё уверенно держится на серверном рендеринге. Сервисная архитектура, CI/CD, тестов могло быть и по-больше.

Резюме шлите мне в директ (@aratak).

И да, если вдруг вам не надо, то наверняка будет интересно соседу. Репосты и шаринги не только вакансий, а и других постов «Экстраполяции» мотивируют меня писать больше. Спасибо.

#экстравакансия

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

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

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

@pmdaily. Фёдор Борщёв — разработчик, который с лаконичностью, ничуть не уступающей «Экстраполяции» пишет о буднях разработчиков и менеджеров. Когда-то работал у Лебедева, а сейчас, по всей видимости, развивает свой собственный бизнес. Но это не точно.

@full_of_hatred. Владимир Рожков — тимлид из Киева. Много времени уделяет самоанализу и пропускает любую мысль через призму своего опыта. Поэтому его и интересно читать.

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

@evilmartians. Марсиане — пожалуй, единственный корпоративный канал, который ведут с душой.

@govorit_mark. Совершенно не помню как я подписался на Марка. Кажется, это было что-то из геймдева и вроде бы Марк в какой-то игре отвечает за нарратив, но это вообще не точно. Марк не пишет про айти, а в основном философствует. И у канала незаслуженно мало подписчиков.

Для вас — только самое лучшее, мои дорогие ❤️.

Позавчера Максим Ищенко в твиттере написал то, что «Экстраполяция» описывала еще два года назад. Не кликайте, я перескажу.

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

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

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

В трендах стартапов наблюдаю невероятной глупости новый вид приложения с общим названием «nocode».

Беда в том, что он был всегда, просто сейчас ему название придумали.

У вас на работе пользуются чем-то таким? Нравится?

Ух, какая жаркая дискуссия в чатике! В рамках #dimoneverything от Дмитрия у нас тизер дискуссии:

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

На мой взгляд, nocode имеет практическую применимость в прототипировании:

1. Заказчик/продакт думает, как могла бы выглядеть фича. И "рисует" её не в фотошопе и не на салфетке, а в nocode. Сразу со всеми подробностями и до тех пор, пока оно не начинает "работать" так, как ему нравится. Показывает её ребятам, которые тоже принимают решения. А потом в качестве части описания задачи спускает группе разработки. Которой, в отличие от фотошопа, не приходится задавать вопрос о том, а куда ведёт эта ссылка или как выглядит форма с ошибками. Это очень здорово, но. Это очень здорово в мире, где твои постановщики задач -- латентные программисты, только в код не умеют. На практике часть того, благодаря чему мы регулярно наполняем свои банковские счета, состоит в превращении бесформенной жвачки из головы постановщика задач в поставленную задачу, и исполнение этой задачи может занять зачастую и меньшее время, чем это превращение.

2. У ребят помельче, дизайнер превращает жвачку из головы заказчика не в набор слайдов в инвижнапп, а вот в такой нокод, показывает ему... в общем, всё как в №1. Это очень здорово, но если бы дизайнеры это умели, они бы программировали и не умели видеть красоту.

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

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

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

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

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

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

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

— Java очень хороший язык программирования с развитой инфрастуктурой и высокой отказоустойчивостью.
— PHP зарекомендовал себя, как легкий в изучении, быстрый и удобный инструмент для построения больших веб-приложений.
— JavaScript быстрый, удобный и универсальный язык программирования, который позволяет с легкостью писать код как на клиенте, так и на сервере.
— Ruby крайне прост в изучении и универсален в использовании. Стоимость разработки на этом языке с лихвой окупает его низкую производительность и писать на нем — одно удовольствие.

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

Слева — прототип фотоаппарата, разработанного дизайнерами. Справа — фотоаппарат, который таки выпустила фирма «Лейка».

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

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

#dimoneverything из рабочей переписки:

«Окунулся я тут недавно в мир px, em, rem и прочих LGBTQ…»