Привет друг,

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

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

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

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

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

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

#истории

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