В гостевом порядке

Посетил выпуск подкаста "Цинковый Прод". Сидим с ребятами, перетираем за IT всякое, обсуждаем новости. Получилось лампово

https://www.youtube.com/watch?v=SmX19dZmof4

Сегодня я рефакторил код (ч.2)

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

И занимаюсь я этим подолгу. Над рефакторингом большого проекта я могу работать и по 12 и по 20 часов. Потому что контекст большой, в голову его подгружать долго - надо сделать пока не забыл, пока держу в голове взаимосвязь сущностей и 4 последних стектрейса от эксепшонов. И мне это, кстати, нравится. Потому что видишь ты перед собой кусок говно-софта с дебильным внутренним устройством. Или бессмысленный код, дублирующий друг друга приводишь к единому виду. И раз, становится с проектом работать удобнее. Его структура становится проще и понятнее. Раз - и билд начинает проходить чуть быстрее. Раз - и метод, который раньше подвисал, потому что при определённых условиях лезет в инфраструктуру начинает работать шустрее потому что использует дотнетовский Lazy<> при доступе к одному из локальных полей.

Если вы считаете что это бесполезное занятие - идите-ка в жопу.

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

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

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

Вот так и обстоит у меня дело с рефакторингом. Интересно, а как этот процесс проходит у моих читателей?

Такие дела

Эпоха развитого социализма

У нашей индустрии много денег. Очень много денег. ПИЗДЕЦ КАК МНОГО. В современном мире мы вроде как главные. Общество двумя ногами опирается на Интернет, как в своё время опирался на электроэнергию. А интернетом рулим мы — айтишники. Прорва бабла позволяет кушать больше, а думать и работать меньше. Это явление известно в истории как "эпоха развитого социализма". Почему бы об этом не поговорить?

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

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

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

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

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

Вот в СССР было принято устраивать столовые при заводах и институтах, пищеблоки при больницах, кухни в школе. И IT эпохи развитого социализма эту практику дичайше котирует. Когда появляется корпоративный холодильник с бесплатными напитками — это терпимо. Когда к напиткам добавляются закуски — это ту мач. Когда заключается контракт с кейтеринговой службой на доставку полноценных обедов каждый день — это a way too much. Пик коммунизма же достигается когда в офисе появляется кухня. Я самолично видел директора, который в такой вот офис с кухней нанял повариху! Она приходила и готовила еду небольшой команде разрабов! Да, вы скажете что это типичная стартапно-гугловая история, но сука этот офис был в Люберцах! Понимаете? В ЛЮБЕРЦАХ!

Что же происходит на рабочих местах? Первым делом разводится класс номенклатуры и бюрократов. Формальности становятся важнее людей, показатели и отчётность важнее работы. Что имеем мы? Показатели спустя 30 после развала Союза назвали KPI и внедряют под видом новомодных управленческих практик в каждую IT-забегаловку, а про оптимизацию процессов вам прожужжат уши на любой конференции.

Но самое вкусное — это наша номенклатура. Когорта бестолковых манагеров. Наша гордость. Наши "последние комсомольцы".

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

Они же приносят с собой ценности, подчёрпнутые из Карнеги и книжек по гламурной психологии: "не быть токсичным", "work-life balance", "важно как мы общаемся", "деньги — не главное", "пятилетку за три года" простите это из краткого курса ВКП(б). Как и в СССР, эти ценности имеют мало общего с реальностью. Они превратились в выхолощенные и казённые лозунги. Пролетариату полагается улыбаться и заучивать термины из новых методичек.

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

———

СССР плохо кончил. Говорят, из-за того, что социалистическая модель порочна по своей сути и порождает злокачественные экономические мотиваторы. "Социализм кончается когда кончаются чужие деньги" — то ли Тетчер сказала, то ли Черчилль. Не знаю чем дело кончится в случае с IT и так ли всё серьёзно. Но тревожные мысли о грядущем кризисе время от времени лезут в голову.

Вот пусть вам теперь тоже лезут.

Такие дела

Сеньорность in habitat

Надысь в твиттере что-то расплодились треды про сеньорность. Вот и я закину свои пять копеек.

На оба треда ответ — нет. Нет в нашей индустрии чёткой линейки. И никогда не было. Начнём с того что в аутсорс-галерах лычку "сениора" дают тупо за выслугу лет. Обычно - крайне маленькую. От 3 до 5. Приходили ко мне такие мальчики на собеседования, да. Самому младшенькому было 23. За плечами 2-3 проекта в лучшем случае, фундаментальных знаний ноль, код пишет как обезьяна лапой. И ничего — гордо называет себя сениор. Приходил и сениор, который не знал чем cookies отличается от сессии. Мрак же? Но на своём рабочем месте — сениор. Так что, планка сениора — большая условность и варьиуется от компании к компании.

Теперь про потребности бизнеса. Увы, но факт: зарабатывает на разработке только очень и очень маленький IT-бизнес. Вооот такусенький. Питающийся, можно сказать, подножным кормом. Или аутсорс, но там своя история. А когда потребность в ежедневном баблопотоке отпадает — у бизнеса натурально отлетает кукуха. Разработка замедляется и требования не только к сениорам, а к разработчикам вообще начинают свой вояж в неведомые ебеня.

В одном месте от разработчика хотят чтобы он был со всеми мил в общении и участвовал во всех встречах (хотя бы номинально). В другом — чтобы разделял ценности критической расовой теории и яро поддерживал LGBTQ+. В третьем ненавязчиво требуют лизать жопу начальству и восхвалять технический скилл Самого учредителя. В чётвёртом — чтобы сам умел смотреть в продуктовые метрики (вам знакомы термины Retention, Churn, LTV, NPS, D/MAU? Вот то-то же). В пятом нужно знать все тонкости гибких методологий разработки и молиться на Scrum Guide. В шестом предпочитают набирать любителей просыпаться в 4:20 (если вы понимаете о чём я). В седьмом хотят чтобы разработчики "были счастливы на своём рабочем месте", что бы то ни значило.

И так далее.

Верный маркер таких бизнесов на собесе — или какая-то экзотика ("покажи фотографию своей книжной полки": мой любимый пример, который подарил мне Лекс АйтиБорода при очень необычных обстоятельствах), или дежурное решение leetcode в технической части, или какое-то невообразимо огромное количество этапов. Важно же, как мне кажется, понять главное:

Таким бизнесам не нужен разработчик вообще. Совсем. Потому что ну не принесёт он сколько-нибудь значимых денег. И не потратит.

На чём же там зарабатываются деньги? Если это стартапная история — то инвестиции. Разработка заканчивается на этапе "сляпать MVP", а в остальном это про то, как правильно торгануть лицом. B2B — это продажи крупным клиентам. Особенно если вовлечён американский deep business. Миллиарды баксов. Основной продукт ужасен, неудобен, но уже сделан. Обслуживать его особо много ума не надо, а в остальном — опять же про торговлю лицом и решение вопросиков с нужными человечками. Если это продуктовая компания, скажем продающая приложеньки — то основной источник бабла — маркетинг. Реклама, реклама и ещё раз реклама. Добавить немного b2b по вкусу. Продукт, опять же, написан и требует лишь доводки и поддержки. Если это FAANG, то не исключены госзаказы и стратегические сделки. Ну не принесёт разраб FAANG-у полтора миллиона пользователей в базе данных, как ни крути.

О чём мы? Ах да, о сениорстве. Знаете, мне нравится такой подход: берите задачи, которые вам не по зубам и грызите потихоньку в свободное от работы время. Так чтобы решить, откинуться в кресле, посмотреть на результат и сказать самому себе — "а я хорош!". Станьте самому-себе сениором. Заодно синдром самозванца подлечите.

Такие дела

500 человек. Вы ж мои яхонтовые. Продолжаем. Материала ещё мнооого.

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

Уроборос Аджайла

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

Тезисы, красивые настолько же, насколько и туманные. Насколько пресловутый PRINCE2 или PMBOK был понятен в одно лицо с книгой, настолько же Agile требовал непременного "тренера". Тем не менее, индустрия постепенно облекла их в понятные формы и взаимодействия. А дальше случилось то, что и должно было случиться -- Agile Manifesto 2.0. И звучит он так:

- Команда и ответственность важнее индивидумов и взаимодействия
- Бизнес-ценность важнее рабочего продукта
- Развитие партнёрских отношений важнее сотрудничества с клиентом
- Готовиться к изменениям важнее реакции на изменения

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

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

Джуниор-манагеры

Забавляют меня манагеры-неофиты. Особенно прикольно когда они пытаются блеснуть терминами, смысл которых не понимают. Вот надысь один такой ляпнул: "никогда не увольнял людей по hard-скиллам, потому что их можно подтянуть — только по soft". Я сразу вспомнил историю.

Работала в одной конторке весёлая девочка. Любила она свою работу (аналитик-тестировщик), вкусно покушать, чёрный юмор и поприкалываться. И вот как-то во время напряжённого дедлайна, дабы разрядить обстановку она выдаёт мрачную шутку чисто в своём стиле: "наша база данных — редкостное говно. Давно пора её грохнуть и создать заново". Коллектив поржал, а через неделю девочку ко всеобщему удивлению уволили. Само собой, "за плохие софт-скиллз".

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

Так я впервые узнал что на самом деле означает увольнение "по софт-скиллам".

Чему нас учит эта история? Подмене понятий. Джун-манагеры не понимают значение термина и подменяют "soft skills" на свои личные предпочтения в общении. Как следствие — набирают людей "под себя", игнорируя нужды продукта. В мою молодость это называлось "самодур". А это обстоятельство полностью дезавуирует руководителя профессионально. Так и хрен бы с ним, но ситуация становится одиозной, когда человек вместо того, чтобы скрыть свой непрофессионализм — наоборот им публично хвастается! А потом удивлённо получает половых органов в панамку.

Грамотное построение команды требует педагогических скиллов. В первый раз я прочувствовал это на своей шкуре в детстве, когда съездил в ВДЦ "Океан". Собственными глазами я увидел как профессиональные педагоги делают дружные и слаженные команды из злобных и циничных подростков всего за месяц. Это потрясающе. Позже я увидел как работает действительно профессиональный HR, настраивая атмосферу в команде на продуктивный лад. Они не разруливают конфликты — они их предотвращают! Вот это я понимаю, профессионализм. Респект. Так же я видел руководителей, которые нанимают по личным предпочтением, но у них в голове, чёрт побери, есть видение как должна работать команда, а не модные баззворды. И стальные яйца. Круто, покупаю.

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

Почему джуниор софтвер-инженеры есть, а джуниор-манагеров нету? Они сразу же рождаются профессионалами? Хм. Я бы таким на лоб клеил табличку "за рулём курсант".

Такие дела

Дополнение

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

Удивительно, почему же с наймом такие проблемы?

Такие дела

Всего два скилла

Хороший инженер отличается от посредственного инженера наличием всего двух скиллов:

- отделять главное от второстепенного
(aka "ухватывать суть")

- разбивать сущности на подсущности
(задачу на подзадачи в частности)

Покатайте в голове.

Такие дела

Лайвкодинг

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

До того как начать: если в резюме кандидата упомянут аккаунт на github/gitlab/bitbucket и он не пуст, то лайвкодинг отменяется. Как быть с людьми, у которых уже есть публично доступный код — в следующем посте. Если такового нет, то будем готовиться к лайвкодингу.

Самый скользкий момент тут это психология. Оперативно сообщаю: шарить экран (как и думать) — это процесс интимный. Кандидату надо к нему подготовиться: расслабиться, закрыть порнуху, скайпы-телеграмы, убрать неприглядные документы с рабочего стола, подготовить IDE и т.п. Поэтому о формате интервью договариваемся с кандидатом ЗАРАНЕЕ, в деталях объясняя что именно будет происходить.

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

В чём суть? Мы пытаемся понять как человек думает и работает. И работать ему предстоит именно с вашим кодом. Поэтому открываем код продукта в IDE, выписываем на бумажку самые глупые места, которые видим — и вот у нас уже материала на час собеседования. Из таких кусков кода можно сформулировать вопросы по методологии STAR, что нынче модно. Говоря по-русски: "чем этот кусок плох/хорош" — "какие проблемы видишь?" — "давай его поправим" — "почему так лучше?". Загружаем эти вводные в кандидата, даём контекст и просим сначала подумать вслух, подискутировать, а потом переписать как он считает нужным. Неплохо помогает понять человека на техническо-ценностном уровне.

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

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

Стоит ли напоминать, что всякие онлайн-тулы идут нахуй? Видимо, стоит. Ребятки, смотрите: хирургу нужен операционный стол, токарю нужен токарный станок, конструктору нужен автокад, а разработчку нужна IDE. Мы можем попросить токаря сделать что-нибудь кухонным ножом из ножки табурета, но едва ли это даст нам представление о том, насколько этот токарь хорош. Поэтому только IDE. И если от установки TeamViewer у вас вдруг отвалится жопа — я лично оплачу вам лечение.

И напоследок про алгоритмы. Решение алгосов что-то скажет вам о человеке только если вы сидите с ним рядом и решаете задачку вместе. Задавая наводящие вопросы и намекая на решения. Зелёная галочка на leetcode говорит лишь о том, что человек задрачивал литкод пару месяцев, сидя на дошираках. Алгосы — это бездумная традиция FAANG-ов, а вы не FAANG. Смиритесь.

Такие дела

Как смотреть в github-репозиторий

Ситуация: к вам на собес пришёл человек, у которого есть аккаунт на гитхабе. Вы прошли по ссылке и обнаруживаете что там что-то есть. Ааа! Ужас! Что делать со всей этой информацией? Кто все эти люди, что происходит?!

Спокойно! Без паники! Новиков снова забирается на коробку из-под мыла и сейчас всё расскажет на примере своего же репозитория Reinforced.Typings. Как же не попиарить себя-любимого!

Итак, перед вами обычный git-репозиторий, в который человек написал что-то от души. Для начала неплохо бы понять что вообще. На этот случай в гитхабе предусмотрен README.md, призванный кратко раскрыть суть проекта. Его вы видите прямо перед собой, под списком файлов. Справа есть описание и хэштеги. А ещё там наверху есть вкладочка Wiki. Тыкните на неё и посмотрите есть ли там что.

Это всё — про информационное сопровождение репозитория. Если разделы не заполнены, то тут два варианта: или человек несерьёзно относится к своей публичной деятельности (и тогда зачем он вообще дал ссылку?), или же тут нам намёкают на лень/необязательность, или человек просто не может в красноречие. Далеко идущих выводов делать не стоит (вам вполне могли дать ссылку на работу, которая "в процессе"), но общую картину дополняет.

Если информация заполнена, то можно сходу оценить уровень владения английским языком (актуально для СНГ), умение формулировать и излагать мысль. Да-да, дорогие мои. Если человек осилил написать доку к своему проекту — то отстаньте от него с глупыми вопросами про софт-скиллз. Вы прямо сейчас можете почитать текст, который человек выдаёт из головы чтобы "пошарить нолидж" с незнакомыми людьми — так чего вам ещё надо?

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

Справа снизу разбивка по ЯПам проекта. Тыкнув на язык можно получить данные о количестве файлов с кодом на выбранном языке программирования. Не LoC, но позволяет грубо понять объём выполненной работы.

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

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

Чуть более полную картину можно посмотреть в Pull Requests - Closed и Issues - Closed. Если там есть информация — прекрасно. Можете открыть, почитать комменты и ещё больше узнать о том, как человек коммуницирует. Если информации нет — то ничего не поделаешь, придётся с человеком разговаривать.

Смотрите, сколько информации. И это за 5 минут и 3 клика мышью. Я даже код не открыл.

А текста уже слишком много. В следующем посте я расскажу как правильно смотреть код.

Не переключайтесь

Об внедрение Скрама.

Работать некому, в стране одни коучи. Вчера я видел вакансию OKR коуча. То есть буквально - человек, который никак не отвечает за результат, будет помогать командам понять, чего они хотят в эту итерацию. Очень красиво, правда?

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

Если вы посмотрите в конкретную ситуацию, которые я видел не раз, вы обнаружите одну или несколько причин из списка:
1. Это не выгодно скрам-тренеру. Ну, потому что его очень быстро попросят на выход, то есть -- прямо закрутят финансовый поток в обмен на "кейс" какой-то степени успешности. Несколько успешных кейсов, разумеется, нужны для презентации, а дальше они становятся бесполезны.
2. Это не выгодно менеджменту. Потому что задача Скрама - устранить препятствия на пути работы команды. И очень быстро становится понятно, что главным препятствием на пути работы команды становится непонимание среднего менеджмента, как вести компанию дальше - видение есть, стратегия, может быть, есть, но средний менеджмент в недоумении, как это превратить в планы. Выражаясь другими словами, внедренный Скрам быстро перемещает бутылочное горлышко на сторону бизнеса. Если раньше можно было ссылаться на священную, но очень упрямую корову ИТ, то теперь уже нельзя, ИТ готов к работе и предсказуем (почитайте: https://habr.com/ru/post/567416/). Еще по этому вопросу можно почитать саркастическую "Черную книгу скрам" (https://iselihovkin.com/bookonline)
3. Это не выгодно самим командам. Самоуправляемые команды, как идеальный газ, случаются не часто, на пути их формирования -- системный кризис, который может вылиться в масштабные увольнения не готовых к "бирюзе".
4. Скрам это дорого - я уже выше писал несколько раз, почему.
5. Банально, сейчас на скрамизацию благополучно списываются бюджеты обучения подразделений, и это всех устраивает.

Часто ситуацию поясняют философским "easy to start, hard to master", особенно тренеры, но тут очень простой ответ: потому что это не выгодно никому.

Как смотреть в код

Это продолжение предыдущего поста.

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

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

Для начала: необходимо чтобы вы сами были знакомы с платформой/языком, на котором исполнен проект. Нужно это чтобы отличить авто-генерированный и glue-код от того, который автор написал сам. А то будете как дурак копаться в node_modules и восторгаться талантом, а человек просто не знает что node_modules добавляют в .gitignore. Fail. Так что в целевой платформе надо шарить хотя бы в общих чертах.

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

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

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

Пытаемся въехать в проблематику и общий дизайн решения. Если удалось понять дизайн — ищем в нём огрехи и фиксируем вопрос для личного разговора. Если дизайн понять не удалось — кандидату же хуже. Будем заставлять рисовать дизайн на доске и объяснять почему так. Для проформы можно выбрать несколько совершенно рандомных файлов, притащить их кандидату и пытать на тему зачем они нужны и почему без них нельзя. Только смотрите не обосритесь, а то притащите код, сгенеренный фреймворком — стыдно потом будет. Хотя толковый кандидат и за генерированный код сможет пояснить.

Дальше надо составить общее понимание о том, как человек пишет. Откройте 10 рандомных файлов из разных точек проекта. Посмотрите насколько код в целом вменяем, написаны ли комменты, соблюдены ли naming conventions. Смотрите, используются ли фишки платформы и правильно ли они используются. Например в C# можно смотреть using-и, lock-и, системные атрибуты, правильную перегрузку equality members, корректное использование EF, ASP .NET MVC и иже с ними. Если понимания не сложилось — откройте ещё 10 файлов. И так далее, пока не сложится. Все возникающие вопросы записывайте в блокнотик и откладывайте до личного разговора.

Так же стоит обратить внимание на unit-тесты и сборочные скрипты. Если они есть — это win. Если проект собирается и выкладывается через github actions — это flawless victory. Если при этом ещё и прогоняются тесты — это fatality. Человек шарит за CI/CD, тестирование и — самое крутое — умеет это настраивать и использовать. А если у него есть понимание зачем это надо (уточняется в лично разговоре) — делайте оффер.

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

Не переключайтесь.

Внеочередной пост: Xsolla

Подробности, например, тут.

Эффективный менеджмент очередной раз обосрался. Как же мы удивлены (нет).

Кратко: манагер-самодур посмотрел в непрозрачные KPI, сократил по ним народ и попытался объяснить как бигдата теперь стоит на страже продуктивности и вовлечённости. Сообщество инновацию почему-то не оценило и справедливо насыпало герою истории половых органов в панамку.

Главное в этой истории, мне кажется, следующее.

Посмотрите на речь CEO. Она очень характерна. Это просто кладезь типичных для "эффективного" манагера штампов. Весьма специфичный лексикон, не так ли? Посмотрите на него и хорошенько запомните. Это — детектор людей, с которыми ни при каких обстоятельствах нельзя иметь дел.

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

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

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

Не ведитесь на буллшит. Никакой пощады некомпетентным самодурам. Созданные ими компании не должны иметь возможность нанимать персонал, и, как следствие, существовать.

Такие дела

О чём говорить с владельцем github-репозитория

Это продолжение предыдущего поста.

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

Вопрос №0: зачем? Какая задача решается?

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

Вопрос №1: кто ваши конкуренты? Чем они хуже?

Это любимое "а ты готовые решения погуглил?", поданное чуть сбоку. Готовое сейчас есть для всего, но у человека могут быть свои представления о прекрасном. Пусть изложит их. Если у кандидата есть целостное видение — лично я такое покупаю. А если "ниасилил" и прочее not invented here — не покупаю. Не стоит впадать в маразм и с порога орать "есть готовое — возьми!". Помните, что React и Angular — взаимные велосипеды. Конкуренция — штука хорошая, но должны быть и конкурентные преимущества.

Вопрос №2: назовите недостатки вашего решения.

Здесь мы проверяем знание своего же продукта и, внезапно, ЧСВ. Не торопите с ответом. Привёл технические недостатки - молодчик, хороший разраб. Привёл продуктовые недостатки — молодчик, хороший продакт. Не видит недостатков — фейл. Хорошие разрабы часто не видят продуктовых недостатков и в большинстве случаев это признак самолюбования. Вера в свой продукт похвальна, но надо понять насколько человек в контакте с реальностью. Вопрос основан на открытом мною лично рычаге "порог входа/функциональность": если продукт перебивает конкурентов по функциональности, то достигается это высоким порогом входа. И наоборот: ниже порог входа — меньше функциональности. В любом случае один из двух недостатков есть: продукт или сложный или нефункциональный. Неплохо, если автор это понимает. Бывает и то и другое. И это печально.

Вопрос №3: чему вы научились в ходе работы над этим проектом?

Многогранно. Отлично проверяет "горящие глаза". Хороший разраб всегда найдёт что рассказать. Как по технической части, так и по продуктовой. Тут у вас будут вводные чтобы оценить проактивность, посмотреть на ценности человека, а так же на потенциальное направление развития: начал про код лечить - супер, берём, вырастет в архитекта. Начал про продукт - супер, хватай будущего манагера. Сказал и про то и про другое — упс, ваше кресло в опасности. Начал задвигать про важность коммуникаций и маркетинг — это продаван, смотрим с пренебрежением.

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

Напоследок, один важный момент: человеку, который уже реализовал что-то своё писать код может быть тупо неинтересно и взятие его на должность разраба при невозможности предложить бОльшее — плохая затея. Это также валидная причина для отказа. Называется overqualified. Так бывает и в этом случае постарайтесь не мучать человека почём зря, а поблагодарить за уделённое время, похвалить и с сожалением признать что не осилите.

Такие дела

9 августа

9 августа 2020 года произошли исторические события: печально известные шестые выборы президента Республики Беларусь. Так получилось, что это время я провёл в Минске. Сам б-г велел надеть шляпу gonzo-журналиста и сделать небольшой recap произошедшего. Погнали.

Началось всё в феврале, с пандемии. В COVID Лукашенко сразу зашёл с козырного диссидентства: заявил, что никакого вируса нет, а поле и трактор лечат от всех болезней. И можно было бы сказать, что это шведская модель борьбы с коронавирусом, но в Швеции это была осмысленная политика (коллективный иммунитет), а в Беларуси — безграмотность и самодурство. Потом Лукашенко кулуарно заявит, что не хотел стопить экономику, но к тому времени у него уже будут проблемы по-серьёзнее.

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

Уже тогда многие подмечали, что отрицать COVID — не самая успешная предвыборная стратегия. А Лукашенко как будто этого мало: 9 мая 2020 года он устраивает военный парад в центре столицы. Маски? Дезынфекторы? Пфф, зачем. Зато каждому белорусу стало очевидно, что у президента истёк срок годности и пора бы его выкинуть.

Предвыборная гонка прошла в лучших традициях РБ: допустили всех, но оппозиционные кандидаты сели (Бабарико, Тихановский) или уехали из страны (Цепкало). И тут случилось неожиданное: места исчезнувших кандидатов стремительно заняли их жёны. Кажется, это удивило даже Лукашенко и он-таки допустил до выборов Светлану Тихановскую. Позже усатый намекнёт, что сделал это ради лулзов.

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

Белорусов удивила не столько фальсификация, сколько вопиющая наглость, с которой сову натянули на глобус. Многие признают, что нарисуй Лукашенко комплиментарные 60% — не было б печали. Но получилось как всегда.

Первых протестующих жёстко задерживают и увозят на Окрестина. Открываются ужасающие подробности о пытках и избиениях, а так же об устном приказе "бить так, чтобы больше не вышли". Вся Беларусь шокирована самим фактом, что усатый построил Гестапо. В 2020. В центре Европы. В лучших нацистских традициях. И это не художественное преувеличение. Обязательно посмотрите большой выпуск "Мы Обречены", посвящённый этим событиям. Егор Малькевич весьма точно рассказывает что происходило.

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

Протестные будни были богаты на драматичные сюжеты. Отключения интернета, транспаранты, флаги, шарики, ашушэние праздника, чешские светошумовые гранаты, резиновые пули, Колесникова рвёт паспорт, Коленька в бронежилете, Ник и Майк, снятая на лавочке обувь. Лично мне довелось подвозить воду протестующим, раздавать БЧБ-гвоздики, спрятаться от ОМОНа в подъезде и убегать от гранат возле ТЦ Рига. Буквально про каждый день белорусского лета-2020 можно писать лонгриды.

...

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

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

Такие дела

Лично

Я завтра вечером я буду на митапе TheRocketBeer в Питере. Происходить всё будет по адресу по адресу наб. Обводного Канала 136 (спейс COM.NATA). Если вы туда уже зарегистрировались — увидимся лично.

Такие дела