Список полезных инструментов для индивидуального плана развития

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

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

Развитие это долгий путь. Где нужно много сил, времени и дисциплины. У меня скоро день рождения и каждый год я основательно меняю свой роадмап развития, который веду еще с 2013 года. Ставлю годовые цели, выбираю ветки куда расти.

В этом году хочу улучшить свой процесс и настроить его максимально ответственно. Сделать полноценный шаблон. Поэтому изучил много разных книг и статей, поговорил с коллегами.

Собрал, на мой взгляд, самые полезные инструменты для составления ИПР:

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

🟣Шаблон ИПР от Qiwi. Еще один инструмент от руководителя групп разработки Авито с детальными советами. Как минимум я лично убедился в эффективности этого инструмента, где множество разрабов выросло в своих навыках.

🟣Книга "The Software Engineer's Guidebook". Очень подробный сборник универсальных советов для бигтехов и стартапов.

Ну а вы тоже делитесь интересными ресурсами.

🌄 Реализация Debounce: Swift Concurrency, Combine, GCD, Timer

Debounce — очень частая задача везде. От собеса, до реальной практики. Недавно помогал одной компании делать тестовое и в нем ожидал, что кандидат применит дебаунсер.

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

В этой статье я сделал реализацию на почти всех популярных вариациях:
🟣GCD
🟣Swift Concurrency
🟣NSTimer
🟣Combine

🧬 Получить доступ к статье можно через подписку в бусти или в боте

Rocket Sim

Купил подписку на инструмент, о котором слышу уже года два. Удобный дебагер, который помогает с частыми задачами:
🟣анализ трафика (если лень запускать снифферы)
🟣дизайн ревью верстки
🟣симуляция локации
🟣Быстрая настройка доступов апки
🟣Пуши и диплинки

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

Всегда ходите на собеседования

Мы привыкли о чем-то задумываться, лишь когда петух клюнет в жопу. Начиная от здоровья и заканчивая работой. Сложно сказать когда появился совет "проходить собесы каждый n-месяцев". Уж точно, до появления айфонов. Но он всегда актуальный. Это как регулярный чекап. Плюс в чат, если тоже на него забиваешь.

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

Автор статьи рассказывает почему IC8 инженер из Меты посоветовал ему всегда быть "острым":

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

🟣 Искать работу лучше, пока есть текущая. Даже для того чтобы убедиться, что текущее место лучше рыночных предложений.

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

🟣Некоторые навыки, как эффективное решение алгоритмов, можно прокачать только усердной подготовкой. Чем больше времени между собесами, тем сложнее все вспоминать.

Ну а лучшие материалы для подготовки и чат с практикующими разрабами из всех компаний мира тут 😬

Не ходите часто по собеседованиям

В противовес предыдущему посту я хочу поделиться своими и чужими мыслями почему не стоит часто ходить на собесы. Основано на реальных данных.

🟣Все меньше вакансий. Если вы часто ходите на интервью, а еще и не подготовившись, то упустите возможность попасть в хорошую команду/компанию своей безответственность.

Рынок вакансий все меньше, а значит и выбора.

🟣Вас забанят. Компании замораживают ваш статус на полгода/год и повторно пройти интервью нельзя.

Это особенно критично при внезапной потери работы.

🟣Рост внутри компании лучше. Выражу непопулярное мнение, но не всегда скачки по компаниям это хорошо. Чаще новое место может быть всего на 10-15% больше от текущего бюджета. Задачи, процесс и коллектив хуже. На долгосрочной дистанции это скорее проигрыш, а не победа. Прыгая туда сюда, в поисках себя, можно потерять драгоценное время. Начать разгоняться и быстро остановиться, заново собирая ресурсы и вникая в работу.

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

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

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

Product Minded engineers

Продолжаю читать на отпуске лучшую книгу про карьерный рост «the software engineer’s guidebook». В ней поднимается тема опыта работы в продуктовых командах. О продуктовом мышлении говорят многие, но лучше формулировки, чем в этой книге, я пока не встречал.

Успешный оффер давно перестал быть только требованиям к техническим скиллам

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

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

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

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

Почему product minded engineers становятся более привлекательными специалистами?

🟣проактивность

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

🟣понимание бизнеса

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

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

🟣любопытство

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

🟣сильные коммуникативные навыки.

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

🟣находит компромиссы.

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

🟣находит конструктивные корнеркейсы.

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

🟣быстрые циклы разработки.

Продуктовый инженер впервую очередь доносит полезные фичи пользователю и умеет быстро понимать и находить фидбэки от них

🟣комплексные навыки в решении проблем.

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

Если вы еще не начали ее читать, то очень советую.

А я напоминаю, что сейчас последние дни скидок и скоро выйдет много уникального контента:
🟣 подкаст про систем дизайн глазами руководителей и инженеров
🟣 воркшоп по Swift Concurrency
🟣 интервью с крутой иос разработчицей из Apple
🟣и много других полезных подборок

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