Good dev knows

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

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

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

Что такое 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 поможет ответить на этот вопрос.

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

#хардскиллы

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

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

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

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

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

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

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

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

#истории

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

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

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

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

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

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

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

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

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

#софтскиллы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#хадрскиллы

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

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

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

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

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

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

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

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

#истории

👋,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#софтскиллы

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

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

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

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

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

Чем отличается 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.
Все зависит от того, кто будет использовать технологию. Что этот человек умеет и что для него важно сейчас. Например, если быстро получить результат и "тяжело" по ресурсам — подойдет декларативный стиль. А если оптимизировать по ресурсам, но потратить на это больше времени, тогда лучше императивный стиль.

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

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

#хардскиллы

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

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

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

#истории

Привет друг,

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

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

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

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

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

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

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

💎 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? Расскажите.

#софтскиллы

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

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

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

Что такое ADR

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

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

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

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

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

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

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

#хардскиллы

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

За время моей карьеры мне где-то три раза нужно было кардинально менять технологии. Начинал я с 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. Потом я подключаю книги 📚, благодаря "насмотренности" я могу слегка критически оценивать что там написано.

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

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

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

#истории

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

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

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

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

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

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

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

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

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

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

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

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

#софтскиллы

​​Что такое 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.

#хардскиллы

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

Вторая часть истории про мой промоушен в принципал инженеры в 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 я смог объявить, что теперь я принципал инженер.

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

#истории