engineering path

🎙 Начинаем эфир сегодня, через 4 часа!

Коллеги, горим, но не сгораем

У вас бывает такое, что какие-то периоды жесткая прокрастинация на работе и вроде работаешь, но ничего не делаешь по факту полезного?

— такой вопрос недавно задал мой друг, и мне было что ответить, ведь сам недавно проходил подобное. Решил поделиться, вдруг будет полезно еще кому: 1. Вообще чекни, всё ли ок с тобой. Может нужен отдых или поменялись приоритеты, дай себе время задать вопросы и поискать ответы. Они могут не придти сразу, однако процесс будет запущен. 2. Есть статейка, в ней разбирают почему мы прокрастинируем, нужно ли бороться с прокрастинацией и как и от неё збавиться. Если понимаешь что откладываешь важное дело до последнего или заставляешь себя работать через силу — почитай, мне помогло разобраться. 3. Как я для себя в последний раз искал мотивацию. Посмотрел на работу через призму навыков, которые хочу развивать. Например — хочу лучше научиться планировать, хочу выступить с докладом, научиться закрывать более сложные проекты и тд. Далее понял как и через какие задачи я могу улучшать свои навыки. Тем самым работа становится не просто действием от слова work, а возможностью прокачать и улучшить меня. И это останется со мной навсегда, нежели просто код или проект, который нужен менеджеру/компании. 4. Реализовывать себя можно не только через работу. Об этом мне часто напоминала моя девушка, о чем хочу сказать и тебе. Возможно ты что-то хотел давно начать, вспомни хобби/проекты или идеи, которые цепляли. Сделай первый шаг к ним — это начало может тебе дать больше смысла и энергии. ━━━━━━ Такие моменты обязательно проходят, но полезно записывать и отмечать какие действия помогали пройти этот этап. Уверен, что каждому есть чем поделиться — предлагаю накидать в комментарии свои способы борьбы с модным выгоранием. @engineering_path

🎙 Публичное мок-интервью по алгоритмам! Совсем скоро мы на канале проведём алгоритмическое мок-интервью, которое пройдёт полностью в формате реального собеседования в компании. Поможет нам в этом Амиржан Армандиев — Software Engineer в Yandex Go. Мы покажем, как проходят алгоритмические собеседования, порешаем задачи, а также поделимся важными советами для прохождении алго-собесов. ⏳ Встречаемся в воскресенье, 16 декабря, в 20:00 (ALMT) • 17:00 (MSK) в этом ТГ-канале. @engineering_path

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

Осознанность принятия технических решений На данный момент я единственный iOS разработчик в команде. Руководитель/CTO - с бэкграундом бэкендера, очень интересный человек. Мы часто обсуждаем с ним часть мобильных приложений(iOS/Android): архитектуру, UI, взаимодействие с бэкендом и тд. Учитывая его опыт в разработке и мой в мобилке, пытаемся прийти к общему решению. Очень нравится его осознанный подход к разработке. Перед тем как принять решение, он все хорошо обдумывает, старается мыслить нестандартно и сравнивать разные решения. Недавно мы начали переписывать сетевой слой приложения и часами все обсуждали, перед тем как приступить к написанию кода. Заметил одну вещь - он всегда задается вопросом “А нам это действительно нужно?” и пытается максимально упростить решение. Он не принимает решения, основываясь на том что это какой-то best practice, или потому что так сказал какой-то сеньор, а пытается понять, почему то или иное решение является самым подходящим и оптимальным для конкретной решаемой задачи. Возможно, понимание всей сути каждого принятого решения может затормозить разработку и занять много времени, но в целом нужно иметь представление о том, что ты делаешь и зачем. На мой взгляд, именно такой подход приводит к более фундаментальному развитию инженера. @engineering_path

Когда вы последний раз... испытывали чувство скуки? Года полтора назад я сидел на обеде с одним коллегой, и в процессе общения он выразил одну интересную мысль, которая в тот момент взорвала мой мозг. Эту мысль я до сих пор проношу через свою жизнь, стараясь дисциплинировать себя в каких-то вещах. Спросил он примерно следующее: «Вспомни, как в детстве, когда тебе было нечем заняться, а условного инстаграма, чтобы в любой момент себя отвлечь, не было, ты мог просто скучать, смотреть в потолок, думать о чём-то своём и мечтать... Я вот недавно задумался и понял, что даже вспомнить не могу, когда у меня последний раз такое было». К своему сильному удивлению, я быстро осознал, что тоже не могу вспомнить, когда я осознанно или неосознанно давал своему мозгу свободное время, полное отстранённых размышлений и мечтаний. Я стал слишком расчетливым для того, чтобы о чём-то мечтать и слишком занятым для того, чтобы смотреть в потолок, вот только любые промежутки между интеллектуальными процессами заполнялись отвлечениями — музыка, инста и тому подобное. Эта мысль так жестко впечаталась мне в подсознание, что я стал стараться намеренно давать себе время на то, чтобы поскучать и побыть наедине со своими мыслями — не слушать иногда музыку за рулём, не залипать в телефон в транспорте и так далее. К слову, научные исследования показали, что ощущение скуки приводит к повышению эффективности в решении проблем творческого характера. Вот цитата на эту тему из книги «Найди время», которую я когда-то рекомендовал в одном из постов:

Лишившись отвлечений, вы можете почувствовать, что вам скучно. Однако скука — это на самом деле хорошая вещь. Она дает вашему сознанию шанс поблуждать, а блуждание часто заводит в интересные места. В ходе двух не связанных друг с другом исследований специалисты из Пенсильванского университета и из Университета Центрального Ланкашира выявили, что скучающие испытуемые эффективнее справлялись с проблемами творческого характера, чем нескучающие. Так что в следующий раз, почувствовав, что вам уже несколько минут не хватает внешних раздражителей, просто посидите спокойно. Вам стало скучно? Считайте, что вам повезло!

@engineering_path

Practice makes perfect

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

"втереть"

полученные знания в свои пальцы, глаза и внутренности усердной

работой и практикой.

(с) Роберт Мартин

Практика всегда лучше теории. Вы можете изучить физику езды на велосипеде, но все равно упадете при первой езде на велосипеде. ✅ Когда ты проходишь туториалы, ты получаешь дофамин из-за того что посмотрел видосы, узнал что-то новое, решил задачку. На туториалах дают какие-то задачи, но скорее всего большинство просто копирует решение и исходный код будет настроен, который ты просто спуллил с гитхаба. Проблема в том что просматривая туториалы можно приобрести не так много практичных знаний. 🛠 Значительно более ценные знания приходят через активное освоение материала. Когда вы "втираете" полученные знания, активно применяя их, происходит настоящий процесс обучения. Например, в процессе изучения iOS-разработки я прошел два курса с заданиями, но настоящий прогресс начался, когда я столкнулся с проектом, где не было готового решения. Только тогда я научился писать код, гуглить и использовать свои знания на практике. 📚 Просмотр туториалов оправдан, если вы начинаете с нуля, но важно не застревать на этом этапе и постепенно переходить к практике. Кроме того, опытные разработчики советуют заниматься собственными проектами, нарабатывая практический опыт для более быстрого развития. Книги, видео и статьи полезны в долгосрочной перспективе. 💎 Здесь мы собрали полезные материалы и задания для практики в различных областях (iOS, Android, Front-end, Backend) Отправьте друзьям и знакомым, которым не помешает практика 😉 @engineering_path

🎤 Начинаем наш эфир через час!

14 habits of highly productive developers Недавно дочитал классную книгу — «14 habits of highly productive developers», которую мне когда-то порекомендовал мой ментор, теперь пришел мой черёд поделиться ею. В книге автор попытался поисследовать, почему одни разработчики только и успевают, что закрывать рабочие таски и ни на что другое у них не остаётся ни времени, ни ресурсов, а другие не только продуктивны в рамках работы, но ещё и успевают заниматься различными активностями вне — выступают на конференциях, пишут pet-проекты, самообразовываются, ещё и на отдых и личную жизнь времени хватает. Для того, чтобы разобраться в вопросе, автор не только поделился своим опытом наблюдений за такими людьми, но и пообщался с другими разрабами из BigTech компаний, задавая им вопросы, что, на мой взгляд, сделало книгу более объективной и богатой на инсайты. К слову, текст для недавнего поста был взят именно из неё. Основной вывод автора в том, что секрет продуктивности заключается в правильных привычках, которыми эти самые продуктивные разработчики обладают. Сила привычек и вообще влияние подсознания на наши результаты, сильно недооценены. Цитата из книги Atomic Habits на эту тему: «Habits are the compound interest of self-improvement. The same way that money multiplies through compound interest, the effects of your habits multiply as you repeat them. They seem to make little difference on any given day and yet the impact they deliver over the months and years can be enormous. It is only when looking back two, five, or perhaps ten years later that the value of good habits and the cost of bad ones becomes strikingly apparent.» Собственно, в самой книге автор описывает 14 привычек, свойственных тем высокоэффективным разрабам, с которыми ему доводилось пересекаться и общаться. Так что читайте и забирайте то, что подходит конкретно вам🎯 📚 Ссылка на книгу @engineering_path

Вы ждали, а мы сделали! 🎙 Рады анонсировать вам наш новый прямой эфир, в котором мы пообщаемся с Аскаром Сатабалдиевым (@myegothings) — ex Head of SDU Technopark, ex Software Engineer at Booking, Amazon, Meta. На прямом эфире мы пообщаемся с Аскаром про его опыт преподавательской деятельности и опыт в MAANG, а также постараемся ответить на вопрос — что делать молодым специалистам с учетом кризиса на рынке IT. ⏳ Встречаемся 16 ноября в 20:00 (ALMT) • 17:00 (MSK) в этом ТГ-канале. @engineering_path

«Working 40-50 hours per week is a pretty significant time investment in your life, so it’s very important that you’re satisfied with your current job, regardless of the pay, or how far along you are on some career ladder.»

Интересное про деньги Результат онлайн-опроса, проведенного американской психологической ассоциацией, показал, что 9 из 10 респондентов считают, что для приобретения «финансового благополучия», им необходимо увеличение материального достатка примерно вдвое. Однако интересная деталь заключается в том, что подобное мышление не имело корреляции с текущим доходом респондента — люди, зарабатывающие 1.000$ в месяц считают, что для счастья им необходимо зарабатывать 2.000$, а люди с доходом в 50.000$, что 100.000$ — это тот самый недостающий винтик душевного благополучия. Означает ли это, что фундаментальная проблема несчастья на самом-то деле не настолько связана с деньгами? Результаты другого исследования показали, что в действительности корреляция между деньгами и счастьем очень низка, а наибольшее ощущение жизненного удовлетворения доставляют: 1. Успешный семейный союз 2. Родственные и дружеские отношения 3. Ощущение жизни — в смысле ощущения своего интеллектуального, духовного и физического развития. Мой инсайт последних нескольких дней в том, что деньги — не более, чем инструмент, которым нужно уметь грамотно управлять и приумножать для того, чтобы обеспечивать себе бóльшую независимость и свободу выбора, однако, как только ты начинаешь закладывать в них нечто большее и начинать базировать на них своё понимание жизненного благополучия, как на главном факторе, ты вступаешь в вечные крысиные бега, счастья в которых найти будет невозможно.

Генерируем полезные мысли 🧠 Не секрет что каждый день приходят и уходят разные мысли. На самом деле, в большинстве случаев от Вас зависит какие мысли генерируются вашим мозгом. Где-то пишут что это число, количество мыслей в сутки, варьируется от 7000 до 8000, где-то около 80000. Можно смотреть на эти мысли как на финансы, которые можно инвестировать и получать дивиденды. Попробую объяснить на примере карьеры, но имхо можно применять для любой сферы жизни. Есть, например, программист который когда-то в будущем хочет стать сеньором в ФААНГЕ и зарабатывать хорошо. Но эта его цель стать сеньором - она не конкретная, где-то далеко в подсознании, всплывает только когда его спрашивают о его целях. Давайте посмотрим на то, как он инвестирует свои мысли и энергию. Если в основном тратить энергию на разные непонятные вещи, не очень полезный сёрфинг браузера и прочее, то и «дивиденды» он получит соответственные. Мысли, которые его мозг генерирует, будут скорее всего такие же, не очень полезные. НО, если хотя бы какую-то часть «портфеля» вкладывать в развитие, вспоминать свои цели(которые конкретные, с четким результатом и дедлайном), то и мозг будет соответственно генерировать полезные мысли, которые помогают так или иначе достичь этой вашей цели. Чем больше инвестируешь в определенную сферу, тем больше генерируются «дивиденды». У меня бывало такое что во сне приходили новые идеи для некоторых проектов или решения задач. P.S. Диверсификация в инвестициях очень важна. Не забываем правильно отдыхать и восстанавливаться 😉 @engineering_path

Engineering Life Path. @engineering_path

Разработка мобильных приложений недооценена Интересное наблюдение, которое мне довелось провести за время работы заключается в том, что разработка мобильных приложений — одно из самых недооцененных с точки зрения сложности направлений в индустрии. Многие люди (разработчики других специальностей, менеджеры, аналитики и т.п.), не погружённые глубоко в эту область, считают, что мобильное приложение — это этакая Figma на стероидах, и его разработка, поддержка и развитие требуют куда меньше знаний, навыков и ресурсов, нежели, например, бэкенд (хотя что там кнопки красить, что тут json-ы перекладывать). Выливается это в постоянное непонимание того, почему та или иная фича, доработка или техдолг могут занимать «так много времени»😑 ❓ К чему я? Недавно книгу дочитал на эту тему и хочу её порекомендовать. ❓ Кому? Всем, кто сталкивается на своей работе с мобильной разработкой — продактам, проджектам, бэкендерам, ну и самим мобильным разработчикам, разумеется. ❓ Что за книга? Building Mobile Apps at Scale: 39 Engineering Challenges 📖 @engineering_path

Пишем грамотное CV Написать резюме сложно. Написать грамотное резюме ещё сложнее, особенно, если не следовать советам людей, находящихся «по ту сторону», т.е. оценивающих эти самые резюме. Недавно сам занимался составлением резюме и потратил много времени на ресёрч того, как всё-таки правильно это сделать. Пришло время поделиться несколькими наиболее важными тезисами, ну и ресурсами, конечно✍️ 1. Правило 10 секунд С детства нас учили тому, что нельзя судить по первому впечатлению. Так вот, забудьте. У hiring manager-а скорее всего нет времени на то, чтобы пытаться познать вашу невероятную внутреннюю красоту и скрытые таланты, резюме должно чётко и быстро дать понять, кто вы и что из себя представляете (стек, опыт, образование, достижения). • «It should be clear that you are a strong developer for the targeted role within the first few moments of reading your resume. If it is not strong, you need to rephrase your resume» 2. Показывать, а не рассказывать Важно писать не только о том, что именно вы сделали, но и какой у этого бэкграунд — какая стояла задача, какие технологии вы использовали и какой impact это дало команде или продукту. Сравните сами два пункта, написанных вроде бы про одно и то же, но дающих совершенно разное восприятие опыта: • «Implemented Carraform v2.0 and launched to Prexo SpringSuite» • «Developed a server-side layout engine in iOS by teaching myself GoLang to automate 1000+ antiquated manual layouts. Working with a coworker, this began as an ambiguous project that I drove to completion and launched company-wide» То же самое касается и личных качеств. Резюме — не набор фактов, это история, строящая картину того, что вы из себя представляете. Если у вас есть талант к комуникации, не надо об этом писать, покажите это, рассказав связанную с этим историю: • «Mentored a team through weekly presentations, leading to the adoption of the ViewModel pattern in the codebase» 3. Less is more Сделайте фокус на наиболее интересных и релевантных проектах и опыте. Не нужно пытаться поместить в резюме каждый свой чих. Как я слышал от hiring manager-а, любое резюме размером более 2 страниц практически наверняка идёт в мусорку. В идеале — одна страница, в редких случаях — две. • «If you have less than 10 years of experience, you have less than 2 pages of content. If you have more than 10 years of experience, you know how to summarize into 2 pages of content» Пост уже получился длинным, а тонкостей в написании резюме ещё не мало. Так что, как и обещал, делюсь ресурсами, где можно почитать (или даже послушать) про это подробнее: — Статья от Engineering Manager-а (очень советую почитать комментарии под статьёй) — Подкаст с Engineering Manager-ом, таймлайн про резюме — Resume Workshop от Ex-Google Tech Lead @engineering_path

📝 Очень важно записывать все что вы делаете на работе. Для чего это нужно? 1️⃣ Во первых, это точно понадобится при обновлении резюме 💼 Велика вероятность забыть всю проделанную работу. Возможно вы и вспомните некоторые фичи, но при логировании работы у вас будут точные детали и статистика по каждой задаче, которую вы закрыли. И в резюме можно будет добавить самые важные и “сочные” работы в деталях, которые вы успели сделать 😁 2️⃣ Повышение 💲 Независимо от того, есть у вас на работе ревью или нет, можно будет пройтись по вашему списку задач и собрать веские аргументы для того чтобы вас повысить и увеличить зарплату. Опять же, без такого списка задач это тоже можно сделать. НО, вам нужно будет вспоминать все детали(А все точно не вспомнишь) и напрягать мозг для этого. А так, у вас будет готовый документ по которому просто нужно пройтись и собрать самые интересные работы. 3️⃣ Подготовка к Behavioral Interview 👨‍💻 Обычно на поведенческих(behavioral) собеседованиях хотят узнать прошлый опыт, оценивают, как кандидат сравлялся с конкретными ситуациями и использовал свои навыки. При наличии такого списка работы будет легче подготовить ответы под каждый из кейсов/вопросов, основываясь на прошлом опыте и проделанной работе. Ну и в целом такие логи помогают в будущем заглянуть в прошлое и узнать о своем прогрессе. @engineering_path

Портрет сильного инженера Недавно послушал посмотрел подкаст с Шамилем Арсунукаевым, проработавшим более 17 лет в Кремниевой Долине в качестве инженера и engineering-менеджера. В целом подкаст просто топ, очень рекомендую послушать. Одной из обсуждаемых тем, отозвавшихся лично у меня, был портрет сильного инженера, и в этом контексте были упомянуты две важные черты, ему присущие: 1. Высокий уровень технических скиллов 2. Умение добиваться результата несмотря на сложности, выходящие за рамки написания кода Первый пункт в целом понятен, хочешь быть классным разработчиком — будь технически подкован, особенно в своём стеке. Второй пункт куда интереснее. Часто разработка, особенно, если речь идёт про большой продукт, усложняется барьерами, выходящими далеко за пределы написания кода, а значит, нужны и дополнительные навыки. Например, необходимо умение общаться с людьми из других команд и специальностей, стоящих за продуктом — продакт менеджерами, аналитиками, дизайнерами и так далее, только у этих людей зачастую бывают ответы на вопросы, блокирующие продвижение команды в проекте. Кроме того, чтобы по-настоящему привносить значимый business/project impact, необходимо самому иметь продуктовый вижн. Как пример, я на работе сталкивался с необходимостью предлагать продукту альтернативный подход к составу MVP проекта для того, чтобы найти компромисс между сроками разработки и функциональностью продукта. И вся вот эта основная мысль, на мой взгляд, переплетается с одним крайне важным тезисом, который упоминался в этом посте — «You’re not a programmer, you’re a problem solver». Любая задача — это решение какой-то проблемы, зачастую пользовательской или бизнесовой, и чтобы быть действительно сильным и классным инженером, важно быть многогранным и выходить за рамки базового умения писать код. @engineering_path

Программисты не пишут код Я часто слышал, что в крупных корпорациях у инженеров много времени уходит на документацию, на дизайн доки, обсуждение решения и прочее. Мне всегда казалось, что это пустая трата времени. Недавно на работе застрял на одной задаче. Когда рассказал это ментору во время 1 х 1 созвона, он попросил меня объяснить задачу и начать рисовать все в draw.io. В итоге, посоветовав пару улучшений (ему минут через 20 нужно было идти), он дал мне задание — дорисовать все решение, ответить на все открытые вопросы и только после этого садиться кодить. В итоге я потратил, наверное, полный рабочий день на этот систем дизайн. По ходу рисования были моменты когда улучшал решения, закрывал небольшие сабтаски и отвечал на вопросы. После того как все задизайнил (на скриншоте не финальная версия), сел кодить. Исправив мелкие ошибки, все скомпилировал и удалось закрыть задачу быстро. Еще один из инженеров советовал (автор этой книги) всегда придумывать два решения для любой задачи. И тут до меня дошло, что большую часть времени нужно продумывать красивое решение. Если начинать реализовывать первое решение, которое пришло в голову, велика вероятность написать говнокод, который в будущем будет сложно отрефакторить и поддерживать. Вообще обычно бывает три состояния задач: 1) Понятно как решать 2) Не знаешь решение 3) Не знаешь, что ты не знаешь :) Задачи первого типа ты просто решаешь, про второго типа задачи спрашиваешь у других или гуглишь. А из-за задач третьего типа и бывают такие застои. И такое объяснение, т.е. зарисовка решения всей задачи и помогает выявить задачи третьего типа и перевести в первую или вторую. В конечном счете, не стоит садиться писать код, если существует очень много неопределенности. Лучше все продумать, попробовать придумать несколько решений на бумаге и только после этого писать код. @engineering_path