Об ИПР и карьерном росте

Опять же читаю книгу "the software engineer's guidebook" и дошел до советов по карьерному росту. Я как раз делал недавно новый ИПР и хочу тоже прокомментировать некоторые советы из книги, вперемешку со своими личными.

Расти по карьере — это такой же скилл, который нужно прокачивать отдельно, как и навык прохождения собеседований. Ты много можешь слушать и смотреть, но важнее всего практиковаться. Сейчас я понял, что засиделся на одном грейде слишком долго и нужно уже расти. Мне и так было раньше комфортно, но хочется новых задач и вызовов. Да и зона комфорта такая вещь, от которой веет забвением.

Иногда рост по карьере может сильно отличаться от профессионального развития, это писали при чтении книге "Growing As a Mobile Engineer". Поэтому есть много важных действий, которые необходимы к ускорению

Эти комменты могут быть полезны и вам:

🟣Иди по лестнице последовательно

Одна из моих ошибок, что смотря на следующий грейд, я думал так: "Ага, для след. грейда нужно написать статью или выступить с докладом. Слишком легко. Сделаю конференцию и там будет три доклада" или "Нужно улучшить компоненты компании. Ага, я создам новый стрим с юнит-тестами". Но этот подход не очень помогает оценить твой дифф между текущим уровнем и следующим. А также требует хорошей защиты. Для карьерного роста гораздо лучше идти последовательно к целям 1, 2, 3, 4, 5. А не пытаться прыгать 1, 3, 2, 5, 4. Лучше делать небольшие иттеративные шаги, чем прыгая вперед на два шага, а потом назад один. Это как качаться в качалке с разными весами каждый день и не иметь четкую последовательность, режим.

🟣Не игнорируй маленькие задачи

У меня, как и умногих инженеров, бывала критическая ошибка недооценивать важность маленьких, но полезных задач. Когда ты хочешь роста, то тратить время на маленькие и простые задачи не хочется. Почему это состояние вредно? Ты можешь остановиться на месте в ожидании сложных и больших задач. А также приносить нулевую, а иногда и отрицательную пользу.

Маленькие задачи могут приносить большой эффект.

🟣Планируй outcome'ы на старте

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

Например, внедрение технологии BDUI помогло нам повысить метрики по качеству или выручки на 3-4%. А благодаря КМП мы ускорили разработки фичи на 30% сторипоинтов.

Иначе, без метрик или четких доказательств, все задачи будут busywork'ами.

🟣Веди логи все время

Очень многое зависит от того, как ты оформишь свой лист с перфоманс ревью. Почти как с резюме. У меня часто бывало, что когда я только начинал писать, то почти все забыл. И думал, что толком ничего не сделал, даже листа не наберу. Потом я тратил много времени собирая все свои output'ы и outcome'ы. Где в итоге, на последнем перфревью, вышло аж 15 листов (конечно, с комментами и другими артефактами)

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

А так хоть самому потом проще собирать для ревью информацию

Делитесь своими советами.

🌟 Подборка задач на Swift Concurrency

Ну и заканчиваем эту неделю разборами Swift Concurrency подборкой задач.

В них собрал все задачи, которые мы разбирали в комьюнити за последнюю неделю, а также что встречались на созвоне:
- Задача на понимание работы async/await
- Задача на группировку тасок
- Задача на отмену тасок
- И другие

💎 Бонусом сделал скидки в честь черной пятницы

Основы синхронизации в многопоточности

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

Теперь структура такая:
🟣Для кого статья: начальный, средний, продвинутый
🟣Вводная информация
🟣Краткие выводы
🟣Практические задачи
🟣Квиз

Этой структуре нас долго обучали в разных школах по контекту (яндекс практикум/грейд и тп). Так после многих исследований выяснилось, что такой формат лучше закрепляет информацию. В книге я его чуть улучшу.

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

🦴 RuStore появится на iPhone!

Так считает депутат Госдумы Антон Горелкин. По его словам, Apple сама заинтересована в появлении российского магазина приложений в iOS.

RuStore на гаджетах Apple быть! — заявил депутат.

Ранее Госдума приняла в I чтении законопроект об обязательной установке RuStore в гаджеты, включая iPhone.

💻 Подписаться