🎙️ Жан Курбанбаев — от IOI и Google до Ironman

Друзья, спасибо всем, кто был с нами на эфире!

Мы обсудили с Жаном его бэкграунд в спортивном программировании, тернистый путь к медали на IOI, работу в Google, разочарование в разработке, поиск себя, путь к первому полумарафону и участие в Ironman.

Спасибо Жану за то, что нашёл время, чтобы провести с нами этот эфир, он получился очень полезным и интересным!

Записи наших эфиров теперь можно также послушать на наших страничках в Spotify и Apple Podcasts:

🎵 Spotify — ссылка
🎙 Apple Podcasts — ссылка
🎵 Яндекс Музыка — ссылка

Работать нужно не 12 часов, а головой

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

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

Приведу пример: летом работал по 10 часов, уделяя чуть больше времени работе и другим проектам. Вроде бы успевал и работать и задачи по проектам закрывать, но спустя 2-3 недели выгорел и перестал работать. Да, заставлял себя, сидел за рабочим столом, но тело и организм отказывались, не хотели работать.

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

Кэл Ньюпорт, выпускник MIT, профессор и автор бестселлеров New York Times, часто пишет о продуктивности и приводит такую формулу:

Выполненная работа = Потраченное время х Интенсивность

Эта формула помогает объяснить, почему некоторые студенты проводят всю ночь в библиотеке и все еще имеют проблемы в учебе, в то время как другие, кажется, что даже не читают книгу, но постоянно набирают высокие баллы на экзаменах. Время, которое вы тратите на «обучение», бессмысленно вне контекста интенсивности. Например, 2-3 часа с высокой интенсивностью потенциально могут дать больше результатов, чем ночь с низкой интенсивностью.

Давайте объясню, что подразумевается под термином "интенсивность" в формуле.

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

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

В итоге чем интенсивнее работаешь, тем меньше тратишь времени и успеваешь больше.

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

📖 Почитать статью Кэла Ньюпорта о формуле: клик
📹 Посмотреть интервью с Маргуланом Сейсембаевым: клик

Тимур Тибеев — отказ от офферов в MAANG и жизнь в Австралии

🦘 Вам кажется, что с перевёрнутым текстом на постере что-то не так? Да не, всё в порядке, ведь к нам из самой Австралии подключится на эфир Тимур Тибеев — Senior SWE at Canva (Сидней), ex TeamLead at Yandex, автор канала @bigtechdream

🎙️ На эфире с Тимуром мы пообщаемся о его карьерном пути, о MAANG и отказе от офферов в Google и Amazon, о жизни и работе в Австралии, поисках жизненного баланса, профессиональном развитии и многом другом!

⏳ Встречаемся в воскресенье, 4 февраля в 11:00 (MSK) • 14:00 (ALMT) на нашем ТГ-канале.

Спасибо всем, кто был на эфире!

🇦🇺 В этот раз к нам из самой Австралии подключился Тимур Тибеев — Senior SWE at Canva, ex TeamLead at Yandex.

Мы пообщались с Тимуром про его карьерный путь, про отказ от офферов в Google и Amazon. Поговорили о жизни и работе в Австралии, поисках жизненного баланса, профессиональном развитии и многом другом!

Получилась супер интересная беседа, спасибо Тимуру за то, что нашёл возможность прийти к нам!

Подписывайтесь на его канал — @bigtechdream

Кстати, послушать этот и предыдущие выпуски можно на 🎵Spotify, 🎙Apple Podcasts и 🎵Яндекс Музыке — по ссылке

Те, кто слушал подкаст с Жаном, наверное, помнят историю его собеса в Google, где он получил отказ из-за некомпетентности интервьюера. В посте тот самый email, который он написал рекрутеру, после которого ему переназначили собесы и он получил оффер 🕸

Мораль, по видимому, такова, что надо становиться настолько прокаченным в своих скиллах, чтобы хватало смелости после интервью считать некомпетентным интервьюера, а не себя 😁

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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