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

В прошлую среду, 22го сентября, меня, наконец, официально объявили принципал инженером в SHARE NOW. Поэтому сегодня, не столько хвастовства ради, а сколько чтобы задокументировать этот опыт, я резюмирую как это происходило.

К концу прошлого года я работал в SHARE NOW уже более трех лет. Я ощущал, что я делаю намного больше вещей, чем когда я начинал в 2018. Я чувствовал, что делаю это лучше. По моим ощущениям это уже превышало тайтл Senior Software Engineer.

На очередном 1-1 я поднял этот вопрос со своим менеджером. Есть ли в SHARE NOW возможности расти дальше чем Senior и не переходить в менеджмент трек? Мне ответили, что сейчас как раз компания завершает формализацию требований для разных уровней и как только что-то будет, то мне скажут.

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

Так что я вызывался помогать с формализацией этого процесса. Я связался с другом, который работает в Amazon и поспрашивал как это происходит у них. В итоге, учитывая их опыт, в SHARE NOW мы решили делать так:

1. Промоушен на позицию Principle Engineer происходит по принципу in position. То есть человек должен уже какое-то время соответствовать этим критериям.
2. В первую очередь менеджер соискателя должен рекомендовать промоушен.
3. Желающий должен инициировать промоушен формально, главе своей локации. Для этого составив promotion document, где он/она описывает свое соответствие критериям приводя примеры. Там же есть рекомендация на промоушен от менеджера.
4. Дальше, если этого документа достаточно, созывается митинг со skip-level менеджерами, где соискатель презентует свой промоушен и ему задают вопросы.
5. Дальше решение принимается группой менеджеров, где ваш менеджер тоже участвует, но у него нет права голоса.

Я прошел этот процесс и получил ... отказ. Конечно, иначе почему бы я писал этот пост только в сентябре 2021? В целом я получил положительный фидбэк, но мне сказали что этого недостаточно. А именно ожидается:

1. Больше влияния вне команды
2. Больше менторинга Senior специалистов
3. Больше влияния на весь инженеринг

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

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

Что думаете, у вас был когда-нибудь формальный промоушен процесс?

#истории

​​Что такое concurrency и parallelism

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

Когда мы это обсуждаем, то говорим, например, так: "Этот парсер будет работать в 10 потоков". И запускаем 10 горутин. Давайте разберемся, действительно ли это так? Что такое concurrency, а что такое parallelism.

1️⃣ Concurrency

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

2️⃣ Parallelism

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

Эти определения актуальны везде - при обработке транзакций в базе данных; на сервере; в сети, при использовании общих сетевых ресурсов.

Если у вас 1 процессор и вы запускаете 10 горутин, то ничего не будет обрабатываться параллельно. Это все еще concurrency. Но обрабатываться будет все равно быстрее, чем просто в одном потоке и последовательно. А вот если вы делаете пул потоков по количеству процессоров, и они обрабатывают задачи из очереди — это уже parallelism.

⬛️ Еще раз — concurrency и parallelism это разные вещи. Главное, что они обе позволяют обрабатывать информацию быстрее. Но разницу тоже знать важно — если будет нужна дальнейшая оптимизация.

Любите горутины? Или может worker threads? Пишите в комментариях.

#хардскиллы

Что нужно отдыхать 🌴

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

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

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

◼️Ещё раз — умение отдыхать это софт скилл. Его нужно развивать. А вот отказ от переработок должен быть данностью.

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

#софтскиллы

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

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

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

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

Вот что я делал в промежуток времени с марта по сентябрь:

1. С подачи одного из skip-level менеджеров, я взял техническую ответственность за отношения SHARE NOW с одним из SaaS решений которыми мы пользуемся. То есть я стал экспертом по этому сервису внутри компании, переписывался с поддержкой самого сервиса по поводу багов, думал о том как мы можем построить свои решения используя этот сервис.
2. В рамках внутреннего tech leadership тренинга рассказал о том как делать технические презентации для НЕ технических людей.
3. Инициировал рабочую группу по Cost optimisation/awareness. Где мы в течении 2-х месяцев прошлись в целом по тому на что мы тратим деньги в инженеринге, где мы можем оптимизировать, а где и так хорошо, что команды должны делать, чтобы быть в курсе своих расходов. Я фасилитировал эти встречи и в результате мы подготовили наши рекомендации, которые представили всему инженерингу.
4. Я инициировал внутреннюю ежемесячную рассылку для product creation департамента. Где уже 6 месяцев мы: рассказываем о том что происходит в architecture guild, люди рассказывают с технической стороны о проектах которые делает SHARE NOW, знакомимся с нашими коллегами — 1 интервью в месяц.
5. Я продолжал работать как член команды и, в принципе, мы тоже сделали много.

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

Чтобы все было измеримо, я отдельно взял фидбэк у людей с которыми я работал про себя. У людей которые участвовали в Cost optimisation/awareness группе — про то как я фасилитировал группу. У всего product creation о том полезна ли ежемесячная рассылка.

В конце августа состоялся еще один митинг со skip-level менеджерами. После которого я в тот же день получил ответ, что все "за". Из-за отпусков и бюрократии сам анонс задержался еще немного, но, наконец, 22го сентября 2021 я смог объявить, что теперь я принципал инженер.

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

#истории

​​Что такое Levels of maturity

Давайте представим, что вы хотите ввести в команде какой-то процесс. Например, вы как-то на ретроспективе обсудили вопрос, что все зависимости должны быть up to date. Но на практике у вас все равно отставание. Уже давно вышел Spring Boot 2.5, а у вас в трех сервисах 2.4 и только в одном 2.5. Вы расстроены, качество внедрения процесса обновления зависимостей ощутимо хромает.

Для того чтобы что-то исправить, нужно сначала что-то измерить. Тогда будет понятно улучшаем мы что-то своими действиями, ухудшаем, или оно остается на месте. Измерить качество внедрения процесса помогут levels of maturity.

Всего их пять:

1️⃣ Initial - процесс непредсказуем, никто его не контролирует и как правило он выполняется реактивно. Иными словами — когда петух клюнет.

2️⃣ Managed — начинается внедрение процесса, он описан на уровне команды или проекта. Но он все еще, иногда, выполняется реактивно.

3️⃣ Defined — процесс описан и формализован для всей организации. Он выполняется проактивно.

4️⃣ Quantitatively Managed — процесс выполняется регулярно, измеряется его качество, отслеживаются ключевые показатели.

5️⃣ Optimising — процесс налажен хорошо, более того, его постоянно пытаются улучшить, основываясь на ключевых показателях.

В нашем примере со Spring Boot, мы, очевидно, на стадии 2️⃣, есть куда развиваться. Levels of maturity, как правило, можно применить ко всем процессам — техническим и не техническим.

⬛️ Еще раз — если мы внедряем какой-то процесс, то важно понимать где мы находимся с его внедрением. В этом нам помогут Levels of maturity.

#хардскиллы

Как вовлечь группу в продуктивную дискуссию

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

Вы начинаете нервничать 😰. Может никто ничего не понял? Может я плохо объяснил(а) А может они и вовсе не слушали?

Из этой ситуации есть универсальный выход. Нужно предложить аудитории ответить на три вопроса:

1️⃣ Что вам понравилось по поводу предложения?

2️⃣ О чем бы вы хотели получить больше информации?

3️⃣ Что у вас вызывает сомнения?

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

Эта техника еще лучше работает на удаленных митингах. Вы можете предварительно подготовить какой-нибудь MURAL, где участники смогут отвечать одновременно.

Далее, как правило, вы можете продолжить дискуссию обсуждая пункты из вопросов 2️⃣ и 3️⃣.

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

Бывало у вас, что вы митинг завершался неловкой фразой "молчание это признак согласия"? Пишите в комментариях.

#софтскиллы

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

За время моей карьеры мне где-то три раза нужно было кардинально менять технологии. Начинал я с PHP и фронт-энд JavaScript, его нужно было сменить на Node.js. Потом нужно было освоить React. А недавно, в 2019, нужно было научиться Java/Kotlin и Spring Boot.

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

А рассказать я хочу о том, как я учу новые технологии. Я делал это неосознанно первые два раза, а потом встретил подтверждение моего метода в книге Soft skills: The Software Developer's Life Manual. Книгу я тоже рекомендую.

Рецепт простой — когда вы начинаете учить новую технологию, то просто окружите себя ей. Сначала нужно убрать "туман войны", узнать какие вообще есть аспекты у этой технологии. Даже если вы не понимаете, о чем идет речь, просто продолжайте, чтобы у вас вырисовывались контуры — что вообще можно учить, если тебе надо освоить Spring Boot ?

Я решаю этот вопрос в основном с помощью видео. Я просто начинаю смотреть Youtube на тему. Там точно есть ролик "Spring Boot за 1 час", там точно есть ролик "Spring Boot за 2 часа" и тому подобные. Еще какой-нибудь дешевый курс на Udemy. Потом я подключаю книги 📚, благодаря "насмотренности" я могу слегка критически оценивать что там написано.

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

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

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

#истории

Что такое ADR

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

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

Например, мы собрались, оценили DynamoDB, MongoDB и PostgreSQL и решили что будем использовать PostgreSQL. Это сработало хорошо, стартап стал успешным 🚀. Через 3 года все участники той дискуссии уже работают в других компаниях тимлидами, а над стартапом работают новые разработчики. Через день они клянут 🤬 своих предшественников — почему тут PostgreSQL, ведь намного лучше подошла бы Neo4j у нас тут граф графом погоняет.

Проблема не в технологии, проблема в том, что новая команда не знает контекста, в котором было принято предыдущее решение. Решить эту проблему можно введя практику Architecture decision record (ADR). ADR это документ, в котором вы описываете ключевые решения для проекта, почему вы их приняли, что вы учли и какие последствия вы предвидели.

Например, можно договориться, что в каждом проекте в корне будет папка /adr и в ней будут документы, составленные по такому простому шаблону. Каждый документ проходит merge request процесс, где другие участники команды могут оставить свои комментарии. В итоге контекст принятия решения сохраняется навсегда и лежит рядом с сервисом — очень удобно ✅.

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

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

#хардскиллы

⚡️ В рамках контент маркетинга опубликовал статью на Хабре, где рассказываю больше про DORA метрики:

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

Если вы олды, то поддержите плюсом 🤝 Еще я обложку сам сделал 🎨

💎 of participatory decision making

Если нужно, чтобы над решением слаженно работала группа людей, то лучше принять его коллективно. В таком случае, все участники группы будут чувствовать ответственность за результат. Такие решения называют participatory decision making.

Некоторые решения простые. Например, у нас уже 6 сервисов на Kotlin и мы думаем какую технологию выбрать для следующего сервиса. Этот вопрос можно решить и в Slack, вряд ли будут трения, это business as usual.

Но есть и сложные вопросы. Например, нам нужно решить как мы будем принимать оплату — будем писать сами? Используем Stripe? Или наймем кого-то, чтобы они написали? Здесь лучше собрать митинг и обсудить. Может мы и вовсе забыли какой-то вариант. На таких митингах нет гарантии, что все пойдет гладко.

Все мы оказывались в ситуации, когда посреди митинга кажется что мы не приближаемся к решению, а участники просто спорят о чем-то отвлеченном 🤯. К счастью это норма! Это можно объяснить с помощью Diamond of participatory decision making. Согласно этой теории, коллективное принятие решения можно разделить на фазы:

0️⃣ Business as usual - простой вариант, все идет по плану, нет конфронтации, решение находится быстро

1️⃣ Divergent Zone - начало процесса, участники выдвигают разные идеи, начинается обсуждение

2️⃣ Groan Zone - время турбулентности, участники в конфронтации, возможно вообще обсуждение отклоняется от темы

3️⃣ Convergent Zone - завершение процесса, количество обсуждаемых идей уменьшается, фокус на основных вариантах

4️⃣ Closure Zone - участники приходят к решению

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

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

Вспоминаете митинги где был Groan Zone? Расскажите.

#софтскиллы

Привет друг,

Хочу рассказать про изменения в этом канале.

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

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

Моя цель — набрать 2000 подписчиков в этом в этом году. У меня есть идеи как этого достичь — контент маркетинг, реклама и ... кросс промо.

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

Спасибо что со мной 🤗

Если у вас есть другие идеи как развивать этот канал, то пишите в комментариях. Мне интересно.

Сегодня день поста про истории и чужой опыт.

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

https://vc.ru/life/306206-kak-ya-zavel-ekspertnyy-tiktok-i-poterpel-neudachu

#истории

Декларативный и императивный стиль

Чем отличается MongoDB от PostgreSQL, а jQuery от React? Отличий можно насчитать сотни. Но сегодня поговорим об особенном, про стиль общения разработчика с технологией.

Возьмем MongoDB, давайте представим что у нас есть коллекция job_offers и мы хотим выбрать топ 3 с самой большой заработной платой.

db.job_offers.find().sort({salary:-1}).limit(3)

А теперь у нас есть табличка job_offers в PostgreSQL и мы тоже хотим выбрать топ 3 по заработной плате.

SELECT * from job_offers ORDER BY salary DESC LIMIT 3

Заметили разницу? В простых примерах она едва уловима, но все-таки видна. В MongoDB мы говорим технологии, что она должна сделать (императивный стиль). В PostgreSQL мы говорим что мы хотим получить (декларативный стиль). Это важно.

Из этого вытекают особенности каждого подхода:

1️⃣ Императивный стиль

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

2️⃣ Декларативный стиль

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

Нельзя ответить какой стиль лучше 🤷‍♀️. И даже нельзя сказать, что все зависит от задачи — что по зарплатам лучше всего сортировать используя SQL, а вот среднюю зарплату лучше считать в MongoDB.
Все зависит от того, кто будет использовать технологию. Что этот человек умеет и что для него важно сейчас. Например, если быстро получить результат и "тяжело" по ресурсам — подойдет декларативный стиль. А если оптимизировать по ресурсам, но потратить на это больше времени, тогда лучше императивный стиль.

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

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

#хардскиллы

Написал еще одну статью на Хабр — про опыт хранения данных в JSONB.

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

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

И расскажите, любите ли вы JSONB так, как люблю его я.

Как оказывать влияние

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

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

Но есть и адекватные способы. Эти способы можно формализовать. Когда вам нужно убедить цель вашего влияния что-то сделать, вы можете апеллировать к чувствам (emotional approach 🤗) или к логике (logical approach 🧐). Вы можете указывать на то, что нужно сделать (push style ⬇️), а можете направить так, что цель сама поймет что нужно сделать (pull style ⬆️).

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

1️⃣ Investigation (⬇️ + 🧐). Собираем факты, логически доказываем что Kotlin классный — емкий синтаксис, можно использовать все Java библиотеки. Команда впечатлена и соглашается.

2️⃣ Calculation (⬆️ + 🧐). Указываем что Java как-то слишком избыточна, может есть какие-то альтернативы? Давайте поищем. Команда находит Kotlin, она впечатлена и соглашается.

3️⃣ Motivation (⬇️ + 🤗). Рассказываем, что когда мы станем использовать Kotlin, то наступит прекрасное будущее. Команда будет эффективна, компания выйдет на IPO, все будут миллионерами. Команда впечатлена и соглашается.

4️⃣ Collaboration (⬆️ + 🤗). Нанимаем топ Kotlin разработчика, он работает рядом с командой, у него все получается и всегда улыбка на лице. Команда тоже хочет так. Команда впечатлена и соглашается.

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

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

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

#софтскиллы

👋,

Хочу порекомендовать Telegram-канал. Это не платное промо, это канал на который я сам подписан.

Когда я начинал переходить на Java, я где-то увидел упоминание Java: fill the gaps и подписался "про запас". Это оказалось полезным и я остался.

Диана, автор канала, самостоятельно описывает то как устроена Java. Например, серия постов про лямбда-выражения. Я перестал активно учить Java после того как освоился, но канал держит меня в Java-тонусе.

Сейчас Диана стала больше писать про не относящиеся к Java вещи, например про менторство. Поэтому я даже отложил свой пост про это 🙃.

Если вы работаете с Java/Kotlin, то точно загляните.

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

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

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

#истории