Что такое N-tier application

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

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

Это классический 3-tier architecture. Иными словами, в нашем сервисе есть presentation tier, application tier и data tier.

1️⃣ Мобильное приложение это presentation tier. Это интерфейс, который предназначен для пользователя.

2️⃣ Бэк-энд сервисы, которые помогают мобильному приложению работать это application tier, здесь живет бизнес логика. Повторяю, это не обязательно один монолит, несколько сервисов могут относиться к одному слою.

3️⃣ Базы данных, с которыми работает бэк-энд и которые обеспечивают сохранение данных это data tier.

3-tier architecture не является единственным возможным вариантом архитектуры. Представим, что наше мобильное приложение все запросы шлет через API Gateway, а этот gateway распределяет их по сервисам. Теперь у нас 4-tier architecture.

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

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

Со сколькими слоями сталкивались вы? Пишите в комментариях.

#хардскиллы

Перевел статью про git bisect для Хабра.

Используете такое? Делитесь опытом в комментариях. (и ставьте ⬆️ на Хабре 🙏)

https://habr.com/ru/post/591447/

Что такое Cognitive complexity

Под термином Сognitive complexity (когнитивная сложность) обычно понимают следующее — как сложно постороннему разработчику будет интуитивно понять ваш код.

Мои "любимые" примеры такой сложности, про то время, когда люди стремились к "эффективности" кода и везде. Например, в JavaScript, использовали битовые операции. Они ведь быстрые.

Что делает код 8 >> 1? Делит 8 на 2. Понимал ли я это когда-то без дополнительного гугления? Нет. (Ну только в следующие 3 минуты после предыдущего гугления). Этот код сложный для восприятия. Обычно такой код писать не надо, нужно писать только в том случае, когда вы действительно оптимизируете на производительность.

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

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

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

⬛️ Еще раз — когнитивная сложность это важно, чем ниже она, тем проще работать и поддерживать этот код или CI файл. Когда что-то делаешь, то нужно себя спрашивать — это будет сложно понять постороннему человеку?

Какова когнитивная сложность постов в этом канале? Пишите в комментариях.

#софтскиллы

Что важнее development experience или cost optimisation?

Примерно 4 года назад, я работал над проектом, который включал в одном репозитории бэк-энд и фронт-энд. Бэк-энд был на Node.js, а фронт-энд на React. Причем сервером для React фронт-энда выступало это же Node.js приложение. В итоге все собиралось вместе, запаковывалось в Docker и запускалось на настоящем железном сервере (нескольких, арендованных в OVH).

Чтобы React приложение стало готово к продакшену его надо собрать. Собиралось все на TeamCity, у которого был свой пул воркеров. И вот как-то раз я заметил, что весь процесс сборки и деплоймента занимает целых 20 минут ⏳. Для Node.js + React приложения с легким Docker контейнером это долго.

Я начал смотреть внимательнее и увидел, что сам билд React приложения и Docker контейнера занимают ~15 минут. А у меня на машине, тогдашнем Macbook Pro, это происходило за 5 минут. Почему? Я быстро предположил что дело в жестком диске. У меня был точно SSD, а что было на воркерах TeamCity? Я спросил у наших DevOps — мне ответили, что там HDD.

Окей, причина проблемы обнаружена. Я решил, что это надо исправить. Написал письмо команде наших DevOps. В письме я рассказал, что команда из 8 человек каждый день N раз ждет лишние 10 минут. Обычно более часа в день. И ждет не только наша команда, другие команды тоже ждут, пока собираются их приложения, просто они не жалуются. Очевидно, что если мы заменим диски на воркерах, то наша эффективность увеличится.

Кому-то очевидно, а кому-то нет. Мне пришел пространный ответ, что в целом я прав, но сделать это очень сложно, поэтому давайте лучше этого не делать. Работали ведь раньше и все было хорошо. А еще это будет стоить дороже. Давайте и дальше работать и чтобы все было хорошо 🤝.

Я решил продолжить и пошел с этим же вопросом к инженеринг менеджеру, который был и менеджером DevOps команды. Он мне тоже сказал что идея хорошая, но вот нельзя просто так взять и изменить это. Это будет стоить дороже. Нельзя просто вытащить одни жесткие диски и вставить другие, это надо просить OVH. Или менять серверы на новые. И команда DevOps тоже не виновата, у них есть другие важные задачи.

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

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

Как вы считаете, кто был прав? Пишите в комментариях.

#истории

Про Рождественский календарь для разработчика

В Европе есть традиция Рождественского календаря. Это календарь на первые 24 дня декабря, который "помогает" дождаться Рождества. Обычно что-то с 24 дверками, на каждой написано число от 1 до 24. Каждый день вы открываете одну дверку и там вас ждет сюрприз. Насколько я знаю, в 🇺🇦 и 🇷🇺 такая традиция тоже проникает последние годы.

В общем, что такое календарь ясно, а причем тут Хороший разработчик?

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

Ниже подборка календарей на 2021 год:

⛄️ Advent of Code

Самый известный. У него даже есть свой subreddit. Это календарь для всех разработчиков, технология не важна. Каждый день появляются задачки, вам нужно их решить. Можно соревноваться с другими.

🌲 Java advent

Календарь про JVM технологии. Каждый день новая статья. То что нужно любителям Kotlin или Java.

🎅🏻 bekk christmas

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

❄️ Advent of GraphQL

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

⬛️ Еще раз — можно провести декабрь с пользой.

Знаете еще какие-то хорошие проекты? Пишите в комментариях.

#хардскиллы

Про продуктивные конфликты

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

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

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

Википедия дает следующее определение. Конфликт — ситуация, в которой каждая из сторон занимает позицию, несовместимую и противоположную по отношению к интересам другой стороны.

В этом определении содержится и ключ к возможности получить продуктивный конфликт.

Представим ситуацию. Мы пишем новый сервис, сайт по производству NFT из фотографий комнатных растений 🌵, и думаем, какая база данных бы нас устроила. Собрали митинг и обнаружили, что у нас два лагеря — одни разработчики хотят использовать InfluxDB, а другие AWS Aurora, как в остальных ваших сервисах. Спор идет уже долго и никакая сторона не хочет уступать.

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

Теперь нам понятны интересы сторон. У одной — попробовать что-то новое, у другой — здоровый консерватизм. В итоге на следующем митинге, учитывая интересы сторон, вы предложили использовать AWS Aurora и написать бэк-энд на Go, с этим согласились все разработчики, команда давно хотела попробовать Go в продакшене. Это решение удовлетворило интересы обеих сторон 🤝.

Один из 🗝 к продуктивному конфликту следующий — фокусируйтесь на интересах, а не на позициях сторон.

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

Есть примеры конфликтов, которые удалось решить удовлетворив интересы, а не позиции? Пишите в комментариях.

#софтскиллы

Холм, за который вы готовы умереть

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

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

Однако, люди такие существа, что им, обычно, недостаточно выслушать логические аргументы, чтобы принять решение. В одном подкасте я услышал про исследование, где 100 людям с раком легких сказали, что им надо бросить курить, иначе они умрут ☠️. Казалось бы — логичнее некуда и ставки достаточно высоки. Сколько из них бросило курить? 10%.

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

Многие вещи можно сделать несколькими разными способами. Нужно ли их делать тем, который именно вы считаете самым подходящим? Хороший разработчик должен задать себе вопрос, является ли этот конфликт "холмом, за который вы готовы умереть" ⚔️. Так ли принципиален для вас этот вопрос? Какие преимущества для компании? Какие преимущества для вас? Может лучше отступить и "не портить" отношения с контрагентом?

"Холмов" за которые можно повоевать в любой компании куча, но выбирать такие холмы нужно с умом. Иначе можно устать (выгореть). А Уставший разработчик не может быть Хорошим разработчиком.

Что еще отличает новичка от разработчика который провел в компании годы? Знание контекста. У каждого решения есть контекст. Возможно, ваша идея кажется вам лучшей, только потому, что вы не знаете весь контекст. Но для того чтобы его получить, нужно тоже тратить время и энергию. Нужно ли это именно вам и именно сейчас?

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

#истории

Хочу порекомендовать еще один Telegram-канал.

В течении моей карьеры, где-то между PHP и Java, моей основной платформой была Node.js. И даже сейчас, для своих пет проектов я выбираю Node.js, но теперь с TypeScript ;)

Хотя активно с технологией я сейчас не работаю, но держу руку на пульсе, в этом мне помогает канал Никиты Галкина Node.js recipes. У Никиты более 15 лет опыта, сейчас он работает System Architect и консультирует стартапы, чтобы их бизнес требования опирались на хороший технологический фундамент, где основная бэк-энд технология это Node.js.

В канале много постов про Node.js стэк. Не только сугубо технические, как Топ 10 ошибок в Nest.js проектах, но и в целом, про экосистему Как технологии будут востребованы для Node.js разработки в 2022?. Еще Никита пишет про личный опыт — Топ 3 моих покупки за последние годы.

Подписывайтесь на Node.js recipes и ❤️ Node.js.

Про классификацию информации

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

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

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

В целом, можно выделить три категории.

1️⃣ Restricted data. Если эти данные утекут, то это может оказать вред нашим пользователям. Сюда обычно так же включают Personally Identifiable Information (PII), все, что позволяет связать нашего пользователя с реальным человеком.

2️⃣ Private data. Данные, утечка которых, может помочь злоумышленнику, получить доступ к Restricted data. Например, если у хакера есть e-mail пользователя, то он может послать тому фишинговое письмо, и получить доступ в аккаунт пользователя.

3️⃣ Public data. Эти данные могут быть доступны всем и требуют минимальной защиты. Например — рейтинги или обзоры, которые оставлял пользователь.

Категорий может быть больше. В зависимости от категории, мы можем решить как хранить данные (например, нужно ли их перед сохранением в бд шифровать?) и кто к ним должен иметь доступ (например, должны ли все сотрудники компании иметь доступ к данным пользователя?).

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

⬛️ Еще раз — данные нужно защищать. Чтобы понять, что нужно защищать больше, данные нужно категоризировать. Restricted data нужно защищать лучше всего — шифровать, выдавать доступ к ней только тем, кому он действительно нужен.

Ваши данные когда-нибудь утекали? Кстати, это можно проверить здесь. Мой e-mail утек уже 10 раз. Пишите в комментариях.

#хардскиллы

Вакансия

Мы в SHARE NOW ищем нового разработчика в команду, где я работаю. SHARE NOW это самый большой каршеринг в Европе, мы присутствуем в восьми странах. Наша команда отвечает за процессы, которые происходят с пользователем до того, как он может начать водить машину. А именно - валидация прав, GDPR, применение промо кодов. Но это не все, еще отвечаем, например, за программу лояльности. Используем Java/Kotlin, немного Node.js. Нас 9 человек (PO, QA, 4xBE, 1xFE, Chapter Lead).

Ищем крепкого Middle разработчика с фокусом на back-end и Java/Kotlin.

Из интересного:
* Перевозим в 🇩🇪 Германию. Можно в Гамбург или Берлин
* Если вы уже в Европе, то можно работать из Германии или Испании
* Пока оформляются бумаги, можно начать работать из вашей текущей страны (легально)
* Даем 100€ в месяц на наш каршеринг
* Development budget, курсы немецкого
* Отпуск 30 рабочих дней
* Офис около Эльбы в Гамбурге, мимо проплывают дорогие 🛥, например эта


Подписка на Хороший разработчик знает это плюс 🙃

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

Что такое RACI матрица

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

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

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

Представим, что мы делаем сложный проект — мигрируем микросервисную архитектуру в AWS. У нас десяток сервисов, пять баз данных, огромный RabbitMQ кластер, его хорошо бы разбить. Этим занимаются три команды и пятнадцать разработчиков.

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

Доступно четыре кода:

R (Responsible) — значит что человек выполняет задачу. Например, перенастраивает микросервисы, чтобы они работали с новым RabbitMQ.

A (Accountable) — человек, который отвечает за результат, у каждого процесса может быть только один такой человек, именно он может принять финальное решение. Например, решить, что теперь мы будем использовать много отдельных брокеров RabbitMQ.

C (Consulted) — люди с которыми нужно проконсультироваться, во время выполнения задачи. Например, разработчики одной из команд, которые используют легаси RabbitMQ кластер.

I (Informed) — сотрудники, которых нужно информировать о выполнении задачи. Например, держать всех разработчиков в курсе прогресса о миграции на новых брокеров.

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

⬛️ Еще раз — RACI матрица позволяет наглядно записать кто за что ответственен. Когда мы, вместе, формализируем и записываем ожидания мы достигаем нескольких целей — теперь понятно кто чем занимается; люди понимают, что они лично ответственны за определенные задачи. Групповой ответственности не бывает.

Были ситуации, когда не было понятно кто должен принять решение? Как они разрешились? Пишите в комментариях.
⁠
#софтскиллы

Про онлайн тренинги

На прошлой неделе со среды по пятницу я участвовал в онлайн тренинге по Kotlin и хочу поделиться своими впечатлениями.

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

Наш тренинг должен был ознакомить разработчика с Kotlin best practices. Как это выглядело:
* Лектор рассказывает и показывает какой-то рандомный топик про Kotlin
* Основное взаимодействие с аудиторией это вопрос — все понятно? Если не понятно, то спрашивайте
* Теория разбавлена заданиями на самостоятельное выполнение
* Перерыв
* Поехали дальше, новый рандомный топик

Моей основной проблемой было удержание фокуса. Для меня это оказалось невозможным. Я не могу просто сидеть и смотреть интересное видео про Kotlin 8 часов в день, даже с перерывами. Мой attention gap намного меньше.

Что можно было улучшить, на мой взгляд:
1️⃣ У тренинга должна быть история, какая-то общая легенда, которая пронизывает все топики
2️⃣ Взаимодействие с аудиторией должно быть интерактивным. У нас было пару моментов, когда мы голосовали, но мы голосовали по темам "Перерыв должен быть сейчас или позже?" 🙃 Так легче быть вовлеченным
3️⃣ Задания нужно выполнять в парах, тогда будет сложнее поддаться соблазну их просто пропустить
4️⃣ Мы начали сразу со сложной темы — Thread safety. Зачем? Логики в этом не было никакой. Потом были менее сложные темы. Сначала надо дать участникам ощущение прогресса, чтобы они поверили в свои силы.
5️⃣ Никакого преимущества, в том, что мы проводим три дня подряд на этом тренинге, нет. Такие курсы лучше проходить медленнее и за более продолжительный срок.

Были и положительные моменты — я услышал о топиках, про которые хочется узнать больше: Offensive programming, Mutation testing, Sequences.

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

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

Вы проходили какие-то классные тренинги онлайн? Напишите о них в комментариях.

#истории

Write-ahead logging

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

А что будет, если RabbitMQ будет недоступен в этот момент и сообщение не отправиться ☠️? Можно добавить какой-то retry, можно вообще откатить транзакцию и ответить 500. Можно "потерять" это сообщение, таких случаев ожидается мало, но лучше не "терять", ведь тогда может нарушиться цельность данных в нашей информационной системе.

Есть другое решение — использовать технику write-ahead log. В таком случае, отправка сообщения будет, грубо говоря, состоять из трех шагов:

1. Записываем что нужно отправить в базу данных, в табличку events, ставим статус PENDING
2. Какой-то worker периодически проверяет эту табличку и отправляет сообщения со статусом PENDING
3. Если сообщение отправилось, ставим ему статус SENT
4. Бонус. Время от времени удаляем строки у которых статус SENT

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

Эта же техника используется движками баз данных для обеспечения atomicity и durability из ACID. Только базы данных записывают информацию в файл, а потом в саму базу данных.

⬛️ Еще раз — если вы хотите быть уверенными, что действие будет выполнено, используйте технику write-ahead log. Это делает программу сложнее, но стабильнее.

Реализовывали такое сами? Пишите в комментариях
⁠
#хардскиллы

Техника Pomodoro

Прокрастинация. Мы все страдаем от этого, правда? Я точно да. Думаю каждый Хороший разработчик, иногда, страдает от этого. Нужно сделать столько всего, и это все вроде бы так важно, что не знаешь с чего начать и как к этому подступиться. Поэтому жмешь Cmd + R и проверяешь есть ли что новое на Медузе.

К счастью, наш мозг, можно легко обмануть. И убедить его, что напрягаться придется недолго. С этим помогает техника Pomodoro timer. Название пошло от кухонного таймера

Она простая, уверен, что многие о ней уже слышали:

1. Составьте список задач, над которыми вам надо работать
2. Заведите таймер на 25 минут, в течении этого времени НИ НА ЧТО не отвлекайтесь. Выключите мессенджеры. Работайте над задачей.
3. Поработали? Отдохните пять минут. Можно читать Facebook.
4. Еще раз пункт два. Завели таймер и работаем. Один такой интервал называется — помидорка.
5. После четырех помидорок можно сделать большой перерыв, например 20 минут.

Это точно работает, я проверял. Согласиться поработать 25 минут намного проще, чем согласиться с абстрактным "сделать задачу".

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

Я использую программу Be Focused - Focus Timer на Mac, все еще на бесплатной версии. Ссылка в комментариях. Мне очень помогает тиканье часов + я включаю белый шум в Spotify.

⬛️ Еще раз — если сложно начать работать над задачей, то проще согласиться поработать над ней только 25 минут, а потом вознаградить себя заслуженным отдыхом.

Уже использовали эту технику? Если использовали, напишите, пожалуйста, в комментариях свое любимое приложение.
⁠
#софтскиллы

👋,

Я решил расширить "Хороший разработчик знает" еще одним каналом и завел Instagram-аккаунт.

Планы такие:
1. В Telegram я продолжу писать контент посложнее и подлиннее
2. В Instagram можно больше и чаще показывать, меньше писать
3. Некоторые темы, которые уже встречались здесь, буду пересказывать там, используя другие средства
4. Еще там я буду рассказывать и показывать личное, то что мне интересно — работа, жизнь в 🇩🇪Германии, архитектура Гамбурга, моя жизнь
5. В будущем, я планирую там продавать, но это в будущем. И это будет win-win.

Сейчас там уже теплится первый пост и игра "две правды одна ложь". А вечером расскажу рецепт традиционного немецкого Рождественского напитка 🍹. Кулинарный разработчик, получается.

Подписывайтесь: https://www.instagram.com/gooddevknows/ , будет интересно и про IT.

История о том, как я не получил промоушен

Как-то раз, работал я в компании. Я работал там уже три года и был Хорошим разработчиком (со скидкой). А по должности назывался Expert Software Engineer, потому, что в этой компании так называли Senior.

Выше Expert в иерархии стоял Head. По факту, люди с тайтлом Head лидили команду. Занимались менеджментом и техническим лидерством. Я тоже хотел быть Head. Чтобы расти и денег 💸 больше.

Компания планировала выход на новый рынок (🇲🇽) и нужно было адаптировать продукт под этот рынок. То есть подкрутить фронт-энд, подкрутить бэк-энд, поинтегрироваться с другими командами и связать все это вместе. Закрутилось все это без меня. Но пошло не так активно как планировалось, поэтому, в рамках оптимизации курса, возникла идея привлечь меня, чтобы я этот процесс лидировал.

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

По результатам перформанс ревью, меня похлопали по плечу, сказали что я ух как хорошо работаю и это ух как помогает компании. Компенсация немного повысилась. А Head дадут? Спросил я. Мне ответили, что, согласно бюрократическим особенностям нашей компании, “ух как работать” нужно 12 месяцев подряд, чтобы рассчитывать на промоушен.

Окей, я прикусил губу и решил работать еще и подождать, что будет через 6 месяцев. В следующие полгода мне выпала другая команда, которую я тоже лидировал. И другая задача. Перспективная, но менее приоритетная, а к концу полугода уже и неактуальная. Хотя я и команда работали хорошо, но мои заслуги оценили как “хорошо”, а не “ух как хорошо”. Перспективы Head особо не обсуждались. На мой вопрос “почему я делаю тоже что и другие Head, но еще не Head?” мне ответили что-то вроде “сейчас нет необходимости в новом Head".

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

Давайте рассмотрим мои ошибки:
1. Изначально, у себя в голове, я нарисовал какой-то “справедливый” план — работай хорошо, это увидят, тебя по заслугам повысят
2. Я не обсудил этот план с моим менеджером. Я подумал, что он тоже придерживается такого плана
3. Похоже, что моему менеджеру просто было удобно закрыть мной проблему. А о моей “проблеме” ему первые 6 месяцев вообще не было известно.

А вот и вывод — Хороший разработчик не надеется на “справедливость”. Справедливость для него, для его менеджера, для его коллег может быть очень разной, это субъективная оценка. Хороший разработчик проговаривает ожидания, а лучше их прописывает. Необязательно прописывать как контракт, можно просто как e-mail с саммари встречи. Тогда результат можно будет оценить объективно.

Попадали в похожие ситуации? Рассказывайте в комментариях.

#истории

А еще я завел 🌄Instagram, подписывайтесь 🤝

👋, еще одно объявление.

Если вы с каналом давно, то может быть помните, что я ставил цель собрать здесь 2000 подписчиков до Нового Года. Тогда нас было где-то 500. И я только примерно представлял, как я этого буду добиваться. Но вот еще 21-е декабря, а нас уже ~2350.

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

Теперь нужно ставить новые цели. Теперь моя цель сделать "Хороший разработчик знает" sustainable. Я хочу продолжать писать по 3 поста в неделю и еще вести Instagram (там, кстати, вышел новый пост). Что нужно Хорошему разработчику, чтобы продолжать делать то, что он делает? Знать, что то, что он делает, кому-то нужно.

Я запускаю программу поддержки, т.е. Patreon. По ссылке, вы можете стать моим патроном и получить что-то взамен.

Это подойдет вам если:
1. Вам нравится то, что я делаю и вы хотите участвовать
2. Вам нужна моя помощь
3. Вы хотите открытку 🎁

По ссылке https://www.patreon.com/PavloPoliakov, вы можете почитать больше про бонусы. Плюс вас уже ждут два публичных текста. Почитайте.

Спасибо, за то что здесь 🤗

Про RPO и RTO

Поговорим еще раз про даунтаймы, а именно, про восстановление работы после них. Записывайте себе в конспект, это будет на экзамене (ну если будете сдавать AWS Solution Architect).

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

Когда мы планируем reliability и availability нашего решения, мы хотим, чтобы наш сервис восстанавливался быстро и без потери информации. Чтобы формализовать эти требования, мы можем определить два параметра — RTO (Recovery Time Objective) и RPO (Recovery Point Objective).

RTO. Сколько времени максимально, наше решение должно восстанавливаться после инцидента. Например, ⚡️ ударила прямо в наш сервер, через сколько времени наш сервис должен опять работать и работать нормально? Этот параметр поможет нам определиться с availability стратегией.
Если для восстановления работы нам нужно заказать и настроить новый сервер, то на это может уйти день. А если у нас всегда параллельно работает такой же сервер, и нам нужно только переключить трафик — то минуты.

RPO. Потерю какого количества актуальной информации может “стерпеть” компания? Измеряется во времени. Например, 🦡 перегрыз провода, произошло замыкание и сгорел HD. Данные за последние два часа нельзя восстановить. Это приемлимо? Зная RPO можно определиться со стратегией резервного копирования.

Определение RTO и RPO это бизнес задача, в которой учитывается пользовательский опыт, возможные финансовые потери от даунтайма, репутационные потери. А вот реализация этих требований, это уже задача Хорошего разработчика. Очевидно, что чем строже требования, тем дороже будут ежедневные траты на поддержку этих требований 💸.

⬛️ Еще раз — Хороший разработчик готов к тому, что все сломается. На этот случай у него есть стратегия. Хорошо, когда эта стратегия подготовлена на основе бизнес требований, которые формализованы в RTO и RPO.

У вас в команде определены эти параметры? Пишите в комментариях.

#хардскиллы, 🌄Instagram |🤝Patreon

Про unknown unknown

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

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

Known known. Мы это твердо знаем и мы знаем, что мы это знаем. Например, мы проектируем REST сервис, который реализует HTTP методы. Мы их все знаем. Существование метода THANOS, о котором мы не догадываемся, стремится к нулю.

Known unknown. Мы знаем что информация существует, если нужно, то мы ее найдем и изучим. Например, как развернуть Rust приложение на Microsoft Azure? Сейчас мы не знаем, но если надо, то узнаем и сделаем.

Unknown known. Мы не знаем эту информацию, но, возможно, ее знают люди которые нас окружают. А мы понимаем, что такое может иметь место. Например, мы хотим развернуть Rust на Microsoft Azure, собираем митинг чтобы провалидировать нашу стратегию. А там опытный Rust разработчик говорит — меньше 64Gb памяти сервер не берите, иначе сборщик мусора взорвет сервер. (это я придумал, если что)

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

Ну а если на примере для разработчиков, то мы все еще разворачиваем Rust на Microsoft Azure, но бухгалтерия не может оплатить счет, потому что ваш главный инвестор оказался замешан в коррупционном скандале и теперь все активы заморожены 🤷‍♂️.

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

⬛️ Еще раз — как бы мы хорошо не готовились, всегда останется unknown unknown, это нужно принять. А если unknown unknown настал, не стоит расстраиваться и корить себя, нужно просто сделать выводы, а в следующий раз сократить количество возможных unknown unknown.

Сталкивались с unknown unknown? Пишите примеры в комментариях.

#софтскиллы, 🌄Instagram |🤝Patreon

Пришла последняя неделя года, время подводить итоги и строить планы. Я придумал, что хорошо было бы написать пост о том, чему я научился в 2021. Но я быстро понял, что лучше я перечислю то, что учило меня в 2021.

В этом году я проходил курсы и читал книги. Вот что это было.

Книги

1️⃣ Искусство объяснять. Мне кажется я и раньше неплохо объяснял и делал презентации. Но эта книга не была лишней. Она дает определению слову “объяснение”, основной цели этого процесса (сделать информацию “дешевле” для слушателя). Дальше рассматривается универсальная структура хорошего объяснения. Уверен, что этого навыка не хватает многим разработчикам.

2️⃣ Solution’s Architect’s Handbook.... В этой книге нет ничего уникального, более того, есть логические ошибки в тексте, которые искажают смысл сказанного. Но это хорошая компиляция прямо всего, что относится к теме Solution Architect. Рад, что прочитал.

3️⃣ Пиши, сокращай. Книга в которой методично объясняется, что основная цель текста это — быть полезным читателю. Конечно, рассматриваются и инструменты, с помощью которых этого можно достичь. Помогает мне писать посты в канал. Рекомендую.

4️⃣ Developing Coaching Skills: A Concise Introduction. Я ничего не знал о коучинге, кроме того что есть коучи и это “модно”. Эта небольшая книжка рассказывает что такое коучинг, почему он работает, освещает базовые коучинг фреймворки. Полезно, все это можно применять и с собой, без всяких коучей. А можно так общаться с людьми и помогать им решать проблемы, при этом не будучи экспертом в их предметной области. Мне понравилось.

5️⃣ Leading Great Meetings.... До этого года мне было не комфортно вести митинги. Я это делал и не избегал, но это вызывало у меня стресс. Благодаря этой книге я структурировал свои представления о митингах, узнал о конкретных инструментах, которые помогают достигать результатов.

6️⃣ Переговоры без поражения. Гарвардский метод. Рассказывают, что любые переговоры вести несложно. Метод состоит всего из четырех пунктов. Никакого секретного соуса, все основано на “справедливости”. Было полезно + подтвердило собственные убеждения.

Курсы

1️⃣ AWS Cloud Services and Infrastructure - Cost Optimization Deep Dive. Компиляция информации о том, как заниматься Cost Optimization с AWS. Много информации уже встречалось при подготовке к AWS Solution Architect сертификации. Но есть и новое. Полезно.

2️⃣ Kubernetes Deep Dive. Стал больше понимать k8s, то как он работает и как развивается. Стало проще общаться с platform командой и следить за нашим “доменным” кластером.

3️⃣ The Diamond of Participatory Decision-Making. Короткий “курс” который открыл мне глаза. Это нормально, когда на митинге происходит “не конструктивная” фаза, а тебе кажется что это ничем хорошим не кончится. Для “сложных” митингов это нормально, это просто часть процесса.

Еще я слушал книги и подкасты, смотрел youtube и читал Telegram-каналы, но про это в другой раз.

А что классного прошли или прочли вы в 2021? Поделитесь, нам всем надо составлять список на 2022.

#истории, 🌄Instagram |🤝Patreon