Истории и личный опыт. Как полюбить Agile.

Многие разработчики не любят Agile и Agile ритуалы 🧙‍♂️. Такие разработчики говорят — зачем нужны все эти аджайл коучи, стендапы, ретроспективы, планнинги, джиры? Давайте просто работать! Хорошо делай — хорошо будет.

Я тоже был таким. Я думал — зачем тратить время на бесконечные митинги? Зачем компания платит всяким аджайл коучам, которые делают не настоящую работу, а играют с нами в игры. То мы рисуем ⛵️ и выясняем что есть ветер, а что якорь. То мы рассказываем какое мы сегодня животное 🐘. Разве это помогает мне писать код? Разве это работает?

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

Мы знаем, что можно писать код в vim, а можно его писать в IntelliJ IDEA. Я уверен, что есть разработчики, которые эффективны в vim, но большинство работает эффективнее если использует IDE. Мы используем IDE потому, что нам с ним проще работать в долгосрочном периоде. Так и аджайл и аджайл практики — они нужны, чтобы сделать большинство команд более эффективными.

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

Есть еще хорошие новости — аджайл можно подстроить под команду, если что-то не нравится, то можно это продуктивно обсудить и изменить. Agile это просто инструмент и им надо учиться пользоваться.

А вы как, какое вы сегодня животное? Пишите в комментариях.

#истории

Архитектурные ограничения

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

Давайте представим, что мы работаем на аутсорсе, команде дали новый проект — пишем API для трекинга радуг 🌈. Новый проект - новые возможности. Решили попробовать Go, накидали архитектуру, подобрали библиотеки. Потом пошли с этим к заказчику, а он говорит — Go нельзя, нужно чтобы Node.js стек был, у нас тут все на Node.js.

В итоге мы зря потратили время, и, возможно, потеряли мотивацию. Если бы мы знали и записали, что у нас есть технологическое ограничение использовать Node.js стек, тогда мы бы и не предлагали Go. Но, возможно, подумали бы про TypeScript.

Большинство ограничений можно условно разделить на такие группы:

Cost
- Какой бюджет запланирован для нашего решения?

Quality
- Насколько точно решение должно соответствовать функциональным требованиям? Может какие-то не критичны?

Time
- Когда решение должно быть готово?

Scope
- Если мы найдем пробелы в требованиях, как будем их устранять?

Technology
- Какие технологии можно использовать? Какие точно нельзя использовать?

Risk
- Что может пойти не так и как мы будем с этим справляться?

Resource
- Какие ресурсы необходимы, чтобы реализовать наш план? Например, доступы к API.

Compliance
- Каким международным и локальным законам должно соответствовать наше решение?

Для каждого типа ограничений можно придумать несколько вопросов. Те что представлены выше это лишь примеры.

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

Какие еще ограничения, которые я не упомянул, приходят в голову? Пишите в комментариях.

#хадрскиллы

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

Сегодня статья про полезные npx команды.

https://tproger.ru/articles/7-npx-komand-kotorye-pomogajut-pri-razrabotke/

Как давать обратную связь

Обратная связь это супер. Хороший разработчик хочет получать обратную связь регулярно. Так можно понять делает ли он(а) свою работу хорошо и что можно улучшить.

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

Как дать адекватный фидбэк:

1️⃣ Подготовьтесь заранее. Лучше уведомить человека, что вы хотите провести такой митинг, чтобы он тоже подготовился.
2️⃣ Обратную связь нужно давать вовремя. Не прямо через 15 минут после события. Но лучше не ориентироваться на события последних 3-х месяцев.
3️⃣ Вы оцениваете не человека, а его дела. Вы не знаете его мотивацию.
4️⃣ Ваша оценка субъективна, возможно другие оценивают те же дела по другому. Расскажите о вашем восприятии.
5️⃣ Когда вы за что-то хвалите, это укрепляет модель поведения. Человеку будет легче ее повторить. С критикой эффект обратный.
6️⃣ При конструктивном фидбэке используйте технику бутерброда (знаете другое название этой техники? 😉). Сначала хорошее, потом критика, потом хорошее. Это просто и это работает.

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

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

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

Любите получать фидбэк? Пишите в комментариях.

#софтскиллы

Истории и чужой опыт 🎃

Вчера был Halloween, поэтому сегодня три короткие страшные истории. Перед сном лучше не читать. Готовы?

1️⃣ Как-то давно, мы искали нового фронт-энд разработчика. В те далекие времена тестовое задание кандидат делал в офисе. Утром пришел кандидат, мы дали ему задание, все было в порядке, он сидел и работал. Пришло время обеда, по плану мы обедали вместе с командой. Кандидат сказал, что ему нужно позвонить и вышел... Больше его мы не видели, на звонки он не отвечал.
Когда мы заглянули в код, то что мы увидели шокировало нас! то увидели вялые попытки решить тестовое задание. Съели ли кандидата оборотни 🐺, когда он вышел позвонить? Не факт.

2️⃣ Когда-то давно я еще не был Хорошим разработчиком. Тогда я работал с магазинами на Magento. И вот во время оформления покупки, там был какой-то баг. PHP ошибки сыпались в браузер. Как Плохой разработчик, я, в то время, хотел не найти причину бага, а убрать его симптомы. Я загуглил и нашел что-то на Stack Overflow и применил это. Ошибки пропали. Я делал это и дальше, в других магазинах. Наверное где-то магазинов пять стерпели мое "лекарство".

Только по прошествии лет я понял, что я убирал тот баг просто комментированием куска кода, который выводил ошибки. Что от этого ломалось я не знаю, но товары вроде купить было можно. Я породил десяток франкенштейнов 🧟‍♂️, надеюсь сейчас они все мертвы. Сейчас я уже Хороший разработчик.

3️⃣ Когда-то нам зарепортили баг на продакшене, я начал разбираться и достаточно быстро понял что не работает. Я удивился, ведь мне казалось что этот кусок покрыт тестами. Оказалось, что мой коллега с не джуниор тайтлом делал рефакторинг, он увидел что тест начал падать и...отключил этот тест ❌. Потом, довольный, со всеми зелеными тестами ✅ задеплоил на продакшен.

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

Какие у вас были страшные истории? Расскажите в комментариях.

#истории

Что такое Technology Radar от ThoughtWorks

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

Ответить на эти вопросы поможет Technology Radar📡. Большая консалтинговая компания ThoughtWorks регулярно, примерно раз в полгода, выпускает документ, где субъективно рассказывает о положении на рынке технологий. Эта информация, помимо текста, отображается в виде радара.

На радаре четыре секции (описания условны):

1️⃣ Techniques. Техники, которые могут использоваться при разработке. Например, Four Key Metrics.

2️⃣ Tools. Инструменты, которые используются при разработке. Например, JavaScript сборщик Vite.

3️⃣ Platforms. Инфраструктурные компоненты или сервисы. Например, Backstage.

4️⃣ Language & Frameworks. Все про уровень языков программирования и вытекающих из них особенностей. Например, React Hooks.

В каждой секции вещи, о которых говориться, расположены в четырех категориях:

1️⃣ Hold. Придержать использование или наоборот, пора отказываться от этой технологии.

2️⃣ Assess. Стоит понаблюдать за технологией.

3️⃣ Trial. Стоит пощупать руками и сделать выводы.

4️⃣ Adopt. Можно смело внедрять.

Таким образом, изучая Техрадар, можно быстро узнать, что нового, о чем стоит знать, появилось, а что старое уже отживает свое. Например, если React Hooks находится в Adopt, то в новом проекте на React точно не нужно использовать классы и lifecycle методы.

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

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

На что вы ориентируетесь при выборе технологий? Пишите в комментариях.

#хардскиллы

Написал немного более развенуто про Техрадар, включил обзор интересных находок.

Поддержите апвоутом плз 🤗

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

Что влияет на продуктивность разработчика

Многие люди вне IT думают, что лучше работают те разработчики, которые получают большую компенсацию 💰. Так, наверное, думают и некоторые люди в IT. Но я уверен, что Хороший разработчик понимает, что это не так.

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

В IT только и приходится что думать. Тогда как обеспечить хорошую производительность?

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

После этого на продуктивность влияют три фактора:

1️⃣ Автономность — желание быть независимыми. Именно поэтому Хороший разработчик не любит микроменеджмент. Одновременно, это повышает вовлеченность, дает разработчику ответственность. Разработчики создают условия для автономности работают лучше.

2️⃣ Скилл — естественное желание становиться в чем-то лучше. Чувство, что ты что-то изучил, улучшил или помог кому-то хорошо само по себе. Разработчики, которым создают условия для профессионального роста работают лучше.

3️⃣ Цель — ради чего разработчик встает с постели каждый день? Напомню, не из-за денег, они уже есть. Должна быть цель, в которую сам разработчик верит. Например, каршеринг помогает людям передвигаться по городу, я в это верю ✅. Создание продукта, где основная цель это прибыль не имеет долгосрочной перспективы. Разработчики, которые понимают и разделяют цель компании работают лучше.

Если разработчик, в целом, может сам решать что ему делать, как ему это делать, если он понимает зачем он это делает, то он будет работать наиболее продуктивно.

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

Что еще мотивирует вас работать? Пишите в комментариях.

#софтскиллы

Почему Spring Boot это лучший в мире фреймворк и все должны его использовать

Раньше я работал с Node.js и только два года назад начал постоянно писать на Java/Kotlin и использовать Spring Boot. Мои первые впечатления подтвердили то, что я слышал раньше — ты не учишь Java, ты учишь что можно сделать с помощью фреймворка. Где создать файл, куда написать аннотацию, сначала ты не очень то и понимаешь, что эти аннотации делают. Но ты их написал и все работает — это чудо.

В мире Node.js у тебя все по другому. Фреймворк это тонкая прослойка облегчающая тебе работу, но ты сам должен решить куда и как положить файлы, где у тебя роутинг, как связать роутинг с моделями. Популярные фреймворки express 🪦 и fastify 📈 не требуют от тебя соблюдать какую-то структуру, они просто немного облегчают тебе жизнь.

Но самое большое чудо в том, что есть миллионы разработчиков, которые умеют работать с Spring Boot и этой экосистемой. В итоге, когда новый человек приходит на проект, он уже знает как тут все работает, ему остается разобраться только с бизнес логикой. А если новый человек приходит на Node.js проект, то он начинает задавать вопросы — почему это лежит тут? Как запустить тесты?

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

Еще один пример. У нас в проекте многие сервисы шлют change data capture сообщения в RabbitMQ, но что если что-то потерялось и нужно опять обработать все сообщения? Для этого давно написали процедуру синхронизации. Она читает все из базы данных и шлет сообщения — миллионы. Пришло время ее менять...это было то еще удовольствие 🤯.

А потом, нам нужно было решить другую, но похожую задачу и один из коллег рассказал мне про Spring Batch, это фреймворк из Spring экосистемы для выполнения batch задач. Как же я обрадовался. Мы смогли взять стандартное решение и применить его. Да мы потратили время на изучение этого фреймворка, и там куча классов и необязательного кода. Но зато любой Java специалист в будущем сможет разобраться с тем, как это работает и у него не будет вопросов, потому что мы использовали стандарты, а не уникальное решение.

Spring Boot это ❤️ потому что это скучный стандарт, именно поэтому проекты на нем легко поддерживать и масштабировать. Процессорное время и память стоят дешевле, чем время разработчиков.

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

А вы как, любите Srping Boot? Пишите в комментариях.

#истории

Все как код

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

Приложения это код. А вот сервера и метрики? Раньше, перед тем как получить готовый сервер для приложения, сервер нужно было купить и настроить. А если требовался еще один сервер? Тоже — купить и настроить, хорошо бы настроить его так же как первый. Если нужны были оповещения о метриках — нужно было зайти в какой-нибудь Datadog и, с помощью UI, сконфигурировать эти оповещения.

Это неудобно 🙅‍♂️, потому что:

1. Много ручной работы. А что если у нас есть три среды окружения - development, integration, production ? Тогда надо три раза все сделать руками.
2. Можно что-то забыть, потому что см. пункт 1.
3. Это долго, везде надо прокликать мышкой.
4. Это плохо контролируется. Принцип 4-х глаз соблюдается только, если при выполнении тебе кто-то смотрит через плечо.

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

Это удобно 👍, потому что:

1. Можно написать один раз и применять везде
2. Все будет одинаково, ровно так, как запрограммировано
3. Код применяется быстрее
4. Код хранится в git, можно делать merge request , видеть историю изменений.

Конфигурация (серверов) как код была доступна достаточно давно, Puppet на рынке с 2005 года. Но сейчас возможности больше. Можно создавать облачные ресурсы используя terraform определения (AWS provider), можно конфигурировать метрики в New Relic используя terraform (New Relic provider).

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

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

Что интересного вы храните в git? Пишите в комментариях.

#хардскиллы

​​Что такое Матрица Эйзенхауэра

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

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

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

Матрица представляет собой квадрат два на два, где по горизонтали деления ⌛️ Срочно и 🌴 Не срочно, а по вертикали 🚨 Важно и ☘️ Не важно.

Все задачи, которые вы хотите приоритизировать, нужно поместить в одну из секций:

☘️ Не важно + 🌴 Не срочно.
Этим можно вообще не заниматься, поверьте, если что-то измениться и задача станет важной, вы точно об этом узнаете.
Например, у кого-то возникла идея, что если поменять картинку на более синюю 🔵, то увеличится конверсия на сайте.

☘️ Не важно + ⌛️ Срочно.
Эта задача все еще срочна, но для вас не важна. Вероятно есть кто-то другой, для которого она важна. Попробуйте найти такого человека или команду.
Например, где-то на UI у кнопки неправильный перевод, а вы бэк-энд разработчик. Нужно поправить, но лучше вас это сделает кто-то с экспертизой во фронт-энд.

🚨 Важно + 🌴 Не срочно.
Такие задачи можно запланировать на будущее, а сейчас выкинуть из головы. Например, создайте задачу в бэклоге.
Например, через год заканчивается срок поддержки LTS версии Node.js. Нужно перейти на новую версию. Но это сделать это нужно не прямо сейчас, можно отложить.

🚨 Важно + ⌛️ Срочно.
Это то чем точно нужно заниматься. Если есть выбор — делайте задачи из этой секции.
Например, у вас по цифрам видно, что если вы поправите валидацию, то у вас будут больше клиентов полностью проходить регистрацию. Делайте это.

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

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

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

#софтскиллы

Про коммуникацию

Как-то раз, в компании где я работал раньше сменилось руководство. Был один СЕО, а стал вообще другой — приглашенный из вне. Так решили инвесторы. И вот новое руководство привело с собой новые метлы. У нас сменился CTО, им стал руководитель разработки банка (в прошлом).

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

Для меня, как для разработчика, оба человека были неприятными. Они говорили какие-то отстраненные вещи — давайте писать ADR, давайте все запускать в контейнерах, давайте перейдем с bash скриптов при CI на декларативный стиль. А я думал - ну что "давайте", у меня что дел нет? Мне надо фичи писать, баги чинить, разгребать технический долг.

Спустя годы я понял — они говорили совершенно хорошие вещи ✅, которые могли бы помочь инженерингу, но они делали это совершенно неправильно ❌. Эти технически грамотные специалисты не умели коммуницировать. Они не вовлекали команду, они не объясняли почему это нужно сделать. Они не заботились, чтобы эти оптимизации имели свой приоритет на фоне бизнес задач.

CTO в компании на 100+ инженеров потратил очень много своего личного времени, чтобы переписать CI на Jenkins на что-то декларативное. Чтобы потом просто скинуть ссылку на этот репозиторий в Slack и сказать что-то типа "80% работает, я не уверен что это покрывает все что было раньше". И все на этом. Очевидно, что эта идея умерла.

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

Сейчас я уже не думаю что эти люди небыли специалистами. Я уверен, что оба делали свою работу искренне и думали что делают что-то правильное. К сожалению, они не знали, что 50% от успеха это коммуникация. И они провалили эти 50%, как и свои "реформы" 📉.

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

Что думаете? Пишите в комментариях.

#истории

High availability и Fault tolerance

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

Хороший разработчик борется с даунтаймом на уровне архитектуры. Мы часто слышим что сервис High available, реже слышим что он Fault tolerant. Иногда эти понятия путают. Давайте разберемся что есть что.

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

1️⃣ High availability

Мы хостим наш стартап в одном датацентре (Availability Zone в AWS). В результате климатических изменений AZ затопило, вместе с ней и все сервера. Мы не можем выдавать в аренду плакаты 📉. Это не High availability.

Лучше, если бы мы поместили сервера в разные AZ и умный лоад балансер распределял бы по ним трафик. Тогда, в случае затопления, наш стартап продолжит работу.

2️⃣ Fault tolerance

Для нормальной работы нашего стартапа нужно 6 серверов, только такой сетап выдерживает текущую нагрузку. Обычно про пиковую нагрузку мы узнаем заранее, ориентируемся на твиттер Греты Тунберг. Наши сервера равномерно распределены по двум AZ. Вдруг один затопило и все стало работать медленнее, три сервера не справляются с нагрузкой. Мы выдаем в аренду меньше плакатов 📉. Это не Fault tolerance.

А вот если бы мы размещали по 6 серверов в двух AZ, то есть имели бы избыточные ресурсы, то наши пользователи бы не заметили конфуза с затоплением. Fault tolerant системы выдерживают обычную нагрузку, даже если произошли какие-то перебои с инфраструктурой.

Если представить, что каждый сервер обходится нам в 100€ в месяц, то очевидно, что построить Fault tolerant систему дороже 💸.

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

Вы строили Fault tolerant системы? Пишите в комментариях.

#хардскиллы

Что такое Glue work

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

Есть еще:
* нерегулярные технические митинги
* пришел новичок, ему надо обо всем рассказать и включить в работу.
* команда решила как бороться с техническим долгом, надо создать тикеты
* заметили, что документация устарела — надо обновить
* отдел маркетинга долго не отвечает на вопрос про бизнес логику — надо им напомнить
* узнали про новую технологию и думаете что она пригодиться — надо подготовить презентацию
* что еще? таких мелких задачек куча

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

У таких задач есть название — Glue work, а люди, которые этим занимаются — они being a glue. Потому что они, фигурально, склеивают сложный пазл разработки программного обеспечения и с ними определенно легче, чем без них.

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

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

⬛️ Еще раз — помимо разработки в IDE Хороший разработчик может делать еще кучу дел, которые делают команду эффективнее. Нужно понимать, что эти "мелкие" дела они сами по себе работа, может даже важнее программирования. Этим может заниматься каждый, не только менеджеры. Людей которые это берут на себя нужно за это благодарить (если они это делают хорошо). Glue work это классно и это тоже скилл.

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

#софтскиллы

У кого есть дети, я написал лонгрид о том как практики из IT помогают мне быть хорошим родителем. У кого нет детей — тоже может быть полезно :)

https://dou.ua/forums/topic/35409

Про типы компаний и карьерный рост

Мнение. Ваш рост в большой продуктовой компании никак не коррелирует с вашим, возможным, рангом в FAANG компании.

Да, мы и раньше знали, что Senior в одной компании необязательно Senior в другой компании. Ты можешь быть самым умным и опытным Senior в компании из 20 разработчиков, а потом переходишь в компанию где их 200 и там ты просто Middle. Но если мы сравниваем большие компании с хорошей инженерной культурой, должно же быть иначе?

Нет. Возьмем меня, я вот рос рос и дорос до Principle Software Engineer в компании с хорошей культурой, умными и мотивированными людьми и большим количеством инженеров. Но если я решу апплаиться в Facebook, будут ли там впечатлены моими достижениями? Нет. Без предварительной подготовки меня размажут вращением деревьев, сортировкой массивов и знанием латенси между датацентрами. Да, я читал, что при собеседованиях в Amazon ожидается, что ты знаешь латенси и учитываешь это при проектировании системы.

Компетенции которые делают меня Principle в SHARE NOW — знание доменной области, софт скиллы, влияние на развитие инженеринга, не делают меня даже Middle (в целом у них уровни по другому называются) в FAANG компаниях. Наверное все, что я упомянул это хорошо, но входной фильтр остается прежним — вращай деревья, пиши код на доске, быстро ищи в массивах, проектируй системы.

В этом году вышла интересная статья, где автор рефлексирует про типы технологических компаний в Европе и где какие платят зарплаты. Там он приходит к выводу, что получать огромные деньги можно, люди это делают, компании платят, но такие позиции уникальны для общего рынка. В частности рынка, на котором играет SHARE NOW. Работа в Big Tech лишь издалека похоже на работу в Tech, а если приблизить, то очевидно, что там другие правила.

Это как плаванье и бег. Если я умею быстро плавать (SHARE NOW), то это не помогает мне быстро бегать (Netflix). Хотя и то и то — спорт.

Но есть и хорошие новости. Если будучи в 🇺🇦 Украине, в прошлом, я думал что в Google попасть сложно или невозможно. То сейчас, я понимаю что это целиком возможно и секретный соус в следующем:

1. Принять, что мой прошлый опыт для них не релевантен. Зато релевантен для меня, он поможет мне с пунктом два.
2. Нужно потратить время (много) и подготовиться. Cracking the coding interview и https://leetcode.com/ нон стоп и все будут довольны.

Что думаете? Есть среди нас люди из FAANG или другого BigTech? Интересно ваше мнение.

#истории

Новости

Michael Jackson (не тот) и Ryan Florence придумали и поддерживают React Router — #1 декларативный роутер для React экосистемы. Этот проект open source, зато он сделал их известными на рынке. Поэтому зарабатывали они, насколько я понимаю, с помощью компании React Training — проводя оффлайн тренинги по React.

Но тут пришла пандемия 🦠 и оффлайн тренинги перестали быть популярными, а онлайн, как я понял, не имели такого же размаха. Ребята решили сделать небольшой пивот и придумали, что они смогут сделать проприетарный (т.е. платный) фулстэк фреймворк для веб разработки. С React, server rendering, улучшенным роутингом и своими фичами. Они назвали его Remix.

Мне эта идея не казалась здоровой, потому что в 2021 не должно быть платных фреймворков. Но недавно все изменилось. В октябре они анонсировали, что получили 3.000.000💰инвестиций и приняли решение сделать свой фреймворк open source.

Сегодня день релиза, можно посмотреть пощупать: https://remix.run/. В общем альтернатива Next.js.

Еще они сделали красивое промо видео, из которого я ничего не понял, кроме как то, что оно красивое.

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

Слышали об этом проекте?

#новости

Что такое 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 файл. Когда что-то делаешь, то нужно себя спрашивать — это будет сложно понять постороннему человеку?

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

#софтскиллы