engineering path

Как Uber приложение для водителей с нуля переписывал Недавно закончил читать серию статей от Uber — «Why We Decided to Rewrite Uber’s Driver App» В 10 статьях описан весь жизненный цикл переписывания приложения, начиная от осознания необходимости такого шага и обоснования его бизнес-значимости топ-менеджменту компании, заканчивая описанием архитектуры и принятых технических и продуктовых решений в новом приложении. Особенно интересно было читать про продуктовые задачи, стоявшие перед командой. Например, ребята разрабатывали механизм, позволяющий водителям пользоваться приложением в условиях отсутствия интернета. Поначалу непонятно, зачем оно нужно, но впоследствии оказывается, что такой функционал действительно необходим, когда ты строишь многомиллиардный бизнес, работающий с более чем 3 миллионами водителей в более чем 600 городах мира, не в каждом из которых качественно развита инфраструктура мобильных провайдеров и присутствует полное покрытие местности сетью. В общем, сами статьи небольшие, но крайне увлекательные, так что крайне рекомендую к прочтению📖 1. Why We Decided to Rewrite Uber’s Driver App 2. Architecting Uber’s New Driver App in RIBs 3. How Uber’s New Driver App Overcomes Network Lag 4. Scaling Cash Payments in Uber Eats 5. How to Ship an App Rewrite Without Risking Your Entire Business 6. Building a Scalable and Reliable Map Interface for Drivers 7. Engineering Uber Beacon: Matching Riders and Drivers in 24-bit RGB Colors 8. Architecting a Safe, Scalable, and Server-Driven Platform for Driver Preferences with RIBs 9. Building a Real-time Earnings Tracker into Uber’s New Driver App 10. Activity/Service as a Dependency: Rethinking Android Architecture for the Uber Driver App @engineering_path

Ментор: в чём польза? Менторство — это двухсторонний процесс, который позволяет как ментору, так и менти получать пользу. Но основной вопрос "чем может быть полезен ментор?". Во-первых, вы получаете доступ к уникальному опыту и знаниям, которые часто недоступны в интернете или книгах. Ментор может передать техники и стратегии, которые использовал для достижения целей и роста в конкретной сфере. Во-вторых, ментор помогает найти ориентиры, которые уже в нас есть. Изначально запроса может и не быть, его можно выяснить в процессе разговора. Вы вместе пытаетесь понять чем ментор может быть полезен или не полезен (это тоже нормально). В-третьих, это помогает расширить кругозор и установить ценные связи. Часто уже имея зрелую карьеру, ментор может помочь расширить горизонт и познакомить с людьми, которые могут стать ценными связями для вашего будущего. Сегодня у меня состоялась первая встреча с ментором. Вот примеры запросов, которые сформировал в процессе: 1. Кажется что стагнирую и мало чего добился 2. Вокруг все скиловые, боюсь спросить, иначе подумают что не могу сам разобраться 3. Как развиваться и что изучать. Столько материалов, как понять на чем концентрироваться 4. Стоит ли переходить из компании в компанию ради смены обстановки/нового опыта/или чтобы поднять ЗП Важно помнить, что ментор не карьерный консультант, он не выдаст готовый план и у него нет ответов на все вопросы, однако вместе вы сможете сформировать понимание, что от такого сотрудничества можно получить.

Обзор книги Growing as a Mobile Engineer — часть 2 В первой части мы поговорили о приоритете и корреляции между ростом с точки зрения позиции и развитием скиллов. В этой, второй части, расскажу про отличительную черту всех сильных инженеров, с которыми автору доводилось общаться, и которой он посвятил отдельную главу в книге. «Master Your Main Stack» Основная мысль также простая — будь настоящим экспертом в стеке, который является твоим основным. Но что реально вкладывается в это понятие экспертности? В тексте книги есть грамотный и лаконичный ответ на это👇 «Covering all engineering aspects of the platform, not just the frameworks/APIs, was key to these engineers mastering the stack. They would get to a proficient level with testing, using debugging tools, performance monitoring, crash reporting, animations, analytics…» То есть важной характерной чертой, отличающей специалиста от среднестатистического разработчика, является то, что специалист разбирается не только в основных инструментах, используемых в повседневных рабочих задачах, он ещё и погружен в смежные части своего стека, зачастую выходящие за пределы того, что ему необходимо на повседневной основе. И именно эти знания и делают колоссальную разницу между ним и остальными. PS: Во вложениях к посту лежат вырезки из книги по теме c дополнительными мыслями, не упомянутыми в посте. @engineering_path

📝 Заметки для эффективной работы Хочу рассказать о том, как я использую заметки на работе, что помогает мне фокусироваться на основных задачах и быть эффективнее. 📄 Я создал текстовый файл с разными частями: ⁃ То, что нужно обсудить с руководителем/тимлидом ⁃ Для обсуждения с ментором ⁃ Видео для просмотра ⁃ Статьи для прочтения ⁃ Книги для прочтения В первой части записываю все вопросы, заметки и проблемы, которые нужно обсудить с руководителем на еженедельной 1 х 1 встрече. Если возникают какие-то проблемы, то сразу все записываю и спокойно забываю. А потом во время встречи открываю документ и прохожусь по пунктам. Таким образом, я не держу все в голове. Также со вторым пунктом, записываю технические вещи, планы и задачи, которые мне нужно обсудить со старшим разработчиком на еженедельной встрече. Последние три пункта для записи материалов для саморазвития, чтобы не потерять. Время от времени стараюсь их проверять и прочитывать. Более того, на работе есть скрипт для дейлика, который каждый день генерирует док с тремя частями: 1️⃣ Что сделал вчера 2️⃣ Планы на сегодня 3️⃣ Блокеры Этот док помогает мне трекать все что я сделал, не держать все в голове для отчета на дейлике и получать небольшой дофамин, когда видишь что ты не впустую потратил день и заполнил первый пункт. Это кстати Максим упомянул на нашем live-подкасте «Как преуспеть на первой работе?» 🙂 @engineering_path

Обзор книги Growing as a Mobile Engineer — часть 1 Прочитал книгу Growing as a Mobile Engineer, которую Адлет порекомендовал в недавнем посте. Книга очень крутая, крайне редкий случай, когда в книгу такой тематики вложено много сути и действительно мало воды. Спасибо этому каналу за такие полезные рекомендации😄 Сама книга разделена на несколько глав, они все рекомендуются к прочтению, но я бы хотел остановиться на главе Growing to Senior и поделиться несколькими важными инсайтами, которые мне удалось подчерпнуть из неё. В один пост я всё не умещу, поэтому разделю его на несколько частей и буду постить каждые несколько дней. «Professional Growth Versus Promotions» Первая мысль – про рост с точки зрения позиции (junior, middle, …) и рост реальных прикладных скиллов. Базовая мысль простая – карьера разработчика – это игра вдолгую, поэтому акцентируйте в первую очередь внимание на своём прикладном развитии в профессии, особенно на начальных этапах, поскольку в перспективе крепкий фундамент знаний даст больше возможностей для развития, смены стека, направления и так далее. В книге даже есть отдельная глава – Down-Leveling When Changing Jobs, где автор писал о том, как уходил с текущих мест работы на понижение позиции и/или зарплаты ради развития в смежном стеке, изучения других фреймворков или архитектурных подходов на практике. Однако при всём сказанном выше, думать о зарплате и позиции тоже крайне важно, поскольку они являются неким предметным отражением вашего роста и развития, и, на мой взгляд, служат дополнительным стимулом к развитию hard скиллов, например, по причине того, что с ростом позиции вы начинаете чувствовать и нести больше ответственности за принимаемые технические решения, а сами решения требуют всё большей компетенции. PS: Вырезка из книги – во вложении, читайте. @engineering_path

Немного сентиментальный пост, не свойственный этому каналу, но мне хотелось поделиться парой мыслей по недавней лекции, которую я читал в Яндексе, а также книгами и ресурсами, которые очень помогли мне в подготовке – в общем, всё, как мы на этом канале любим. Вообще, это не первый мой опыт в качестве лектора – ранее мне доводилось читать несколько лекций по матанализу в универе, но масштаб и уровень ответственности, как вы понимаете, был совсем иной. Главная мысль, на которой я себя в какой-то момент по-настоящему поймал, заключается в том, что со стороны всё всегда видится легче, чем оно есть. Кажется, что лектор изначально знает (или должен знать) абсолютно всё, а слайды к презентации накидываются, условно, за вечер. В реальности же качественная подготовка к такого рода выступлениям – это огромный труд, и пока сам через это не пройдешь, не сможешь понять, насколько. Например, чтобы в подготовке к лекции дойти из точки А в точку Б, у меня ушло около 3 месяцев, и на этом пути было всё – начиная от кучи потраченных на подготовку и изучение материала выходных, заканчивая неоднократными реструктуризациями всей презентации, желанием сдаться, всё бросить и откинуть копыта. Усложнялось всё это ещё и тем, что в интернете, кроме двух коротких выступлений на WWDC, напрочь отсутствуют качественные лекции по моей теме, где бы можно было подсмотреть структуру повествования – в общем, я вполне сам себе раскопал и исследовал восьмой круг ада. С другой стороны, такие челленджи – это, наверное, и есть настоящий рост, поскольку опыт я приобрёл колоссальный. Тут только остаётся сказать спасибо всем в Яндексе, кто причастен к организации всего этого дела, за то, что предоставляют такие крутые возможности. Теперь к ресурсам 1. Книга по Combine, в которой есть всё, начиная от самых основ, заканчивая advanced темами – Combine: Asynchronous Programming with Swift 2. Лучший онлайн-ресурс, который я нашёл и автору которого очень благодарен. Всё написанное – по делу, с достаточно глубоким разбором некоторых тем, абсолютно ничего лишнего – Using Combine 3. Первая сессия по Combine на WWDC – Introducing Combine 4. Вторая сессия по Combine на WWDC – Combine in Practice 5. Ну и теперь скромно могу добавить свою работу в эту коллекцию, хоть и не считаю её идеальной – моя лекция

Про канал и его авторов Адлет — разработчик, ментор и спикер, выпускник Назарбаев Университета. Ранее успел поработать в Яндексе, сейчас работает в стартапе из США. Анас — разработчик, лектор и куратор в Академии Яндекса, выпускник ФКН ВШЭ. Работает в команде Доставки в Yandex Go. Леонид — разработчик, менторит стажеров и студентов в Академии Яндекса. Работает в команде Доставки в Yandex Go. Максим — разработчик. В 22 года нашел себя в IT, перебравшись из сферы финансов. Работает в команде технического развития Yandex Go. О чем этот канал и почему он есть? Мы уделяем много внимания саморазвитию — статьи, книги, курсы, подкасты — это всё про нас. Вдобавок мы находимся на наиболее активном этапе жизни с точки зрения приобретения опыта. Мы подумали — почему бы не делиться всем этим с окружающими? Так и появился этот канал, в котором мы делимся тем, что сами изучаем, читаем слушаем и через что проходим🤝🤝 @engineering_path

Недавно закончил книгу “Growing as a Mobile Engineer” от Gergely Orosz - автор работал Senior SWE/Engineering Manager’oм в Uber, Skype, J.P. Morgan... В книге на самом деле всего 71 страниц, в начале рассказывает о том как вырасти до Senior разработчика и дальше, затем уже делился опытом engineering management’а. Если коротко, лично я понял что вырасти до старшего разработчика - уже протоптанный путь, нужно просто поработать и вкладывать в свое развитие. А дальше, если оставаться разработчиком и пытаться расти до уровней staff/principal инженеров, нужно уже находить opportunities, с помощью которых ты сделаешь значительный impact. После прочтения начинаешь представлять какого уровня задачи решаются в компаниях как Uber, в которой 100+ разработчиков работающих над одним приложением У автора на самом деле очень много полезного и бесплатного контента в его блоге. И мне кажется что большую часть контента, которая есть в книге, можно найти там - Блог автора - Канал на youtube - Купить книгу @engineering_path

В понедельник, 10 июля, в 19:00 (по Мск) пройдёт моя лекция по Combine в Академии Яндекса. Присоединяйтесь к трансляции!🙂 https://www.youtube.com/watch?v=pO5vZdS__xs @engineering_path

Про первый опыт стажировки Я выходил из офиса после 12 ночи, постоянно прибывал в тревоге и боялся признаться, что я чего-то не знаю — так начиналась моя первая стажировка. Казалось, что такая проблема только у меня. При этом вокруг были коллеги, у которых хватало времени на себя, хобби, обучение и т. д. Сравнение с другими никогда не идет на пользу, и я начал искать способы, как справляться с большой нагрузкой проще. Пробовал всем знакомые техники тайм-менеджмента: расписывал распорядок дня, разбивал задачи на маленькие шаги и выделял главное, используя правило 20/80. Многое из этого давало результат, но… К чему я это. На поиск и проверку лайфхаков уходит время, я был бы рад сэкономить его на старте и сейчас хочу помочь в этом другим. Поэтому я собрал весь свой опыт в статье, чтобы помочь обойти те грабли, на которые так часто наступал — портал на Хабр. Чужой опыт, позволяет сформировать «карту граблей» и сэкономить силы. Мы с ребятами (авторами канала) готовы этим опытом делиться. Напомню, что завтра, 2 июля в 17:00 (MSK) · 20:00 (ALMT), мы проведем прямой эфир на тему «Как преуспеть на первой работе?» — подключайтесь, будет полезно🔥 @engineering_path

«Как преуспеть на первой работе?» Анонсируем наш первый прямой эфир в формате подкаста🚀 Расскажем о себе, пообщаемся на тему первой работы, проведём ретроспективу своего опыта и обсудим, что бы мы изменили в своих подходах к работе с учетом накопившихся знаний. В конце пообщаемся с вами и ответим на вопросы. Встречаемся 2 июля в 17:00 (MSK) · 20:00 (ALMT) в нашем TG-канале. @engineering_path

Хочу поделиться одной из лучших книг по продуктивности и тайм-менеджменту, которую мне доводилось читать. Примерно год назад я столкнулся с сильным выгоранием и полным ощущением неэффективности на работе и в сторонних проектах, которые тогда были. В какой-то момент я всё бросил, взял отпуск и улетел на отдых на 5 дней на перезагрузку, взяв с собой несколько книг из своего книжного бэклога, среди которых была и эта. Последующие 5 дней я провел на шезлонге за чтением, но именно в этой книге я словил очень большое количество инсайтов, которые отложились на подкорке и остаются со мной и по сей день. Вкратце — книга от двух ребят — бывших сотрудников Google, которые сами в какой-то момент искали продуктивный баланс среди изобилия работы, проектов и личной жизни, а главное — отвлекающих от всего этого факторов. Каждый из авторов высказывает свою субъективную позицию и их позиции не всегда сходятся в рассматриваемых кейсах/рекомендациях. За счет этого, на мой взгляд, книга получилась реально живой, как будто слушаешь читаешь подкаст. Думаю, я сделаю серию постов по этой книге с самым ценным, что отозвалось лично у меня. Для вас — полезный материал, для меня — мотивация снова пробежаться по ней и освежить в памяти всё забытое. Пока просто рекомендую её к прочтению😏 «Лишившись отвлечений, вы можете почувствовать, что вам скучно. Однако скука — это на самом деле хорошая вещь. Она дает вашему сознанию шанс поблуждать, а блуждание часто заводит в интересные места. В ходе двух не связанных друг с другом исследований специалисты из Пенсильванского университета и из Университета Центрального Ланкашира выявили, что скучающие испытуемые эффективнее справлялись с проблемами творческого характера, чем нескучающие. Так что в следующий раз, почувствовав, что вам уже несколько минут не хватает внешних раздражителей, просто посидите спокойно. Вам стало скучно? Считайте, что вам повезло!» @engineering_path

Be a programmer - problem solver / creator / innovator Многие “программисты” изучают один язык/фреймворк X и считают себя программистом X, не больше: iOS разработчик, Frontend разработчик на React, Backend разрботчик на Go и т.д. Не нужно ограничиваться одним high-level инструментом, будьте инженерами, которые решают сложные и интересные задачи, облегчают жизнь и в целом полезны обществу. Все эти высокоуровневые инструменты/языки очень быстро обновляются и устаревают, поэтому очень важно уметь изучать новые вещи, прокачивать problem solving навыки и знать основы, даже если тебе кажется что на работе это не потребуется. Да, нужно изучить один стек вглубь, но не ограничиваться только им 🙂 Более того, такие инженеры, которые знают смежный стек, очень хорошо ценятся и работают эффективнее. (Можете почитать комменты про T-shaped people тут). @engineering_path 👨‍💻🛣

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

Сегодня в 19:00 (по Москве) у моего руководителя лекция по многопоточке в iOS в Школе Мобильной Разработки Яндекса. Я был на финальном прогоне лекции, очень ценный материал, поэтому смело рекомендую) Моя лекция впереди, stay tuned🙃 https://youtube.com/live/quDU2ISqXZ0?feature=share @engineering_path

Прочитал книгу “Dive into Design Patterns” от refactoring.guru 📖 «Дизайн паттерны - это типичный способ решения какой-либо часто встречающейся проблемы, возникающей при проектировании програм.» В книге описывается 22 классических дизайн паттерна(Singleton, Factory, Facade, …). Причем все очень структурировано, с понятными иллюстрациями, примерами, аналогами из жизни и плюсами и минусами(это еще не все) и другие принципы проектирования(ООП, SOLID, Composition, …) После прочтения начинаешь чувствовать что такое красивое и хорошее решение в разработке, применять некоторые у себя в проектах. А если еще и прочитать книгу, о которой писали тут раньше, будет вообще отличное комбо 🚀 На самом деле мне ее советовали прочитать как только будет пол года опыта разработки, но я начал на пару лет позже 😁 Возможно из-за этого книга показалась интуитивно понятной и читалась легко. Но лично для себя взял много нового и более менее структурировал все знания. Есть чувство что нужно прочитать книгу еще раз, но уже более сконцентрировано, делая заметки или параллельно объясняя кому-то, чтобы понять все еще лучше. Советовал мне ее один из опытных инженеров, который успел побыть и тимлидом и engineering manager’ом в разных компаниях. Сейчас понимаю что он был прав и нужно было начинать книгу еще раньше. Имхо, отличная книга и для начинающих, и для опытных разработчиков. P.S. Да, книга платная, можно спиратить и найти бесплатную версию. Но настоятельно рекомендую купить ее(хотя бы вместе с кем-то) и поддержать автора. Ибо книга очень хорошо написана, переведена на разные языки и явно потребовала немало труда) @engineering_path

На днях дочитал “Чистый код” Роберта Мартина 🛀🏾 Собрал на странице в Notion список “запахов”, указывающих на загнивающий код, а так же приёмов и эвристических правил, которые помогут сделать ваш код чище. Не подразумевается, что эта страница заменит вам чтение книги. Скорее послужит шпаргалкой, к которой можно возвращаться после прочтения. Запахи и эвристические правила @engineering_path

Про планирование. Часть 1. Так уж вышло, что я по своей натуре – человек, помешанный на структуризации всего и вся. За последние 2-3 года у меня было несколько десятков попыток найти идеальный для себя подход к планированию, но как оказалось, наиболее важным оказался не используемый инструмент, а закладываемый принцип. Про принцип “разделяй и властвуй” не слышал разве что глухой, однако, очень немногие понимают его реальный смысл и умеют проецировать его на практику, хотя он отлично ложится на парадигму планирования. Суть в том, что сначала идёт определение долгосрочных планов, долгосрочные планы дают видение того, что необходимо сделать на более коротком интервале времени, и так вплоть до некой минимальной единицы измерения. Например, я привык считать верхнеуровневой границей чёткого планирования один месяц. Месяц разбивается на недели, в каждой из которых ставятся цели через призму целей на месяц. Недели разбиваются на дни, в каждом из которых ставятся цели через призму целей на неделю. Вообще, говоря про важность планирования – существует масса исследований, показывающих, что люди, регулярно занимающиеся планированием, достигают жизненных целей в разы чаще, чем те, кто "живёт моментом” и периодической мотивацией что-либо делать. Так что если вы ещё не начинали всерьез заниматься планированием, самое время начать. PS: Слышал, что некоторые способны ставить цели чуть ли не на десятилетия, но лично мне до такого уровня пока далеко🙃 @engineering_path