Хороший разработчик знает что такое функциональные и нефункциональные требования.
🎥 видео в TikTok.

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

1️⃣ Функциональные требования или functional requirements
Чаще всего, когда мы разрабатываем программное обеспечение, мы знаем что оно должно делать. Еще лучше, когда мы знаем почему оно должно это делать. Для решения какой бизнес задачи мы пишем эту программу?

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

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

2️⃣ Нефункциональные требования или non-functional requirements

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

Например, есть множество вариантов куда сохранять картинки в нашем мессенджере — мы можем сложить их прямо на диск на сервере, а можем положить в S3. Но только вариант с S3 обеспечит хорошую долговечность этих картинок (99.999999999%).

Большинство нефункциональных требований можно отнести к таким категориям:

1. Performance (производительность)
2. Security and compliance (безопасность и соблюдение правил)
3. Recoverability (возможность восстановления)
4. Maintainability (удобство в обслуживании)
5. Reliability (надежность)
6. Availability (доступность)
7. Scalability (масштабируемость)
8. Usability (удобство использования)

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

Дальше мы подробно рассмотрим категории нефункциональных требований.

Хороший разработчик знает про виды нефункциональных требований.
🎥 видео в TikTok.

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

Большинство нефункциональных требований можно отнести к таким категориям:

1. Performance (производительность)
2. Security and compliance (безопасность и соблюдение правил)
3. Recoverability (возможность восстановления)
4. Maintainability (удобство в обслуживании)
5. Reliability (надежность)
6. Availability (доступность)
7. Scalability (масштабируемость)
8. Usability (удобство использования)

Теперь рассмотрим примеры.

Performance
- Как быстро для пользователя должен открываться сайт?

Security and compliance
- Как мы обезопасим приложение от неавторизованного доступа?
- Как мы можем обеспечить исполнение закона о защите персональных данных?

Recoverability
- Если база данных упадет, как мы можем восстановить данные?

Maintainability
- Если что-то идет не так, наш сервис шлет разработчикам уведомления об этом?

Reliability
- Как мы можем убедиться, что сервис работает стабильно?

Availability
- Если датацентр затопит — наш сервис продолжит работать?

Scalability
- Если ссылку на сайт разместят на reddit — он выдержит нагрузку?

Usability
- Как можно упростить для пользователя использование приложения?

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

Очень важно обдумывать и документировать такие требования как можно раньше.

Было интересно? Поделись каналом с другом.

Хороший разработчик знает что такое DORA метрики.
🎥 видео в TikTok.

Современные процессы разработки включают в себя DevOps практики.

Как мы можем измерить насколько они хороши в нашей организации?

В течение 6 лет DevOps Research and Assessments (DORA) группа из Google проводила исследование, чтобы выявить метрики, которые отражают качество DevOps в командах.

Они пришли к выводу, что это можно сделать благодаря четырем ключевым метрикам:

1️⃣ Deployment frequency

Частота деплоев. Как часто ваша команда успешно релизит на продакшен? Чем чаще тем лучше.

2️⃣ Lead Time for Changes

Время внесения изменений. Сколько времени занимает путь от коммита в master до релиза на продакшен? Чем меньше тем лучше.

3️⃣ Change Failiure Rate

Коэффициент ошибок. Процент деплоев, которые привели к проблемам на продакшене. Чем меньше тем лучше.

4️⃣ Time to Restore Service

Время восстановления. Сколько времени нужно, чтобы восстановиться после ошибки на продакшене. Чем меньше — тем лучше.

Регулярно измеряя эти метрики вы можете получить оценку уровня DevOps и следить за ее прогрессом. Оценка может быть такой: Elite, High, Medium или Low.

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

О чем еще рассказать про DevOps? Пишите в комментариях.

Хороший разработчик знает какие метрики нужно измерять.
🎥 Видео в TikTok.

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

Но что именно нужно мониторить? Исследования Google говорят, если вы можете мониторить только четыре метрики, то начните со следующих:

1. Latency
2. Traffic
3. Errors
4. Saturation

Они назвали их Four Golden Signals.

1️⃣ Latency

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

2️⃣ Traffic

Сколько трафика получает наш сервис? Для http сервисов это как правило измеряется в количестве запросов в секунду.

3️⃣ Errors

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

4️⃣ Saturation

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

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

⬛️ Еще раз - чтобы не было проблем, нужно на них оперативно реагировать. Для этого можно мониторить четыре золотых сигнала - latency, traffic, errors, saturation.

Было что-то новое для вас? Расскажите об этом в комментариях.

Хороший разработчик знает как использовать технику Fist to Five на митинге.

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

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

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

С помощью техники ✊ To 🖐 мы получим фидбэк, есть ли у группы консенсус по вопросу. Готовы ли мы двигаться в направлении использования Kotlin? Для этого каждому нужно с помощью своей кисти отразить отношение к вопросу.

Можно показать 6 знаков:
1. Кулак — мне не нравится, я блокирую
2. Один палец — я вижу большие проблемы, которые нужно решить сейчас
3. Два пальца — я вижу небольшие проблемы, которые нужно решить сейчас
4. Три пальца — я вижу небольшие проблемы, которые нужно решить потом
5. Четыре пальца — мне нравится идея
6. Пять пальцев — идея супер, я готов вести этот проект

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

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

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

Хочешь узнать больше про митинги? Пиши в комментариях.

Хороший разработчик знает истории и учится на чужом опыте.

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

Грубо говоря архитектура была такая - пользователь заполнял форму, где указывал данные про себя и сколько он хочет взять денег в кредит. Затем эта заявка проходила скоринг. А затем, в зависимости от результата, бэк-энд делал выплату.

Однажды кто-то заметил, что один 🧑‍💻 получил больше 10.000€. По бизнес правилам это было невозможно, потому что максимальный кредит который мы давали был 1500€ в одни руки.

Мы стали разбираться, и выяснили, что он получил выплату по одной заявке 8 раз! Мы стали копать дальше, и выяснили что, скорее всего, 🧑‍💻 для результата достаточно было просто очень быстро нажимать на кнопку подачи заявки — когда происходит сабмит формы. Потому что мы успешно обработали одну и туже заявку 8 раз.

На фронт-энде мы просто делали кнопочку "серой", но не блокировали клики по ней. На бэк-энде мы проверяли статус заявки, но если нажимать с разницей в миллисекундах, то запросы будут обработаны разными копиями аппликейшена и статус не успевал обновляться. Это называется race condition, ну и наш security фэйл, конечно же.

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

⬛️ Еще раз, при проектировании всегда думайте что может пойти не так — design for failure. Мы не подумали и это стоило минимум 10.000€.

А у вас были какие-то security фейлы? Рассказывайте.

Давайте немного познакомимся и посмотрим кто у нас тут где. Меня зовут Павел, я в IT уже более 15 лет. Сейчас по документам я Senior, а по ощущениям Staff+. Работаю в SHARE NOW, каршеринг сервис в 🇩🇪 Германии.

Расскажите плз, где вы в IT, это поможет мне лучше готовить контент. Отвечайте по свои ощущениям, а не по документам.

Хороший разработчик знает как правильно сравнивать расходы на инфраструктуру или что такое TCO.

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

Давайте рассмотрим на примере. Представим что мы запускаем стартап - социальная сеть для любителей панд. В нашей соцсети можно будет дружить, размещать смешные картинки про 🐼, у нас будет даже чат для пандолюбов!

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

* далее все расчеты примерны

1️⃣ Предположим, что мы думаем разместить это на Hetzner - сервер для приложения и вебсокетов, сервер для базы данных и файловое хранилище для картинок на 5 терабайт. Примерно, это будет стоить 45€ + 45€ + 27€ = 120€ в месяц.

2️⃣ Теперь посмотрим на AWS. Приложение разместим в Fargate - 320€ в месяц. База данных около 420€ в месяц. S3 который сохраняет по 1Тб в месяц - 23€. Итого 765€ в месяц.

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

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

А в случае с облачным решением за нас это будет делать AWS.

💵 Поэтому нужно сравнивать суммы 2120€ и 765€. Правильно сравнивать суммы, которые мы платим за Total Cost of Ownership.

⬛️ Еще раз - TCO это стоимость покупки ресурса + стоимость его обслуживания.

Считали раньше TCO? Расскажите в комментариях.

Хороший разработчик знает кто такие Staff и Principal инженеры.

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

Большинство разработчиков как-то представляет карьерную лестницу до Senior. Давайте быстро по ней пробежимся (условно):

1️⃣ Junior — в целом что-то понимает. Еще не понятно как настроить IDE, ошибки компилятора вызывают грусть. Не спешит принимать решения самостоятельно.
2️⃣ Middle — если кто-то расскажет что и как надо сделать, то он сможет это сделать. Может потом в мердж риквесте окажется что он не покрыл какие-то граничные случаи, но работать будет. Иногда предлагает оптимизации.
3️⃣ Senior — сформировавшийся специалист, задается вопросом ПОЧЕМУ мы должны это делать? Принимает информированные решения, анализирует трэйд-оффы, измеряет. Координирует разработку в команде, является тем "кто-то" для мидла. Делится знаниями, поддерживает Middle и Junior. В основном влияет на свою команду.

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

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

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

Для этого существуют уровни Staff и/или Principal. Обычно они появляются в компаниях с 30+ инженерами. Эти уровни можно объединить под Staff+

4️⃣ Staff+ — основное различие от Senior это уровень влияния. Он постоянно влияет на несколько команд, иногда на всю компанию. Улучшает процессы и технологии во всем инжинеринге. Менторит Senior людей. Хорошо знает доменную область. Координирует взаимодействие между командами. Учавствует в принятии стратегических решений.

Я описал продактового Staff+. Есть еще и с фокусом на технологию, например, у вас в компании работает создатель какого-то популярного опенсорс фреймворка.

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

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

Хороший разработчик знает истории и учится на чужом опыте

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

Тогда, в середине 2000х, я работал на маленькую 🇳🇱голландскую компанию. У этой компании был внутренний, на то время инновационный, продукт для трекинга задач. Он действительно был красивее чем альтернативы, которые были доступны в то время. Отдельно менеджменту нравилось, что это наш собственный велосипед и мы могли его обновлять.

Однажды и мне поручили внести какое-то изменение в этот продукт. Процесс разработки был тоже простой — правь php файлы по ftp и смотри что получилось. В базу ходи через phpMyAdmin. Окружений было два - integration и production. Разница была в названии баз данных, которые они использовали.

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

Я обновил страницу в phpMyAdmin — таблицы не появилось 🙀. Через 5 минут судорожных кликов по табам в браузере я решил сказать об этом кому-то еще. Дальше пошел damage control.

В результате компания потеряла таски за последние 3 месяца. Потому что оказалось, что бекапы были предусмотрены, но они не работали. Нашелся только старенький, что лучше, чем ничего.

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

Давайте выпишем недостатки инженеринга, которые нужно избегать:

1. Должна быть возможность развернуть проект локально. С локальной инфраструктурой.
2. Периодически нужно проверять что бэкапы работают. Сейчас лучше отдать это на аутсорс и использовать, например, AWS RDS.
3. Нужно чтобы команда знала как реагировать на такие ситуации. Лучше всего проводить 🎯 Game day.

◼️Еще раз — удалять базу данных на продакшене не страшно, такое точно будет происходить и в будущем. Но важно, чтобы команда была к этому готова. Design for failure.

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

Произошел пивот!

Некоторые знают, что вместе с телеграм каналом, я пытался/юсь развивать TikTok. Где выкладываю видео ролики о том, что знает Хороший разработчик.

Так вот, после 3-х недель выкладывания роликов я сдался, потому что TikTok оказался не в состоянии найти мою аудиторию. А именно - он тестировал мои ролики в 🇩🇪Германии, где шансов стать просмотренными у них не было. Потому что я ведь говорю там по-русски.

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

Новый аккаунт пока тут: https://www.tiktok.com/@gooddevknows.official. Приглашаю вас зайти и посмотреть, подписаться и полайкать.

Например, 🎥 про YAGNI и аренду летучих мышей.

Еще я сделал такие выводы:
1. Ролики должны быть короче
2. Тогда их будет легче производить и монтировать
3. Поэтому в Телеграмме я буду продолжать писать большие посты, а в TikTok снимать кусочками.

Надеюсь боги китайских алгоритмов будут ко мне более благосклонны в этот заход.

Вы вообще как, смотрите TikTok?

Хороший разработчик знает как выбрать тип процессора в облаке

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

Давайте посмотрим, какие варианты у нас есть:

1️⃣ CPU — central processing unit. Самый обычный процессор, такой стоит в вашем компьютере. Такие процессоры проще всего программировать. Они подходят для большинства стандартных задач.
CPU состоит из нескольких ядер.

2️⃣ GPU — graphical processing unit. Изначально такие процессоры предназначались для обработки графики. Но стали применяться и в других задачах, где нужен большой объем параллельных вычислений.
GPU процессор состоит из тысяч ядер. Важно, что, чтобы использовать эти преимущества, ваша программа должна уметь работать с таким процессором.

3️⃣ FPGA — field-programmable gate array. Это железо, которое можно низкоуровнево запрограммировать, чтобы оно стало лучше обрабатывать определенные задачи. Грубо говоря, такой процессор сперва нужно прошить, а только потом использовать.

4️⃣ ASIC - application-specific integrated circuit. В этом случае процессор сразу производят оптимизированным для выполнения определенных задач. Например, Google предлагает tensor processing unit для обработки TensorFlow задач.

Если характеризовать эти процессоры по цене 💰(больше мешков = дороже), эффективности 📈 и гибкости ⚖️, то будет так:

1. CPU: 💰, 📈, ⚖️⚖️⚖️⚖️
2. GPU: 💰💰, 📈📈, ⚖️⚖️⚖️
3. FPGA: 💰💰💰, 📈📈📈, ⚖️⚖️
4. ASIC: 💰💰💰💰, 📈📈📈📈, ⚖️

◼️Еще раз — процессоры бывают разные, обычно хватает CPU. Если не хватает и софт позволяет, то можно использовать GPU. Если все еще не хватает — поздравляю, вы работаете над чем-то интересным.

Использовали когда-нибудь GPU? Пишите в комментариях.

Хороший разработчик знает разные способы принятия решения на митинге.

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

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

Существует пять базовых способов, вовлечения группы в принятие решения. На английском их можно назвать Five Cs:

1️⃣ Consensus — каждый из участников искренне поддерживает решение.

2️⃣ Consent — все участники согласны, что решение "достаточно" хорошее.

3️⃣ Compromise — каждый из участников отказывается от каких-то своих желаний, чтобы достичь общего решения.

4️⃣ Count — принимается то решение, которое набирает большее количество голосов.

5️⃣ Consult — человек, который принимает решение, заинтересован узнать мнение группы. Но решение принимает он/она.

Метод принятия решения напрямую влияет на то как будет проходить митинг. Так же он влияет на то насколько вовлечены будут участники в исполнение решения.

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

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

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

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

В прошлую среду, 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. Потом я подключаю книги 📚, благодаря "насмотренности" я могу слегка критически оценивать что там написано.

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

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

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

#истории