Product Minded engineers

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как быть хорошим инженером

Мы уже выяснили, что быть хорошим инженером — это не только классно красить кнопки, но и целый лист требований, которые расширяются. Мы уже писали про Product Minded Engineers.

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

В статье дал такие определения:

🟣Хороший инженер хорошо общается письмено и устно. Его работа напрямую зависит от сотрудничества.

🟣Хороший инженер понимает процессы. Не сабботирует их, а помогают улучшить, либо нарушить.

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

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

🟣Хорошие инженеры упрощают. Они занимаются модульностью, стратегии для тестирования и адаптируются под сложность.

🟣Хороший инженер постоянно учится. Он не боится публично признать свои ошибки и знает, что в следующий раз сделает лучше.

🟣Хорошие инженеры командные игроки. Они распознают проблему и предлагают решение. Они не бросают проблему за ограду и не просят других ее исправить.

☕️ Как я баг исправил, который не могли найти два года

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

Я всегда ищу интересные задачи: помогаю коллегам на работе; менти; беру небольшие подработки, если мне интересен проект. Так я улучшаю карму, повышаю навыки, выходя за границы привычных задач и, конечно, зарабатываю 🤡

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

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

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

🌟 Добавить логи. Зачем мне стараться воспроизвести редкий баг, если я сделаю систему трекинга, которая при воспроизведении у кого-то, даст мне полезную информацию самым быстрым способом.

Окей. С логами понятно, но что будем трекать?

Если зависание главного потока, то здесь на помощь приходит Watchdog. О стандартном механизме мы уже когда-то писали, но я напомню. Watchdog — это механизм, который помогает отслеживать проблему блокировки потока. Я же написал свою реализацию, чем-то похожую на эту.

Так. Мы научились понимать когда main thread завис. Теперь нам нужно как-то понимать что стало причиной его зависания.

Тут тоже все тривиально. Мы берем Stack Trace и записываем его в файл и отправляем в Firebase. Стандартный

Thread.callStackSymbols

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

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

Дополнительно сделал экран в дебаг меню, который записывает в формате "Date -> Thread.callstack" логи. Чтобы можно было сразу мне отправить лог, как только получили зависание.

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

💎 Вывод. Задача была несложная, но требовала ряда компетенций, которые формируются с опытом и насмотренностью. Это понимание работы потоков, специфики кодовой базы и основ логирования.

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

Делитесь своими метриками, которые помогли решить редкие баги

Сегодня 01.11 у меня др

Завтра я этот пост удалю, не хотел его писать, но вдохновился постом Дурова на свой др.

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

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

Я ни разу не просил рекламу и делал только то, что нравится мне. Писал то, что думал. Старался задумываться о своих читателях. Банил хейтеров.

Наверное, я заметил, что все чаще меня вдохновляют люди. Мне нравится, как ребята сами приходят с просьбами менторства. Хотя я не рекламирую своих услуг, их доверие для меня важно. Также важно, что это уже опытные специалисты, а не новички, которым часто наивно ссут в уши недобросовестные люди, но они выбрали более качественный путь. Пришли на путь истинный 😬 Где кидают респект за смелость быть собой и философию развития фундаментальных навыков, инженерного подхода и радикальной честности. Это все мотивируют идти дальше.

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

В нем всегда одна философия — быть полезным себе и другим.

Мы сделали первыми:
- выигрывали телеграм конкурс. Интересно кста перечитывать посты того времени
- Решали алгоритмы 365 дней
- Создавали апку "Симулятор иосника"
- Создали комьюнити
- устроили марафон по проектированию
- Сделали ютуб
- И кучу всего другого

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

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

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

Поддержать вы его можете конечно же тут 🤡

💎 БУМ! Воркшоп по собеседованию на тему Swift Concurrency

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

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

Сергей делает сложный мессенджер, где на практике использовал всю мощь Swift Concurrency.

За целый час мы узнали:
🟣Какие задачи нужно давать для оценки навыков
🟣Дает ли буст Swift Councurrency в сложных приложения?
🟣Какие знания он ждет от сеньора?
🟣Как ускорил приложение с помощью SC?
🟣Какие баги были и есть в SC?
🟣А также многое другое

Выпуск получился супер техническим и с кодом. Дополнительные ссылки и полезные ресурсы прилагаются

🧬 Получить доступ к этому видео можно тут

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

Опять же читаю книгу "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 листов (конечно, с комментами и другими артефактами)

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

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

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