engineering path

An easy productivity hack — instead of spending time getting «in the mood» to work, just start working, confront the work. People think they need perfect conditions to start, when in reality, starting is the perfect condition.

«Money is not the root of all evil; there's nothing evil about it. But the lust for money is bad. The lust for money is not bad in a social sense. It's not bad in the sense of "you're a bad person for lusting for money." It's bad for you.

Lusting for money is bad for us because it is a bottomless pit. It will always occupy your mind. If you love money, and you make it, there's never enough. There is never enough because the desire is turned on and doesn't turn off at some number. It's a fallacy to think it turns off at some number.

The punishment for the love of money is delivered at the same time as the money. As you make money, you just want even more, and you become paranoid and fearful of losing what you do have. There's no free lunch.»

— The Almanack of Naval Ravikant

Синдром отложенного всего

Вот получу оффер в Google и стану счастливым. Вот релоцируюсь и начну путешествовать. Вот куплю квартиру, вот найду партнёра, вот закончу проект, вот, вот, вот… Сколько таких «вот» у каждого из нас?

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

«Существует обманчивое чувство, что твоя настоящая жизнь ещё не началась, что нынешняя реальность — лишь прелюдия к некоторому идеальному будущему. Этот идеал — всего лишь мираж, который по мере приближения будет рассеиваться, раскрывая, что прелюдия, через которую ты так спешил быстрее пройти, была, в действительности, прелюдией к твоей смерти»

«Do you actually want it, or do you want other people to see that you have it?»

Прокрастинация

Прокрастинация обычно зарождается из отсутствия ответов на один из двух вопросов (а иногда и на оба) — зачем и как.

Если нет ответа на вопрос зачем, мозг начинает искать что-нибудь «поважнее», лишь бы не тратить ресурсы на что-то с сомнительным профитом.

Выхода два — либо определить, в чём ценность активности и зачем тратить на неё время и ресурсы, либо уверенно задвинуть её куда подальше (честно говоря, ни разу не жалел о таком решении).

Если нет ответа на вопрос как, мозг начинает искать что-нибудь «полегче» — что-то, что он способен объять и воспринять. Мозг вообще любит простоту и структурированность, остальное его отпугивает размытой трудозатратностью. Поэтому хочешь съесть слона — определи, как его порезать и ешь по кусочкам.

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

Метеорит и кратер

Когда-то давно в Аризонской пустыне упал метеорит диаметром 50 метров, оставив за собой кратер, диаметром 1200 метров.

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

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

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

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

🤼 Мне для борьбы с такими отвлечениями помогают две вещи:

1. Полное отсутствие телефона в поле досягаемости и отключенные уведомления в период любой сосредоточенной деятельности, например, во время написания этого поста :)

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

Что убивает большие проекты?

Недавно вспомнил один случай из жизни. В начале второго курса в универе договорились с другом совместно сделать аппку.

Тогда на хайпе была тематика здоровья, отслеживание всяких метрик по сну, сердцебиению и так далее. В общем, решили прям полноценно залететь на рынок со своим приложением для трекинга сна. Проект был реально большим, по итогу у нас было два приложения — для iOS и WatchOS.

В iOS приложении можно было отслеживать всю статистику по последнему сну, сколько времени ты спал, в каких фазах сна находился (мы даже написали свой алгоритм определения фаз сна) и много всего другого.

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

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

Однако было два очень важных «но»:

1. Мы оба были крайне неопытными разрабами и написали всё без какой-либо расширяемой архитектуры и с кучей говнокода.

2. Мы оба не имели опыта запуска проектов, поэтому не понимали, как правильно это делать.

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

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

Так вот, две морали сей истории:

1. Сводите проект к инкрементальным улучшениям. И даже отдельные итерации ставьте иногда под сомнение!

2. Изначально не упарывайтесь излишне в архитектуру и чистоту кода. Сначала проверьте, что ваша гипотеза вообще работает. Сделайте MVP и раскатите его как можно быстрее на пользователей!

К слову, плоды этого урока я неоднократно пожинал и на работе. Нередко менеджеры, да и другие разрабы бывают теми ещё максималистами и хотят видеть в реализации проекта всё и сразу.

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

Время

Представим, что нам 18 лет, а проживём мы до 90. В таком случае, в нашем распоряжении есть чуть больше 800 месяцев (скрин 1).

Кажется, что это много, но на самом деле всё намного хуже. Цифры, конечно, среднестатистические, но суть передают отлично (скрин 2):

🛌 288 из них уйдут на сон
💼 126 — на работу и учёбу
🍽 36 — на еду и готовку
🛣 71 — на прочие активности по типу времени в дороге, гигиены и так далее

Сколько остаётся? Чуть больше 300 месяцев абсолютно свободного времени, что даже меньше половины от общего количества. И это если дожить до 90 лет. А что, если нам суммарно дано всего 70? 60? 50?

Такая математика даёт неожиданно понять, как мало времени у нас на то, чтобы заниматься чем-то по-настоящему значимым для себя.

Теперь немного статистики — среднестатистический 18-летний подросток в США тратит 93% этого самого свободного времени на экранное время (скрин 3).

Но в моей голове вопрос выходит далеко за пределы экранного времени:

• Не тратим ли мы это время на ненадёжных или безразличных нам людей?
• Не тратим ли мы его на то, чтобы действовать, думая о мнении тех, кому мы безразличны?
• Ну и всё же, точно ли 3 каждодневных часа листания рилсов — это то, что мы будем с теплом вспоминать завтра, смотря в прошлое?

📹 TED Talk

FOMO vs JOMO

Мы постоянно слышим о каких-то новых фреймворках и технологиях. Мы читаем статьи и посты, в которых нам упорно советуют, на чём нужно фокусироваться и что изучать.

Этот информационный поток бесконечен и нередко вызывает у нас чувство, называемое FOMO (the fear of missing out).

Что, если я изучаю не тот язык или фреймворк? Что, если я отстаю от трендов индустрии и мои знания вскоре окажутся невостребованными?🙉

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

Чтобы этому противостоять, следует вместо FOMO начать практиковать JOMO (the joy of missing out)🧘🏼‍♀️

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

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

📚 Ну и цитата из 14 Habits of Highly Productive Developers, которая, как мне кажется, актуальна в этом контексте:

«Say more «noes» so you can say «yes» to what really matters to you.»

Повышаем вероятность грейдапа или как написать грамотное performance review

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

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

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

Правильная структура такой оценки выглядит примерно следующим образом:

1. Цели

Начните performance review с описания того, какие цели ставились на оцениваемый период.

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

- Завершить проект X и раскатить его на 50% пользователей.
- Съездить на конференции Y и выступить с резюме перед командой.

2. Описание результатов

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

- 26 сентября запустил проект Х — на 3 недели раньше запланированного срока.

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

3. Планы

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

Это показатель компетентности, способности планировать и видеть точки роста у себя и в продукте.

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

If you do not ask for or talk about that promotion with your manager, do not expect to get it.

📹 Классный видос по теме — клик.

Когда вы последний раз испытывали чувство скуки?

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

Сказал он примерно следующее: «Вспомни, как в детстве, когда тебе было нечем заняться, а условного инстаграма, чтобы в любой момент себя отвлечь, не было, ты мог просто скучать, смотреть в потолок, думать о чём-то своём и мечтать... Я вот недавно задумался и понял, что даже вспомнить не могу, когда у меня последний раз такое было».

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

Эта мысль так жестко впечаталась мне в подсознание, что я стал стараться намеренно давать себе время на то, чтобы поскучать и побыть наедине со своими мыслями — не слушать иногда музыку за рулём, не залипать в телефон в транспорте, в зале и так далее.

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

Вот цитата на эту тему из книги «Найди время», которую я когда-то рекомендовал в одном из постов:

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

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 привычек, свойственных тем высокоэффективным разрабам, с которыми ему доводилось пересекаться и общаться.

📚 Ссылка на книгу

Интересное про деньги

Результат онлайн-опроса, проведенного американской психологической ассоциацией, показал, что 9 из 10 респондентов считают, что для приобретения «финансового благополучия», им необходимо увеличение материального достатка примерно вдвое.

Однако интересная деталь заключается в том, что подобное мышление не имело корреляции с текущим доходом респондента — люди, зарабатывающие 1.000$ в месяц считают, что для счастья им необходимо зарабатывать 2.000$, а люди с доходом в 50.000$, что 100.000$ — это тот самый недостающий винтик душевного и финансового спокойствия.

Означает ли это, что фундаментальная проблема несчастья на самом-то деле не настолько связана с деньгами?

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

1. Успешный семейный союз
2. Родственные и дружеские отношения
3. Ощущение жизни — в смысле ощущения своего интеллектуального, духовного и физического развития.

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

Пишем грамотное 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

Портрет сильного инженера

Недавно послушал посмотрел подкаст с Шамилем Арсунукаевым, проработавшим более 17 лет в Кремниевой Долине в качестве инженера и engineering-менеджера. В целом подкаст просто топ, очень рекомендую послушать.

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

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

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

Второй пункт куда интереснее. Часто разработка, особенно, если речь идёт про большой продукт, усложняется барьерами, выходящими далеко за пределы написания кода, а значит, нужны и дополнительные навыки.

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

Кроме того, чтобы по-настоящему привносить значимый business/project impact, необходимо самому иметь продуктовый вижн. Как пример, я на работе сталкивался с необходимостью предлагать продукту альтернативный подход к составу MVP проекта для того, чтобы найти компромисс между сроками разработки и функциональностью продукта.

И вся вот эта основная мысль, на мой взгляд, переплетается с одним крайне важным тезисом, который упоминался в этом посте — «You’re not a programmer, you’re a problem solver».

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

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

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

Вкратце — книга от двух ребят — бывших сотрудников Google, которые сами в какой-то момент искали продуктивный баланс среди изобилия работы, проектов и личной жизни, а главное — отвлекающих от всего этого факторов. Каждый из авторов высказывает свою субъективную позицию и их позиции не всегда сходятся в рассматриваемых кейсах/рекомендациях. За счет этого, на мой взгляд, книга получилась реально живой, как будто слушаешь читаешь подкаст.

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

Как развиваться на работе? Про людей

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

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

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