Вот у всех есть такие знакомые и друзья — Abstract<Петя>.
Петя работает в IT — развивает стартап. Хорошо зарабатывает и считается профессионалом в своём деле. А ещё у Пети свой профессиональный блог, он, может, и не массовый, но в профессиональной среде его знают. Ещё у Пети есть свой курс, параллельно он успевает путешествовать, постоянно учиться, медитировать, конечно, и развивать несколько пет-проектов: делает подкаст, телеграм-бот и чего только не делает. В списке его достижений много классных строчек. Ну и конечно, Пете 22 года и он сын маминой подруги. Очень много тревожных моментов случается, когда мы сравниваем своё начало с чьим-то результатом в текущем моменте.
Если замечаете это за собой — рекомендую эту статью
Петя работает в IT — развивает стартап. Хорошо зарабатывает и считается профессионалом в своём деле. А ещё у Пети свой профессиональный блог, он, может, и не массовый, но в профессиональной среде его знают. Ещё у Пети есть свой курс, параллельно он успевает путешествовать, постоянно учиться, медитировать, конечно, и развивать несколько пет-проектов: делает подкаст, телеграм-бот и чего только не делает. В списке его достижений много классных строчек. Ну и конечно, Пете 22 года и он сын маминой подруги. Очень много тревожных моментов случается, когда мы сравниваем своё начало с чьим-то результатом в текущем моменте.
Если замечаете это за собой — рекомендую эту статью
Кинжал
Чувствую, что отстаю от своих многозадачных, всё успевающих и энергичных знакомых — Кинжал
Вот Петя. Петя работает в IT — развивает стартап. Он хорошо зарабатывает и считается профессионалом в своём деле.
❤9👍3🔥1
Как развиваться на работе? Про людей
Когда речь заходит про развитие на работе, многие думают, что развиваться можно только за счёт реализации сложных задач. Доля правды в этом, есть, но мне кажется, влияние на нас коммуникации с окружающими часто недооценивается, хотя в действительности самый ценный ресурс — это люди вокруг, нужно только не бояться перенимать у них их знания. Проще говоря, для роста крайне важно быть в постоянном режиме впитывающей губки.
В первую очередь это, конечно, касается вашего руководителя. Исходя из своего опыта могу сказать, что руководитель с большой долей вероятности будет заинтересован в вашем росте, а следовательно, будет готов вложить в вас свои знания и опыт, если увидит, что вы к этому стремитесь, так что не стесняйтесь цепляться за эту возможность.
Кроме того, не скупитесь на общение с коллегами из других направлений. Если вы разработчик, регулярно общайтесь с людьми из продукта или менеджмента, это даст вам возможность перенимать их видение — не забывайте, что профессионально расти надо не только вглубь, но и вширь.
Когда речь заходит про развитие на работе, многие думают, что развиваться можно только за счёт реализации сложных задач. Доля правды в этом, есть, но мне кажется, влияние на нас коммуникации с окружающими часто недооценивается, хотя в действительности самый ценный ресурс — это люди вокруг, нужно только не бояться перенимать у них их знания. Проще говоря, для роста крайне важно быть в постоянном режиме впитывающей губки.
В первую очередь это, конечно, касается вашего руководителя. Исходя из своего опыта могу сказать, что руководитель с большой долей вероятности будет заинтересован в вашем росте, а следовательно, будет готов вложить в вас свои знания и опыт, если увидит, что вы к этому стремитесь, так что не стесняйтесь цепляться за эту возможность.
Кроме того, не скупитесь на общение с коллегами из других направлений. Если вы разработчик, регулярно общайтесь с людьми из продукта или менеджмента, это даст вам возможность перенимать их видение — не забывайте, что профессионально расти надо не только вглубь, но и вширь.
🔥13👏3⚡2
Хочу поделиться одной из лучших книг по продуктивности и тайм-менеджменту, которую мне доводилось читать.
Примерно год назад я столкнулся с сильным выгоранием и полным ощущением неэффективности на работе и в сторонних проектах, которые тогда были. В какой-то момент я всё бросил, взял отпуск и улетел на отдых на 5 дней на перезагрузку, взяв с собой несколько книг из своего книжного бэклога, среди которых была и эта. Последующие 5 дней я провел на шезлонге за чтением, но именно в этой книге я словил очень большое количество инсайтов, которые отложились на подкорке и остаются со мной и по сей день.
Вкратце — книга от двух ребят — бывших сотрудников Google, которые сами в какой-то момент искали продуктивный баланс среди изобилия работы, проектов и личной жизни, а главное — отвлекающих от всего этого факторов. Каждый из авторов высказывает свою субъективную позицию и их позиции не всегда сходятся в рассматриваемых кейсах/рекомендациях. За счет этого, на мой взгляд, книга получилась реально живой, как будтослушаешь читаешь подкаст.
Думаю, я сделаю серию постов по этой книге с самым ценным, что отозвалось лично у меня. Для вас — полезный материал, для меня — мотивация снова пробежаться по ней и освежить в памяти всё забытое. Пока просто рекомендую её к прочтению.
Примерно год назад я столкнулся с сильным выгоранием и полным ощущением неэффективности на работе и в сторонних проектах, которые тогда были. В какой-то момент я всё бросил, взял отпуск и улетел на отдых на 5 дней на перезагрузку, взяв с собой несколько книг из своего книжного бэклога, среди которых была и эта. Последующие 5 дней я провел на шезлонге за чтением, но именно в этой книге я словил очень большое количество инсайтов, которые отложились на подкорке и остаются со мной и по сей день.
Вкратце — книга от двух ребят — бывших сотрудников Google, которые сами в какой-то момент искали продуктивный баланс среди изобилия работы, проектов и личной жизни, а главное — отвлекающих от всего этого факторов. Каждый из авторов высказывает свою субъективную позицию и их позиции не всегда сходятся в рассматриваемых кейсах/рекомендациях. За счет этого, на мой взгляд, книга получилась реально живой, как будто
Думаю, я сделаю серию постов по этой книге с самым ценным, что отозвалось лично у меня. Для вас — полезный материал, для меня — мотивация снова пробежаться по ней и освежить в памяти всё забытое. Пока просто рекомендую её к прочтению.
❤19👍5🔥2
Про первый опыт стажировки
Я выходил из офиса после 12 ночи, постоянно прибывал в тревоге и боялся признаться, что я чего-то не знаю — так начиналась моя первая стажировка. Казалось, что такая проблема только у меня. При этом вокруг были коллеги, у которых хватало времени на себя, хобби, обучение и т. д.
Сравнение с другими никогда не идет на пользу, и я начал искать способы, как справляться с большой нагрузкой проще. Пробовал всем знакомые техники тайм-менеджмента: расписывал распорядок дня, разбивал задачи на маленькие шаги и выделял главное, используя правило 20/80. Многое из этого давало результат, но…
К чему я это — на поиск и проверку лайфхаков уходит время, я был бы рад сэкономить его на старте и сейчас хочу помочь в этом другим. Поэтому я собрал весь свой опыт в статье, чтобы помочь обойти те грабли, на которые так часто наступал — портал на Хабр.
Я выходил из офиса после 12 ночи, постоянно прибывал в тревоге и боялся признаться, что я чего-то не знаю — так начиналась моя первая стажировка. Казалось, что такая проблема только у меня. При этом вокруг были коллеги, у которых хватало времени на себя, хобби, обучение и т. д.
Сравнение с другими никогда не идет на пользу, и я начал искать способы, как справляться с большой нагрузкой проще. Пробовал всем знакомые техники тайм-менеджмента: расписывал распорядок дня, разбивал задачи на маленькие шаги и выделял главное, используя правило 20/80. Многое из этого давало результат, но…
К чему я это — на поиск и проверку лайфхаков уходит время, я был бы рад сэкономить его на старте и сейчас хочу помочь в этом другим. Поэтому я собрал весь свой опыт в статье, чтобы помочь обойти те грабли, на которые так часто наступал — портал на Хабр.
Хабр
Сложно, но можно — стажировка в Яндекс Go
Впереди новый сезон стажировок, и статья будет актуальна для тех, кто планирует начать карьеру в Яндексе. Я Максим, iOS-разработчик в службе технического развития Яндекс Go. В декабре 2021 года...
❤13🔥5👍3
В понедельник, 10 июля, в 19:00 (Мск) пройдёт моя лекция по Combine в Академии Яндекса.
Присоединяйтесь к трансляции!
https://www.youtube.com/watch?v=pO5vZdS__xs
Присоединяйтесь к трансляции!
https://www.youtube.com/watch?v=pO5vZdS__xs
YouTube
Combine. Продвинутая архитектура (реактивное программирование)
Лектор - Анас Бен Мустафа, Разработчик клиентского продукта Доставки.
В рамках лекции мы рассмотрим реактивный фреймворк Combine и посмотрим на то, как он позволяет облегчить работу с асинхронными событиями в приложении, делая код более эффективным и масштабируемым.
В рамках лекции мы рассмотрим реактивный фреймворк Combine и посмотрим на то, как он позволяет облегчить работу с асинхронными событиями в приложении, делая код более эффективным и масштабируемым.
🔥12❤3👍2
Программисты не пишут код
Я часто слышал, что в крупных корпорациях у инженеров много времени уходит на документацию, на дизайн доки, обсуждение решения и прочее. Мне всегда казалось, что это пустая трата времени.
Недавно на работе застрял на одной задаче. Когда рассказал это ментору во время 1 х 1 созвона, он попросил меня объяснить задачу и начать рисовать все в draw.io.
В итоге, посоветовав пару улучшений (ему минут через 20 нужно было идти), он дал мне задание — дорисовать все решение, ответить на все открытые вопросы и только после этого садиться кодить. В итоге я потратил, наверное, полный рабочий день на этот систем дизайн. По ходу рисования были моменты когда улучшал решения, закрывал небольшие сабтаски и отвечал на вопросы.
После того как все задизайнил (на скриншоте не финальная версия), сел кодить. Исправив мелкие ошибки, все скомпилировал и удалось закрыть задачу быстро.
Еще один из инженеров советовал (автор этой книги) всегда придумывать два решения для любой задачи.
И тут до меня дошло, что большую часть времени нужно продумывать красивое решение. Если начинать реализовывать первое решение, которое пришло в голову, велика вероятность написать говнокод, который в будущем будет сложно отрефакторить и поддерживать.
Вообще обычно бывает три состояния задач:
1) Понятно как решать
2) Не знаешь решение
3) Не знаешь, что ты не знаешь :)
Задачи первого типа ты просто решаешь, про второго типа задачи спрашиваешь у других или гуглишь.
А из-за задач третьего типа и бывают такие застои. И такое объяснение, т.е. зарисовка решения всей задачи и помогает выявить задачи третьего типа и перевести в первую или вторую.
В конечном счете, не стоит садиться писать код, если существует очень много неопределенности. Лучше все продумать, попробовать придумать несколько решений на бумаге и только после этого писать код.
Я часто слышал, что в крупных корпорациях у инженеров много времени уходит на документацию, на дизайн доки, обсуждение решения и прочее. Мне всегда казалось, что это пустая трата времени.
Недавно на работе застрял на одной задаче. Когда рассказал это ментору во время 1 х 1 созвона, он попросил меня объяснить задачу и начать рисовать все в draw.io.
В итоге, посоветовав пару улучшений (ему минут через 20 нужно было идти), он дал мне задание — дорисовать все решение, ответить на все открытые вопросы и только после этого садиться кодить. В итоге я потратил, наверное, полный рабочий день на этот систем дизайн. По ходу рисования были моменты когда улучшал решения, закрывал небольшие сабтаски и отвечал на вопросы.
После того как все задизайнил (на скриншоте не финальная версия), сел кодить. Исправив мелкие ошибки, все скомпилировал и удалось закрыть задачу быстро.
Еще один из инженеров советовал (автор этой книги) всегда придумывать два решения для любой задачи.
И тут до меня дошло, что большую часть времени нужно продумывать красивое решение. Если начинать реализовывать первое решение, которое пришло в голову, велика вероятность написать говнокод, который в будущем будет сложно отрефакторить и поддерживать.
Вообще обычно бывает три состояния задач:
1) Понятно как решать
2) Не знаешь решение
3) Не знаешь, что ты не знаешь :)
Задачи первого типа ты просто решаешь, про второго типа задачи спрашиваешь у других или гуглишь.
А из-за задач третьего типа и бывают такие застои. И такое объяснение, т.е. зарисовка решения всей задачи и помогает выявить задачи третьего типа и перевести в первую или вторую.
В конечном счете, не стоит садиться писать код, если существует очень много неопределенности. Лучше все продумать, попробовать придумать несколько решений на бумаге и только после этого писать код.
🔥22❤5❤🔥3👍3⚡1
Портрет сильного инженера
Недавнопослушал посмотрел подкаст с Шамилем Арсунукаевым, проработавшим более 17 лет в Кремниевой Долине в качестве инженера и engineering-менеджера. В целом подкаст просто топ, очень рекомендую послушать.
Одной из обсуждаемых тем, отозвавшихся лично у меня, был портрет сильного инженера, и в этом контексте были упомянуты две важные черты, ему присущие:
1. Высокий уровень технических скиллов
2. Умение добиваться результата несмотря на сложности, выходящие за рамки написания кода
Первый пункт в целом понятен, хочешь быть классным разработчиком — будь технически подкован, особенно в своём стеке.
Второй пункт куда интереснее. Часто разработка, особенно, если речь идёт про большой продукт, усложняется барьерами, выходящими далеко за пределы написания кода, а значит, нужны и дополнительные навыки.
Например, необходимо умение общаться с людьми из других команд и специальностей, стоящих за продуктом — продакт менеджерами, аналитиками, дизайнерами и так далее, только у этих людей зачастую бывают ответы на вопросы, блокирующие продвижение команды в проекте.
Кроме того, чтобы по-настоящему привносить значимый business/project impact, необходимо самому иметь продуктовый вижн. Как пример, я на работе сталкивался с необходимостью предлагать продукту альтернативный подход к составу MVP проекта для того, чтобы найти компромисс между сроками разработки и функциональностью продукта.
И вся вот эта основная мысль, на мой взгляд, переплетается с одним крайне важным тезисом, который упоминался в этом посте — «You’re not a programmer, you’re a problem solver».
Любая задача — это решение какой-то проблемы, зачастую пользовательской или бизнесовой, и чтобы быть действительно сильным и классным инженером, важно быть многогранным и выходить за рамки базового умения писать код.
Недавно
Одной из обсуждаемых тем, отозвавшихся лично у меня, был портрет сильного инженера, и в этом контексте были упомянуты две важные черты, ему присущие:
1. Высокий уровень технических скиллов
2. Умение добиваться результата несмотря на сложности, выходящие за рамки написания кода
Первый пункт в целом понятен, хочешь быть классным разработчиком — будь технически подкован, особенно в своём стеке.
Второй пункт куда интереснее. Часто разработка, особенно, если речь идёт про большой продукт, усложняется барьерами, выходящими далеко за пределы написания кода, а значит, нужны и дополнительные навыки.
Например, необходимо умение общаться с людьми из других команд и специальностей, стоящих за продуктом — продакт менеджерами, аналитиками, дизайнерами и так далее, только у этих людей зачастую бывают ответы на вопросы, блокирующие продвижение команды в проекте.
Кроме того, чтобы по-настоящему привносить значимый business/project impact, необходимо самому иметь продуктовый вижн. Как пример, я на работе сталкивался с необходимостью предлагать продукту альтернативный подход к составу MVP проекта для того, чтобы найти компромисс между сроками разработки и функциональностью продукта.
И вся вот эта основная мысль, на мой взгляд, переплетается с одним крайне важным тезисом, который упоминался в этом посте — «You’re not a programmer, you’re a problem solver».
Любая задача — это решение какой-то проблемы, зачастую пользовательской или бизнесовой, и чтобы быть действительно сильным и классным инженером, важно быть многогранным и выходить за рамки базового умения писать код.
YouTube
#36 | Шамиль Арсунукаев, Twitter, Confluent: секреты и 20 советов из 17 лет в Кремниевой Долине.
nFactorial Club - это invite-only сообщество предпринимателей, фаундеров, инвесторов, топ-менеджеров и экспертов. Подать заявку: https://nfactorialschool.typeform.com/to/LybSrqwc
Получите 10% скидку на любой курс от nFactorial School, используя промо-код…
Получите 10% скидку на любой курс от nFactorial School, используя промо-код…
🔥17👍6❤5
Пишем грамотное 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
Написать резюме сложно. Написать грамотное резюме ещё сложнее, особенно, если не следовать советам людей, находящихся «по ту сторону», т.е. оценивающих эти самые резюме.
Недавно сам занимался составлением резюме и потратил много времени на ресёрч того, как всё-таки правильно это сделать. Пришло время поделиться несколькими наиболее важными тезисами, ну и ресурсами, конечно✍️
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
stackoverflow.blog
How to write an effective developer resume: Advice from a hiring manager - Stack Overflow
🔥17❤6👍5
Интересное про деньги
Результат онлайн-опроса, проведенного американской психологической ассоциацией, показал, что 9 из 10 респондентов считают, что для приобретения «финансового благополучия», им необходимо увеличение материального достатка примерно вдвое.
Однако интересная деталь заключается в том, что подобное мышление не имело корреляции с текущим доходом респондента — люди, зарабатывающие 1.000$ в месяц считают, что для счастья им необходимо зарабатывать 2.000$, а люди с доходом в 50.000$, что 100.000$ — это тот самый недостающий винтик душевного и финансового спокойствия.
Означает ли это, что фундаментальная проблема несчастья на самом-то деле не настолько связана с деньгами?
Результаты другого исследования показали, что в действительности корреляция между деньгами и счастьем очень низка, а наибольшее ощущение жизненного удовлетворения доставляют:
1. Успешный семейный союз
2. Родственные и дружеские отношения
3. Ощущение жизни — в смысле ощущения своего интеллектуального, духовного и физического развития.
Мой инсайт последних нескольких дней в том, что деньги — не более, чем инструмент, которым нужно уметь грамотно управлять и приумножать для того, чтобы обеспечивать себе бóльшую независимость и свободу выбора, однако, как только ты начинаешь вкладывать в них нечто большее и начинаешь базировать на них своё понимание жизненного благополучия, как на главном факторе, ты вступаешь в вечные крысиные бега, счастье в которых найти будет невозможно.
Результат онлайн-опроса, проведенного американской психологической ассоциацией, показал, что 9 из 10 респондентов считают, что для приобретения «финансового благополучия», им необходимо увеличение материального достатка примерно вдвое.
Однако интересная деталь заключается в том, что подобное мышление не имело корреляции с текущим доходом респондента — люди, зарабатывающие 1.000$ в месяц считают, что для счастья им необходимо зарабатывать 2.000$, а люди с доходом в 50.000$, что 100.000$ — это тот самый недостающий винтик душевного и финансового спокойствия.
Означает ли это, что фундаментальная проблема несчастья на самом-то деле не настолько связана с деньгами?
Результаты другого исследования показали, что в действительности корреляция между деньгами и счастьем очень низка, а наибольшее ощущение жизненного удовлетворения доставляют:
1. Успешный семейный союз
2. Родственные и дружеские отношения
3. Ощущение жизни — в смысле ощущения своего интеллектуального, духовного и физического развития.
Мой инсайт последних нескольких дней в том, что деньги — не более, чем инструмент, которым нужно уметь грамотно управлять и приумножать для того, чтобы обеспечивать себе бóльшую независимость и свободу выбора, однако, как только ты начинаешь вкладывать в них нечто большее и начинаешь базировать на них своё понимание жизненного благополучия, как на главном факторе, ты вступаешь в вечные крысиные бега, счастье в которых найти будет невозможно.
🔥20❤10👍8
«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.»
❤18😭10💯3
🎙 Анонсируем новый прямой эфир, в котором мы пообщаемся с Аскаром Сатабалдиевым (@myegothings) — ex Head of SDU Technopark, ex Senior Software Engineer at Booking, Amazon, Meta.
На прямом эфире мы пообщаемся с Аскаром про его опыт преподавательской деятельности и опыт в MAANG, а также постараемся ответить на вопрос — что делать молодым специалистам с учетом кризиса на рынке IT.
⏳ Встречаемся в четверг, 16 ноября в 20:00 (ALMT) • 17:00 (MSK) в этом ТГ-канале.
На прямом эфире мы пообщаемся с Аскаром про его опыт преподавательской деятельности и опыт в MAANG, а также постараемся ответить на вопрос — что делать молодым специалистам с учетом кризиса на рынке IT.
⏳ Встречаемся в четверг, 16 ноября в 20:00 (ALMT) • 17:00 (MSK) в этом ТГ-канале.
🔥28❤6👀4
14 habits of highly productive developers
Недавно дочитал классную книгу — «14 habits of highly productive developers», которую мне когда-то порекомендовал мой ментор, теперь пришел мой черёд поделиться ею.
В книге автор попытался поисследовать, почему одни разработчики только и успевают, что закрывать рабочие таски и ни на что другое у них не остаётся ни времени, ни ресурсов, а другие не только продуктивны в рамках работы, но ещё и успевают заниматься различными активностями вне — выступают на конференциях, пишут pet-проекты, самообразовываются, ещё и на отдых и личную жизнь времени хватает.
Для того, чтобы разобраться в вопросе, автор не только поделился своим опытом наблюдений за такими людьми, но и пообщался с другими разрабами из BigTech компаний, задавая им вопросы, что, на мой взгляд, сделало книгу более объективной и богатой на инсайты. К слову, текст для недавнего поста был взят именно из неё.
Основной вывод автора в том, что секрет продуктивности заключается в правильных привычках, которыми эти самые продуктивные разработчики обладают. Сила привычек и вообще влияние подсознания на наши результаты, сильно недооценены.
Цитата из книги Atomic Habits на эту тему:
Собственно, в самой книге автор описывает 14 привычек, свойственных тем высокоэффективным разрабам, с которыми ему доводилось пересекаться и общаться.
🎯 Так что читайте и забирайте то, что подходит конкретно вам!
📚 Ссылка на книгу
Недавно дочитал классную книгу — «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 привычек, свойственных тем высокоэффективным разрабам, с которыми ему доводилось пересекаться и общаться.
🎯 Так что читайте и забирайте то, что подходит конкретно вам!
📚 Ссылка на книгу
👍19❤7🔥3💯1
Когда вы последний раз испытывали чувство скуки?
Года полтора назад я сидел на обеде с одним коллегой, и в процессе общения он выразил одну интересную мысль, которая в тот момент взорвала мой мозг. Эту мысль я до сих пор проношу через свою жизнь, стараясь дисциплинировать себя в каких-то вещах.
Сказал он примерно следующее: «Вспомни, как в детстве, когда тебе было нечем заняться, а условного инстаграма, чтобы в любой момент себя отвлечь, не было, ты мог просто скучать, смотреть в потолок, думать о чём-то своём и мечтать... Я вот недавно задумался и понял, что даже вспомнить не могу, когда у меня последний раз такое было».
К своему сильному удивлению, я быстро осознал, что тоже не могу вспомнить, когда я осознанно или неосознанно давал своему мозгу свободное время, полное отстранённых размышлений и мечтаний. Я стал слишком расчетливым для того, чтобы о чём-то мечтать и слишком занятым для того, чтобы смотреть в потолок, вот только любые промежутки между интеллектуальными процессами заполнялись отвлечениями — музыка, инста и тому подобное.
Эта мысль так жестко впечаталась мне в подсознание, что я стал стараться намеренно давать себе время на то, чтобы поскучать и побыть наедине со своими мыслями — не слушать иногда музыку за рулём, не залипать в телефон в транспорте, в зале и так далее.
К слову, научные исследования показали, что ощущение скуки приводит к повышению эффективности в решении проблем творческого характера.
Вот цитата на эту тему из книги «Найди время», которую я когда-то рекомендовал в одном из постов:
Года полтора назад я сидел на обеде с одним коллегой, и в процессе общения он выразил одну интересную мысль, которая в тот момент взорвала мой мозг. Эту мысль я до сих пор проношу через свою жизнь, стараясь дисциплинировать себя в каких-то вещах.
Сказал он примерно следующее: «Вспомни, как в детстве, когда тебе было нечем заняться, а условного инстаграма, чтобы в любой момент себя отвлечь, не было, ты мог просто скучать, смотреть в потолок, думать о чём-то своём и мечтать... Я вот недавно задумался и понял, что даже вспомнить не могу, когда у меня последний раз такое было».
К своему сильному удивлению, я быстро осознал, что тоже не могу вспомнить, когда я осознанно или неосознанно давал своему мозгу свободное время, полное отстранённых размышлений и мечтаний. Я стал слишком расчетливым для того, чтобы о чём-то мечтать и слишком занятым для того, чтобы смотреть в потолок, вот только любые промежутки между интеллектуальными процессами заполнялись отвлечениями — музыка, инста и тому подобное.
Эта мысль так жестко впечаталась мне в подсознание, что я стал стараться намеренно давать себе время на то, чтобы поскучать и побыть наедине со своими мыслями — не слушать иногда музыку за рулём, не залипать в телефон в транспорте, в зале и так далее.
К слову, научные исследования показали, что ощущение скуки приводит к повышению эффективности в решении проблем творческого характера.
Вот цитата на эту тему из книги «Найди время», которую я когда-то рекомендовал в одном из постов:
Лишившись отвлечений, вы можете почувствовать, что вам скучно. Однако скука — это на самом деле хорошая вещь. Она дает вашему сознанию шанс поблуждать, а блуждание часто заводит в интересные места. В ходе двух не связанных друг с другом исследований специалисты из Пенсильванского университета и из Университета Центрального Ланкашира выявили, что скучающие испытуемые эффективнее справлялись с проблемами творческого характера, чем нескучающие. Так что в следующий раз, почувствовав, что вам уже несколько минут не хватает внешних раздражителей, просто посидите спокойно. Вам стало скучно? Считайте, что вам повезло!
❤20🔥12💯2
Осознанность принятия технических решений
На данный момент я единственный iOS разработчик в команде. Руководитель/CTO — с бэкграундом бэкендера, очень интересный человек.
Мы часто обсуждаем с ним часть мобильных приложений (iOS/Android): архитектуру, UI, взаимодействие с бэкендом и тд. Учитывая его опыт в разработке и мой в мобилке, пытаемся прийти к общему решению.
Очень нравится его осознанный подход к разработке. Перед тем как принять решение, он все хорошо обдумывает, старается мыслить нестандартно и сравнивать разные решения.
Недавно мы начали переписывать сетевой слой приложения и часами все обсуждали, перед тем как приступить к написанию кода. Заметил одну вещь — он всегда задается вопросом «А нам это действительно нужно?» и пытается максимально упростить решение. Он не принимает решения, основываясь на том что это какой-то best practice, или потому что так сказал какой-то сеньор, а пытается понять, почему то или иное решение является самым подходящим и оптимальным для конкретной решаемой задачи.
Возможно, понимание всей сути каждого принятого решения может затормозить разработку и занять много времени, но в целом нужно иметь представление о том, что ты делаешь и зачем. На мой взгляд, именно такой подход приводит к более фундаментальному развитию инженера.
На данный момент я единственный iOS разработчик в команде. Руководитель/CTO — с бэкграундом бэкендера, очень интересный человек.
Мы часто обсуждаем с ним часть мобильных приложений (iOS/Android): архитектуру, UI, взаимодействие с бэкендом и тд. Учитывая его опыт в разработке и мой в мобилке, пытаемся прийти к общему решению.
Очень нравится его осознанный подход к разработке. Перед тем как принять решение, он все хорошо обдумывает, старается мыслить нестандартно и сравнивать разные решения.
Недавно мы начали переписывать сетевой слой приложения и часами все обсуждали, перед тем как приступить к написанию кода. Заметил одну вещь — он всегда задается вопросом «А нам это действительно нужно?» и пытается максимально упростить решение. Он не принимает решения, основываясь на том что это какой-то best practice, или потому что так сказал какой-то сеньор, а пытается понять, почему то или иное решение является самым подходящим и оптимальным для конкретной решаемой задачи.
Возможно, понимание всей сути каждого принятого решения может затормозить разработку и занять много времени, но в целом нужно иметь представление о том, что ты делаешь и зачем. На мой взгляд, именно такой подход приводит к более фундаментальному развитию инженера.
🔥34👏5❤🔥2🥴2😢1
Повышаем вероятность грейдапа или как написать грамотное performance review
Рабочие реалии таковы, что в большинстве случаев ваш руководитель управляет не только вами, но и другими людьми, как следствие, его внимание естественным образом пропорционально рассеивается между всеми подчиненными.
Это приводит к тому, что сколько бы важной и ценной работы вы не проделали, руководитель будет видеть и помнить только вершину айсберга, а бóльшая часть так и останется под водой.
Практически единственный способ исправлять это — писать качественное performance review, в котором вы сможете полноценно раскрыть ваш импакт на продукт, его техническое развитие, вашу команду и так далее.
Правильная структура такой оценки выглядит примерно следующим образом:
1. Цели
Начните performance review с описания того, какие цели ставились на оцениваемый период.
Благодаря этому результаты перестают быть чем-то плавающим в воздухе — вы сразу задаёте планку, отталкиваясь от которой можно оценивать полученные результаты — где вы достигли запланированного, где перевыполнили, а где недотянули.
2. Описание результатов
Обычно я пишу это в формате небольшой сводки, то есть как некий набор сухих фактов. Крайне важно стараться использовать репрезентативные метрики, позволяющие адекватно оценить результат.
Если по какому-то из пунктов я хочу оставить более подробное описание, я выделяю для этого отдельную секцию ниже, там можно раскрыть детали — принятые решения, ссылки на RFC, ключевые PR-ы и так далее.
3. Планы
Последнее и не менее важное — ваши планы на будущее, как с точки зрения развития проекта, так и с точки зрения развития профессиональных навыков.
Это показатель компетентности, способности планировать и видеть точки роста у себя и в продукте.
И наконец следует помнить, что если вы хотите грейдап, обязательно говорите об этом с руководителем.
📹 Классный видос по теме — клик.
Рабочие реалии таковы, что в большинстве случаев ваш руководитель управляет не только вами, но и другими людьми, как следствие, его внимание естественным образом пропорционально рассеивается между всеми подчиненными.
Это приводит к тому, что сколько бы важной и ценной работы вы не проделали, руководитель будет видеть и помнить только вершину айсберга, а бóльшая часть так и останется под водой.
Практически единственный способ исправлять это — писать качественное 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.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍4❤2❤🔥1
Жан Курбанбаев — от IOI и Google до Ironman
🤩 Не знаем какие планы у вас, но мы в новогодние каникулы планируем решать leetcode. Мотивацию нам для этого даст Жан Курбанбаев — Competitive Programming Coach, Google SWE, призёр IOI.
🎙 Жан станет гостем предстоящего прямого эфира на нашем канале, где расскажет о своём пути в спортивном программировании, работе в Google, опыте участия в Ironman и о том, как навыки спортивного программирования помогают добиваться результатов в спорте.
⏳ Встречаемся в пятницу, 29 декабря в 20:00 (ALMT) • 17:00 (MSK) в этом ТГ-канале.
🤩 Не знаем какие планы у вас, но мы в новогодние каникулы планируем решать leetcode. Мотивацию нам для этого даст Жан Курбанбаев — Competitive Programming Coach, Google SWE, призёр IOI.
🎙 Жан станет гостем предстоящего прямого эфира на нашем канале, где расскажет о своём пути в спортивном программировании, работе в Google, опыте участия в Ironman и о том, как навыки спортивного программирования помогают добиваться результатов в спорте.
⏳ Встречаемся в пятницу, 29 декабря в 20:00 (ALMT) • 17:00 (MSK) в этом ТГ-канале.
🔥28❤5👍3🤡1