noTieinIT - Об IT без галстуков

2021-10-13 18:47:00 ​​ Что с рынком?

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

Почему происходит рост? Я вижу несколько факторов.

В США и ЕС была произведена денежная эмиссия (то что у нас называют “напечатали денег”) за последние полтора года на огромные суммы, триллионы долларов и евро. Это подстегивает инфляцию и вы уже могли видеть рост цены на дерево, металлы, стройматериалы, недвижимость, землю и т.п., а также эти деньги попадают в IT сектор и выросло количество проектов на которые нанимают. Вот и превышение спроса над предложением.

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

Отток хороших специалистов. К сожалению, часть знакомых перебралась в 2020-2021 в другие страны, а большинство компаний из FAANG начали хантить специалистов из СНГ и релоцировать их в ближнее зарубежье. На данный момент можно лишь сказать, что для хороших специалистов релокация в ЕС или UK является менее выгодной в экономическом плане на фоне СНГ. Мало того, что в ЕС уже сейчас зарплаты до вычета налогов (gross salary) ниже или сопоставимы с зарплатами в СНГ, так и налоговая нагрузка в ЕС/UK выше, а на руки в ЕС/UK (net salary) останется куда меньше. Но люди едут за новым опытом, за стабильностью и порядком, жертвуя снижением дохода.

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

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

Энивей, в таких условиях приходится нанимать и меняться самому, менять подходы к найму. О том какие выводы я сделал и меры предпринимаю будет отдельная серия публикаций. Stay tuned. Открыть/Комментировать

2021-10-13 10:47:00 ​​ "Дима, что дальше, ты где?"

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

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

Из нового для себя: добавилось много всего с Amazon AWS, а также появился .NET где много low latency, что прикольно.

Не очень прикольно лишь то, что IT рынок колбасит последний год. Об этом далее пойдет серия публикаций. Не переключайтесь) Открыть/Комментировать

2021-05-07 13:22:59 ​​ Спустя 8.5 лет я ушел из Авроры, переболел короной, готовлю лайв с приятелем из Google и лайв-батл с гостями из QA Guild (Manual vs Automation).

Закончился мой забег и наступил тот момент, когда я решил уйти из компании. Если так задуматься, то 8.5 лет - это огромный срок и за это время было множество свершений. Были и переключения на разные виды бизнеса, и построение новых бизнесов с нуля, были и непростые ситуации... Самым ценным я считаю собранную команду, которая всегда желала большего и двигаться вперед. Особенно приятно слышать отзывы разработчиков, QA и админов, которых я нанимал и помогал расти, что в их карьере самая сильная техническая команда была именно в Авроре. За качество не стыдно) Да и по культуре собраны были уникальные люди. Можете похвастаться тем, что люди могут самоорганизоваться за 2 дня и выехать на выходные с палатками за город?) Или поехать на горнолыжный курорт
толпой в 8-12 чел, да и не раз, а из года в год? Всем с кем работал - большой респект, вы в моем сердце навсегда.

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

Еще я успел переболеть короной ... Ну и как настоящий экспериментатор я прошел весь флоу с гос. поликлиниками и семейными врачами. Тут несколько основных поинтов: идиотизм процветает, но с другой стороны, семейные врачи пытаются сделать добро, но система их давит. Примеры идиотизма: только у нас могут догадаться в двух соседних кабинетах принимать коронавирусных с ПЦР тестами положительными на рентген легких, а в соседнем кабинете проводить вакцинацию. Люди рядом в очереди стоят (ну да, куда же без очередей)... Умно, ничего не скажешь. Тем не менее, семейному врачу спасибо, она разделяла прием людей с симптомами и подтвержденным диагнозом от остальных. А что относительно тестов? Делают и делают даже бесплатно, если от семейного врача работающим в государственной поликлинике направление, а если в частной, то никто не принимает в бесплатных лабораториях.

Никаких специальных карет скорой помощи нет, тех которые должны ездить и у симптомных пациентов делать забор на ПЦР тест. Вместо этого люди должны добираться своим ходом в поликлинику и сдавать сами. Стоит ли упоминать, что большинство с симптомами поедет на общественном транспорте? Т.е. на минуточку... Кафе, рестораны и даже магазины торгующие хозтоварами закрыты, даже те что с антисептиками и замерами температуры на выходе, а общественный транспорт без температурного скрининга и антисептиков осмысленно возит симптомных граждан. Мало того, еще и не гоняют людей с масками на рту и открытым носом... Кстати, на вакцинацию я был еще записан с января, но очередь не дошла до сих пор, а судя по скорости вакцинации, то получу ее между 2042 и 2056 годом (так виджет рассказал).

Пол года я уламывал приятеля из Google записать либо подкаст, либо сделать лайвстрим и поговорить о работе в Google предметно. И этот человек ни разу не средний по рынку специалист, а хардкорный инженер с большим опытом, который работал и работает с софтом камер на телефонах, камерах помощи парковки авто, 360 surround view и тп. Я уже обсудил с ним зоны и свои вопросы, но прошу и вас написать что вам интересно узнать или на какие темы поговорить. Пишите прямо в @noTieInIT_bot или @NoTieInITChat. Анонс будет скоро.

Меня очень часто ввязывают в дискуссии относительно QA Automation vs QA Manual. Я однажды работал с командой автоматизаторов (даже 2 попытки были), а потом отказался. У меня свои мысли когда это мешает продукту и бесполезно потраченные деньги. Потому я попросил ребят из QA Guild поучаствовать в лайвшоу, которые занимаются той самой автоматизаций. Вот и будем искать истину на стыке разных мнений. Скоро будет анонс. Открыть/Комментировать

2021-02-17 18:17:00 Чат канала. Поехали!

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

Вместо комментариев будет полноценный чат!

Встречайте, @noTieInITChat.

Велкам в чат! Открыть/Комментировать

2021-02-16 20:16:00 ​​ Так как же экономить на этапе оценки требований?

Люся Сидорова хотела выйти замуж по расчёту... Но не смогла. Она гуманитарий.

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

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

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

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

В моем опыте были объяснения:
- как работает протокол HTTP, WebSocket
- как ведет себя браузер после запроса загрузки страницы и до закрытия табы
- что такое сессия пользователя
- как происходит балансировка нагрузки и почему два запроса подряд на разных серверах могут выполняться
- что за магия с cookies и local storage
- и многое друго...

Почему Вот хочет реализовать постановщик логику работы чатов на WebSocket. В его мире “ДО” нажатие кнопки “отправить сообщение” было неразрывно связано с тем фактом, что сервер получил сообщение в риалтайме и обработал его. Когда объясняешь, что банально в момент отправки соединение может быть не установлено, может быть в процессе реконнекта и тп, то после этого человек уже формирует требования с учетом разных состояний соединения! Когда объясняешь, что у могут быть синхронные и асинхронные запросы, а пока ответ летел клиенту с сервера, то состояние на сервере могло уже поменяться, то качество проработки edge cases и fail-сценариев в требованиях вырастает в разы. Это и создает экономию на этапе написания требований.

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

@noTieInIT Открыть/Комментировать

2021-02-05 20:16:00 ​​ Потери при недоработках планирования. Часть 2.

Факап из прошлого поста не стоил карьеры людей, но переписывать систему пришлось.

На этот раз собрали функциональные и нефункциональные требования и пришли к выводу, что нужно отказаться от монолита на PHP и строить на базе сервисов на асинхронном языке. Специалистов на рынке было больше со знанием Javascript и вопреки моей большой любви к Java я не рискнул с Java NIO стартовать проект: был большой риск не уложиться в сроки и не найти специалистов из-за крайне малого опыта Java разработчиков на нашем рынке с асинхронным IO.

В этот раз с Сашей, TL этого проекта, мы стирали фломастеры об доски не один месяц (actually, 2). К сожалению где-то потерялась фотка нашей проектной документации, которая была засвидетельствована на стопке листов A4, с рукописным текстом и вырезанных и вклеенных куском логики с других листочков. Жаль конечно, выглядело как Франкенштейн или как лоскутное одеяло… кому как угодно)

На выходе получили систему, которая вот уже 4-5 лет в эксплуатации и переживала смену слоев, но не смену общей архитектуры. Decoupling в действии. Мы потратили на первом этапе несколько месяцев на планирование и устранили теоретические проблемы еще на старте, а вот окупилось это с лихвой, ибо выкидывание целых двух слоев приложения (двух сервисов) заняло 1 неделю ударной работы (вот ссылка на эту часть истории из выступления на конфе, fyi).

Конечно, не все так радужно было и столкнулись с другими проблемами, которые были вызваны наличием большого количества сервисов/микросервисов:
оркестрация доставляла неудобства, да и еще доставляет дискомфорт по сей день)
tracing/debugging становится сложным
service mesh на объемах становится большой головной болью!

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

2021-02-04 20:30:01 ​​Service mesh, онлайн–интенсив 19–21 марта

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

Спикер интенсива — Александр Лукьянченко, тимлид в команде архитектуры Авито. Он раскроет механики работы service mesh и поможет подготовиться к внедрению технологии без даунтайма.
Для практики будем использовать проект без service mesh в Kubernetes-кластере. Задача — постепенно внедрить service mesh, отслеживая изменения.

Посмотреть программу на сайте: http://slurm.club/36DXaK8 Открыть/Комментировать

2021-02-03 19:45:00 ​​ Потери при недоработках планирования. Часть 1.

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

Как-то мне достался продукт, который должен был работать с live видео: принимать потоки, транскодировать их в несколько качеств, отдавать пользователям. Одним словом - была работа с realtime. Ответственные лица приняли решение разрабатывать эту часть платформы на базе PHP и успешно полтора года пилили проект. Ну как пилили… Первые 9 месяцев что-то напилили, а остальные 9 месяцев пытались перемотать изолентой весь продукт дабы он не рассыпался. Product Manager хотел двигаться быстрее, перейти к следующим этапам, но все время команды только и выжирал технических долг. Так до меня дошел запрос вмешаться в процесс и разобраться что там творится, принять меры.

После плотной интеграции в продукт, пришли к выводу, что вообще выбран некорректно весь технологический стек и PHP плохо подходит по ряду причин:
Этот язык через пень-колоду поддерживает работу с асинхронностью, а система должна была обслуживать live видео, где множество процессинга и асинхронных событий. PHP обеспечивает меньшую пропускную способность и провоцирует большое количество затрат времени.
Он ориентирован на работу со stateless запросами: запрос поступил, скрипты обработки запустились, запрос выполнился и скрипты умерли. Сохранение состояния потоков между стартом-смертью скриптов возможно лишь посредством постоянной сериализации/десериализации данных и сохранения в базы данных или кэши. Это тоже перетрата.
Запустить процесс другой программы и его контролировать попросту невозможно без запуска сотен процессов, которые еще и блокируются ожидая input/output. Про phpDaemon и т.п. можете не писать, это та еще дрянь если с ней работать плотно.
При выполнении каждого запроса тратится 50-100ms только на бутстратпинг скрипта, ну и фреймворков заодно, если они есть.

После анализа приняли решение переписывать на другом языке.

Какие затраты? Команда из 6-8 человек полтора года двигалась не туда и это $300-400k слитых в унитаз и потеря как конкурентного преимущества за это время, так и потенциальной прибыли.

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

Welcome to real life, bro. Открыть/Комментировать

2021-02-02 20:42:27 ​​ Стоимость ошибки и изменений…

Ошибки любят списывать на разработчиков или QA. Это сделать проще всего. Таким поведение грешат менеджеры, ведь проще всего обьяснить своему же руководству о пофейленном проекте или задаче взвалив это на разработчиков. Нетехническим топам рассказать о том, что “разработчики козлы” проще всего, ведь они не могут вникнуть глубоко в суть и разобраться в проблеме. Можно еще уволить исполнителей и взять новых… чтоб наверняка.

В современной статьях и литературе (в основном про Agile) приводят вот этот график, который очень упрощен и не показывает истинную трагичность. Всего-то выпилили значения по шкалам… Еще продавцы гибких методологий любят продавать историю, что использование XP практик делает “график плоским”, потому чтоб не профакапить, то юзайте XP.

Происходит это за счет уменьшения времени обратной связи на ошибки. Работая по TDD от момента написания кода до понимания что тесты попадали пройдет несколько минут, потому исправить такую ошибку проще. Это действительно правда, писали об этом Кент Бек и Мартин Фаулер, кстати, но это лишь часть правды.

Сегодня восстанавливаю справедливость! К этому посту я приатачил давно забытый график, но он не утратил актуальность даже спустя 40 лет!. Его автор - Barry Boehm и он опубликовал этот график в книге Software Engineering Economics. На этом графике отображены все этапы в разработке: от формулировки бизнес требований до исправлений в продакшне.

Расшифрую суть графика на примере. Если на этапе формирования требований к продукту ошибку в требованиях можно предотвратить и доработать за 1 час, то исправление во время разработки уже будет стоить примерно 10 часов. Если проморгать проблему и код ушел на тестирование, то ее исправление может затянуть на 20-50 часов, а если ошибка уехала в релиз, то и вовсе до 1000 часов!

Еще раз. Исправление ошибки на этапе проектирования в 100-1000 раз ниже, чем после выпуска релиза!

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

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

2020-12-22 18:17:00 ​​ Подкаст! Про найм, про ставки и компетенции, про вопросы на собеседованиях и про флоу собеседований. Что выясняет хороший интервьюер?

Несколько недель назад я пришел в гости на подкаст к замечательным ребятам из QA Guild: Ярославу Пернеровскому и Сергею Пирогову. В ходе беседы прошлись по множеству тем связанных с наймом и знаете… этот выпуск содержит информацию, которая является квинтэссенцией моей философии. Сразу обозначу, что речь про IT, хотя 90% применимо к любой индустрии.

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

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

Подробности? А Вот темы!

Про собеседования
Откуда бабло в продукте
Сколько стоит нанять нового человека?
Почему люди обычно фейлятся?
Ставки vs компетенции
Про перспективы зарплатного перекоса
Челенджи найма в продуктовой компании
Что важно в резюме?
Какие вопросы задают и почему?
Кто виноват?
Влияет ли зп на сложность задаваемых вопросов?
Флоу собеседования
Как культурно объяснить, что нет
Тестовое vs код на гитхабе

Слушать на SoundCloud - https://soundcloud.app.goo.gl/KzFRT

Канал ребят - https://t.me/automation_remarks

P.S. Спойлерну. Так как ребята лидеры мнений QA комьюнити, то договорились о стриме где будем распинать/защищать автоматизацию тестирования и разберем каким компаниям это будет полезно, а какие может просто убить. Открыть/Комментировать