Уже завтра все онлайн школы:
Стань экспертом в информационной безопасности за 3 месяца! Востребованная профессия, стабильная оплата. Гарантия трудоустройства.

https://t.me/rbc_news/48383

Два года назад снял немного противоречивое видео. Возможно сейчас оно будет чуть более актуально.

https://youtu.be/tcU-NGhkoCE

Готовы чат открыть?
👍 👎

Используйте код на скидку FLY10 ☝️

Интервью, которое мы записали еще 23 февраля. Поговорили про SAP и ABAP, про то, как делают облака и про проблемы кубернетис кластеров.

https://youtu.be/DQU90HRwA_g

Хей 👋

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

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

— А вот это же только те, кто из бывшего так косячат?

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

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

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

Буду рад, если курс окажется вам полезным. В любом случае, больше надоедать я не планирую. Разве что за день до старта еще напомню. Старт 26 мая.

https://education.borshev.com/relocate + код FLY10 на скидку 10%, которая работает до 16 мая.

Rutube, похоже, таки реанимировали. Не то чтобы он кому-то был нужен, но как инженерная проблема очень интересно, как ее решали. Если у вас есть есть контакты внутри — я с удовольствием бы сделал интервью или выпуск на эту тему.

seniorsoftwarevlogger@gmail.com

Разработчик пришел с проблемой

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

На прошлой неделе сбой повторился как раз в тот момент, когда Лешка был на дежустве. Пришлось опять (прописью: опять) чинить руками. Пейждер звонил не переставая. Леха расстроился, что ошибка же была найдена. Можно было починить и этого бы не произошло. Как научиться объяснять менеджеру, что некоторые вещи не стоит откладывать. Главное: как самому понять, какие вещи не стоит откладывать?

Начнем с причины. Почему менеджер отказал? Это, кстати, был не я. Я просто люблю коучить людей. Менеджер отказал основываясь на многолетнем опыте и довольно глубоких технических знаниях. Грубо говоря — интуиция. Когда встречаются 2 интуиции, то побеждает авторитет. Чего не было у Алексея? У Алексея не было авторитета и данных.

Какие данные в такой ситуации можно собрать, как оценить вероятность повторения сценария? Раньше такого ведь не было.

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

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

Если зайти дальше, то как спрогнозировать вероятность повторения? Тут можно немного запариться и построить модель Монте-Карло, например. Взять предыдущие всплески нагрузки от разных клиентов и прикинуть насколько вероятно, что нагрузки перехлестнутся пробив уровень стабильного обслуживания.

Выписать все на 1 страничку с графиком и идти к менеджеру. Интуиция хороша, когда надо быстро принимать решения. Когда уже все починили и есть время подумать — нужно собирать данные и работать исходя из них.

Смотрю онлайн https://highload.ru/foundation/2022 по билету, который мне предоставили. В комментариях — мои комментарии.

Выбор инструментов

Недавно у меня горело с админки на реакте. Задача добавить 2 круда под готовые АПИ. Я понимаю, что с какой-нибудь Джанго я бы это сделал 2 раза за время координационного звонка. Но когда у тебя админка на реакте - уложиться в 15 минут уже не получится. С той же Джангой бэкенщик бы просто добавил нужное прямо вместе с АПИ. А так придется потратить спринт фронтенд разработчика. Значит, что скорее всего никто никогда это делать не будет.

В итоге делать конечно будем, но для этого пришлось поговорить с людьми. Кто вообще придумал, что реакт ускоряет разработку?

Максимы (tenets) - это линтер для решений команды

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

Но зачем спорить если можно не спорить?

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

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

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

С такой максимой побеждает первый программист. Гораздо проще увеличить максимальный размер топика в Кафке, чем искать все затыки в коде.

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

В таком случае победил бы второй программист.

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

Это как ревью пул реквестов в программировании
Или почему я раньше этого не сделал.

Я всегда готовил все свои выпуски сам. Сначала записывал все видео экспромтом. Потом стал писать тексты и читать с суфлера. Сейчас материал мне помогает готовить Марьяна.

Я пишу текст, который уже нельзя улучшить. Отправляю Марьяне. Получаю пачку комментариев и предложений, где что можно улучшить. Сажусь и переписываю, а как быть? И получается на порядок лучше, чем было. Структура выравнивается, вода высушивается. Примеры добавляются.

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

Я сейчас реально думаю найти редактора, чтобы так писать все видео для канала, как мы готовим курс. В таком режиме я написал уже 4 урока из 7 для курса про работу за рубежом. Оказывается это делается именно так. Важно до старта записать как минимум половину всего контента. Осталось дописать еще 3 урока.

Именно поэтому разные курсы часто проваливаются. Набирают народ, а материал дописать не успевают. Было тут пара скандалов. Я же себе даже отпуск взял, чтобы все точно дописать.

Вот темы уроков:
✅ Урок 1. Проверка цели. Подойдёт ли мне работа за рубежом? Что 100% понадобится сделать ещё до курса. Начнём практиковать на кошках.
✅ Урок 2. Типы компаний, как выбрать свою. Где искать вакансии. Где лучше работать.
✅ Урок 3. Оценка job offer. Что примерно предлагают разные компании и за что можно торговаться.
✅ Урок 4. Подготовка профиля в линкедине, сопроводительное письмо.
⏳ Урок 5. Оценка вакансии и адаптация резюме под конкретную компанию.
⏳ Урок 6. Технические и поведенческие собеседования. Что учесть, как презентовать себя.
⏳ Урок 7. Как не закрыть доступ в компанию мечты. О чём спросить потенциального работодателя.

А еще будут домашки, мок интервью и дополнительное чтиво от Феди Борщева.

Старт 26 мая.

Наконец-то скоро будут видны самые горячие моменты интервью.

Программист с пустым гитхабом

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

Были и другие истории.

История первая. Друг нанимал человека к себе в команду. Кандидат был просто суперзвездой. Твиттер, пет проекты, активный гитхаб. На собеседовании человек провалил вообще все. Команда была в полной фрустрации. Сидя на дебрифе после интервью они сошлись во мнении, что со стороны выглядят, как конченные идиоты. Как можно не нанять такого крутого программиста? Они решили не нанимать доверяя процессу интервью, который собрал их всех в одной команде. False Negative? Возможно.

История вторая. Человек с очень активным и социально полезным пет проектом. Профиль на гитхабе оформлен. Есть сайт портфолио на последних писках веб технологий. Человек не находит мотивацию прорубаться через легаси на проекте. Его вклад в приватные репозитории на гитхабе взлетает после устройства на работу. Вопрос: чем занимается человек на работе? Рабочая этика? На вопрос нет ответа.

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

Меня теперь наоборот настораживают активные гитхабы и сайты портфолио. На собеседованиях я не говорю о пет проектах ни слова. Только о реальном рабочем опыте.

Where wizards stay up late

Отличная книга про историю создания интернета с точки зрения физической инфраструктуры. Как люди создали первый маршрутизатор. Как решали вопрос стабильности его работы. Как соединяли разнородные сети в одну сеть. Как изобрели первый протокол и почему решили использовать термин "протокол". Про войну OSI против TCP/IP. Про электронную почту и другие основные технологии.

Я открыл бусти (название такое себе, конечно). Через бусти можно получить доступ к чатику в котором меня чуть больше, но в котором не все выдерживают 😬 мы уважаем тех, кто ушел, и рады тем, кто в итоге возвращается. Ну и ежемесячные стримы, куда же без них.

Ну или просто, если по какой-то причине вы благодарны за весь бесплатный контент, который я делаю с 2014.

https://boosty.to/seniorsoftwarevlogger

Стань координатором

Или как люди становятся "архитекторами".

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

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

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

Самое простое, что можно сделать - собрать людей вокруг одной проблемы.

Вы прочитали это видео первыми в телеграме, потому что вы — красавчики :)

https://youtu.be/yNZKZhjg-SY

Я буду ботом

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

Есть решение попроще — регистрируешься на make.com 💰, собираешь логику из конструктора — готово. Тут бывают проблемы с доступами к внутренним ресурсам компании и политикой безопасности.

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

Стань ботом на месяц.

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

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

— Эй, Дима, что если результат нужен не раз в день, а по запросу?

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

Иногда, кстати, оказывается дешевле остаться ботом.

Живой пример.
Раз в месяц я делаю отчет. Это занимает минуты 3. Ну хорошо, 10. Даже если на автоматизацию потребуется 4 часа программиста, а потребуется день, то это окупится только через 2 года. Я никогда не поставлю эту задачу в спринт, я не идиот.

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

Чтобы проще считать ROI на xkcd есть таблица автоматизатора. Она рассчитана на 5 лет — и это очень долго. Вы либо уволитесь, либо 100 раз все перепишите, либо оно станет не нужно. Рассчитывайте исходя из 1-2 лет максимум. Тем не менее даже эта таблица отрезвляет автоматизатора.

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