Место, где свет

Ребята из RndTech снова делают хорошее дело – собирают данные об узнаваемости и привлекательности брендов ростовских IT-компаний. Приглашаю присоединиться к опросу здесь :)

☕ Рекомендация: Теоретический минимум для программиста

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

-------------------

В общем-то посты о том, чего я не знаю, я могу больше не писать. В этом т.н. «минимуме» упаковано материала на десятки лет вперёд, и до пенсии этих тем мне точно хватит :)) Осталось только понять, зачем.

☕ Рекомендация: Сценарий идеального технического собеседования

Дисклеймер: это сценарий идеального технического собеседования в Delivery Club Tech. Мнение нашей команды может не совпадать с мнением читателей.

-------------------

Та структура собеседования, которая описана в статье, отчасти напоминает тот процесс, к которому я в конце концов пришёл по ходу кампании найма сотрудников в Trucker.

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

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

☕ Рекомендация: joelparkerhenderson/architecture_decision_record

Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation - joelparkerhenderson/architecture_decision_record

-------------------

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

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

Регистрируйтесь и приходите послушать, верю, что будет классно!

☕ Рекомендация: Opium.Fill — стандартизация цветовой схемы глазами программиста — Дизайн на vc.ru

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

-------------------

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

☕ Рекомендация: Brown M&Ms, or Why No One's Reading the Manual

«Yes, people don't read the docs. But that doesn't mean they shouldn't be written at all – rather, they should be designed for people who don't read.»

-------------------

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

И в этом случае кажется, что UX вашего Confluence не должен отличаться от сценария, когда кто-то к кому-то пристаёт с вопросом и получает конкретный ответ. А значит, хорошая статья документации – это маленькая статья с перекрёстными ссылками и с понятным заголовком, которую легко найти в поиске.

Agile снаружи, дерьмо внутри

Популярная история, которую я наблюдал не раз и не два, выглядит примерно так: к команде разработчиков, которые работали до этого вообще абы как, приходит руководство (или в совсем тяжелой ситуации – Agile-коуч) и говорит, что теперь мы работаем по Scrum/Kanban/etc. "Давайте, – говорит, – возьмем Jira, будем там вести задачи, будем делать демо и ретроспективы, и тогда станем настолько гибкими, что сможем садиться в шпагат между грузовиками как Ван Дамм!". В ответ он получает вялые отклики сотрудников, но деваться им некуда – если пришёл босс и сказал самоорганизоваться, то значит надо. И вот Jira заполняется несметным количеством карточек, которые программисты могут в какой-то момент даже достаточно быстро начать двигать по доске с энтузиазмом. Однако, затем скорость разработки драматически падает, а затем падает и качество работы. Дальше у кого-то сдают нервы, кто-то спивается, а кто-то увольняется. Разработка останавливается. Такая вот драматическая история.

Я долго думал, что что-то не так в консерватории – стулья, может, надо переставить? Долго сам раньше пытался осознать, где лежит проблема – менял процесс, вводил практики и т.д. Какие-то шаги помогали, какие-то – нет. Потом, конечно, послушал подкаст великолепного Олега Сороки про дисфункции организации и понял, что проблема всё же не в спринтах. Но в чём? Все точки сошлись воедино, когда дочитал наконец "Чистый Agile". Немалую часть книги Роберт Мартин озвучивал практики и принципы методологии экстремального программирования (XP), которая была предшественником Agile, а затем ловко завернул аргументацию так, будто бы принципы XP важны для любой Agile-методологии. И вроде бы это манипуляция в чистом виде, но чёрт возьми, он прав! Что, ничего не поняли? Сейчас объясню.

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

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

☕ Рекомендация: Полиморфизм простыми словами

Скорее всего вы уже встречались с понятием «полиморфизм» и даже помните пример с наследованием кошек и собак от Animal или квадратов и кругов от Shape. Однако эти примеры показывают далеко не всё, что скрывается за полиморфизмом.

-------------------

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

Давно не появлялось в эфире #медленное_радио. Исправляюсь.

Сегодня – GoGo Penguin с одноименным альбомом «GoGo Penguin», который вышел 5 июня 2020 года. И да, это снова джаз.

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

Всё, что я описал выше, вообще никак не относится к музыке GoGo Penguin. Они как джазисты не обходятся без экспериментов, но их границы, тем не менее, можно легко проследить и не потеряться где-то посередине. Каждая композиция – хитрое переплетение из всего трёх инструментов: ударной установки, фортепиано и контрабаса. Благодаря такому минимализму достаточно легко воспринимаются даже самые отважные гармонические ходы. Вся их прелесть именно в том, что они не пытаются удивить слушателя какими-то трюками и не делают специальную музыку для музыкантов. Пока готовил этот пост, то вычитал, что критики находят сходство их музыки с Massive Attack, и в чем-то оно действительно прослеживается.

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

Слушать новый альбом: Яндекс.Музыка, Google Play Музыка, Apple Music, Spotify

Прямо сейчас я участвую в онлайн-конференции Podlodka Teamlead Crew – двухнедельном марафоне с массой интересных активностей и довольно-таки живых обсуждений. Закончилась первая неделя конференции, и у меня есть несколько мыслей по итогам.

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

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

Сообщество. Оффлайн-мероприятия слишком сильно зависимы от географии участников. Больших трудов стоит пригласить эксперта из другого региона на вашу маленькую сходку, чтобы хотя бы немного прикоснуться к его опыту. Здесь всё иначе – есть множество знакомых по различным активностям людей из компаний разного калибра – Яндекс, Лаборатория Касперского, Badoo, JetBrains, Lamoda и т.д. и т.п. А благодаря paywall'у в сообществе практически не встречаются сомнительные люди, с которыми невозможно вести осознанный диалог. Открытое к обсуждениям сообщество адекватных людей – это всегда замечательно.

Интерактивность. Очень показателен пример книжного клуба, где во время серьезного обсуждения по книге у всех участников была ещё возможность неформально пообщаться в чате созвона и посмеяться. Не могу представить себе такое на оффлайн-встрече. Ещё не могу не отметить мастер-класс по коммуникациям от Ильи Синельникова, где он активно подключал слушателей к разговору и строил свой мастер-класс от участников. Это не телевизор с докладами, это настоящая конференция с живым общением и возможностью в любой момент включиться в разговор, поделиться своими мыслями и задать вопросы. Я слышал от участников Подлодки, что очень много вопросов вызывают конференции Олега Бунина, перетёкшие в онлайн-режим – аудиторию зачем-то разделяют на YouTube-холопов и Zoom-боярей. Подлодка в этом смысле куда более весёлая.

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

Всё вышесказанное – отчасти реклама, но больше всё же личное мнение. Хорошую конференцию и прорекламировать незазорно.

☕️ Рекомендация: #166 – Переговоры

Мы ведем переговоры каждый день – споря о сроках выполнения задачи, проходя собеседование на работу, договариваясь о скидке в магазине. И чаще всего мы это делаем неправильно. В этом выпуске Илья Синельников, преподаватель курса по переговорам в Школе Бюро Горбунова, разбирает основные приемы успешного переговорщика и сразу отрабатывает их с ведущими на кейсах.

-------------------

Отличнейший выпуск Подлодки о том, как построить экологичные конструктивные переговоры вокруг какой-то проблемы и попытаться найти для неё решение. Дослушал его сегодня утром, а вечером на Podlodka Teamlead Crew ещё и ворвался к Илье Синельникову на мастер-класс по переговорам и проверил, правильно ли я всё воспринял – оказалось, что да, и я молодец ^^ В выпуске можно услышать много интересного о вреде поиска компромиссов, об "айкидо" в переговорах, работе с эмоциями, предоставлении путей отступления оппоненту и т.д.

☕ Рекомендация: Event Storming на практических кейсах

Event storming – это способ собрать вместе разработчиков и экспертов в бизнесе для быстрого, совместного исследования сложной предметной области бизнеса

-------------------

Офигенно. Очень нравятся подходы из DDD, потому что они позволяют взглянуть на процесс и уловить мелкие детали, которые обычно ускользают от внимания. Так происходит из-за того, что процессы в больших системах никто и никогда не понимает целиком. Event Storming – одна из методик фасилитации встречи, которая позволяет вытащить из всех участников проекта неочевидные детали, и о её принципах неплохо рассказывает эта статья.

☕ Рекомендация: Профили инженеров

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

-------------------

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

☕ Рекомендация: Git from the inside out

-------------------

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