#Карьера

Думал сегодня о том, как компании вроде Гугла поддерживают культуру, которая способна справляться с неопределённостью и невероятно сложными системами.

Ответ пришёл во время собеседования. Некоторые люди просто более заточены на работу в сложной (complex) среде и в условиях, когда всё неясно. Когда не то что нужно найти ответы, а нужно найти вопросы, потому что бывают моменты, что вообще ничего не понятно. Вокруг чернота и ты должен быть источником света.

Культура поддерживается при помощи найма людей. И гипотетические продуктовые вопросы, которые задаются на таких собеседованиях, хорошо показывают способность людей взять неопределённую проблему, к которой непонятно как подступиться (вроде «сколько рейсов ежедневно вылетает из аэропортов США»), разложить её по полочкам, задать правильные вопросы, сделать правильные предположения и набросать на бумажке некое подобие структуры.

Как сказал Бадма в последнем эпизода подкаста — «Старкрафт как шахматы, если умеешь играть, значит есть мозг. Если есть мозг, значит умеешь работать».

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

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

Это способность или данность? Можно ли это развить?

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

Развить эмпатию можно либо интеллектуально (будет что-то вроде фейковой эмпатии), либо проработав затыки через терапию или духовные практики. Но кому-то это досталось бесплатно, а кому-то — через работу над собой и, возможно, даже боль.

Как-то читал про роль таланта в успехе. Поинт статьи был в том, что талант даёт фору, но успехов достигает тот, кто много работает. При этом тот, у кого есть талант и кто много работает, конечно же, обладает значительно бОльшими шансами на успех.

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

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

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

Как-то так.


Меня спросили как проходят перемещения между командами (внутренние трансферы) в Гугле.

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

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

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

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

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

Вернусь к процессу.

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

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

Когда я переходил в Google Maps, я разговаривал с другим ПМом, сениор руководителем разработки (менеджером менеджеров), руководителем дизайнеров, директором по продукту и директором разработки. Все разговоры были относительно неформальными, но, естественно, они собирали какую-то информацию обо мне, а я — о них.

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

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

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

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

Это Гугл. Мой опыт в Амазоне был немного другим.

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

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

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

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


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

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

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

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

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

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

Но!

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

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

Аминь.


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

Начну со школы.

В седьмом классе я попал в экспериментальный математический класс в школе №11 в Иркутске, где математику вела преподавательница из университета. Мы решали Сканави и билеты со вступительных экзаменов столичных ВУЗов. Каждую неделю был “теор-опрос” — мини-контрольная на доказательство теорем.

Каждые полгода был устный экзамен, и за несдачу переводили в обычный класс. Постоянная практика (+страх исключения из “интеллектуальной элиты”) помогла прокачать навык решения сложных задач и коммуникации сложных концепций.

Потом 5 лет в Байкальском Государственном Университете на факультете Прикладной Информатики в Экономике (a.k.a. Экономической Кибернетики).

Универ, по большому счёту, не дал никаких знаний. Мне было интересно только программирование, я работал с 3-го курса и на старших курсах уже редко появлялся на учёбе. Но специальность в английском подтверждении диплома звучит как “Computer Science”, а 5-летний диплом считается за степень master’s, что выгодно смотрится на резюме.

Я успел пару лет прочислиться в аспирантуре экономического факультета, где появлялся несколько раз. Дед хотел, чтобы я был кандидатом наук, как и он. Наука — это однозначно не моё и нужно было выбросить тысяч 80 рублей при доходе 40 в месяц, чтобы в этом убедиться.

Я никогда не пишу о своей учёбе в аспирантуре и, если честно, уже и сам забываю, что когда-то там “учился”. Так же как и на непонятном мини-MBA в МГИМО, откуда я даже не стал забирать диплом.

Я грезил об американском MBA лет с 22-х и почти в 30 поступил в бизнес-школу Wharton в Университете Пенсильвании. Это — старейшая бизнес-школа в мире и каждый год находится в топ-3 бизнес-школ, соревнуясь с хипстерским Stanford GSB и чопорным Harvard. Качество студентов и репутация в США у трёх школ примерно одинаковые, но в России Wharton менее известен.

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

В Wharton я понял силу бренда на резюме. Во время летней практики в Амазоне мой коллега сказал следующее: “когда я смотрю на резюме и вижу топовую школу, например, Wharton, то автоматически считаю людей крутыми, потому что они смогли пройти фильтр и поступить туда”. Сам этот чувак учился в Berkley, тоже не лыком шит. Так не должно быть, но это — реальность. Бренд на резюме имеет значение, так как срабатывает когнитивное искажение “halo effect”.

После Wharton я больше нигде не учился и не планирую. Я уже наработал на “зачётку”, которая теперь работает на меня, и не вижу смысла продолжать получать формальное образование. То, что мне нужно, я могу, как и раньше, изучать сам или на курсах. Формальное подтверждение такого образование корочками мне не требуется, а те редкие курсы, которые я всё же закончил, я проходил без сертификата.

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

На вопрос “нужно ли современному айтишнику образование?” ответ зависит от того, какие у вас цели. Работать в FAANG, переехать за границу? Без образования человеку из нашей географии ну почти никак, если его резюме не может блеснуть крутыми компаниями вроде Яндекса. Работать на себя или мелкие компании? Можно всему научиться самому и корочки не нужны. Плюс время, потраченное на университет — это упущенная возможность получить практический опыт.

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

Мне в какой-то степени “повезло”, что я знал в раннем возрасте, что хочу заниматься информационными технологиями (это расшифровка “айти” если что). Не зная, как мне пригодится образование, я всё же вкладывал в него время и ресурсы. И оно пригодилось, потому что профессия оказалась очень востребованной. Однако, в то время это не было очевидно.

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

На эти деньги я купил первую электрогитару.


Иногда просто нужно что-то изменить.

Прошлой весной я решил рубануть с плеча и перешёл из работы над чатботами и UX-платформами в продукт, для которого интерфейс вторичен. Последний год я погрузился в инструменты для разработчиков — успел поработать с Kubernetes, “бессерверными” технологиями (serverless), а также немного окунулся в особенности девяти языков программирования.

Это было интересно, но мысли всегда уходили куда-то ещё.

Они уходили в дизайн.

Несмотря на то, что по образованию я автоматизатор-разработчик, в душе дизайн всегда занимал место на одну ступеньку выше кодерства. С того самого момента, когда мне в руки в 1990х попала газета Computer Review, где в короткой статье был описан язык HTML. Когда я кое-как смог выждать одну ночь на даче, чтобы прибежать домой и попробовать наконец вбить в компьютер заветные <html><head><title> и увидеть страницу в браузере.

Это было просто вау. Несколько строк достаточно сохранить и они показываются в экране? Без компиляции? Это был взрыв мозга. Отвал башки.

Именно благодаря HTML я начал изучать фотошоп и заниматься дизайном. Дизайн всегда привлекал меня тем, что пользователь взаимодействует с продуктом именно через его интерфейс. Дизайн — передовая линия продукта, то, что и есть “экспириенс”, даже если 90% кода — на бэкэнде.

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

Всю жизнь я пытаюсь найти баланс между двумя парадоксами: во мне живёт любовь к дизайну без желания им заниматься и любовь к кодингу без желания кодить профессионально. Отчасти поэтому я всю карьеру мечусь между техническими и менее техническими продуктами. И вообще мечусь всю жизнь в поисках того, что же мне интересно. AWS Chatbot был таким продуктом и я занимался им 4 года, но хотелось чего-то другого…

Перейдя в Гугл, я отправился слишком далеко в технические дебри. В какой-то момент я перестал получать удовольствие от того, что делаю. Разбираясь с особенностями обратной совместимости Node.js и нюансами сетевых политик в Istio, я попросту засыпал. Знаете, когда, как на лекциях, нужно вставить в глаза спички, чтобы хоть как-то держать глаза открытыми. При этом моя работа приносила огромную ценность и была важной и для разработчиков, и для компании.

Но это было то, что англичане называют “not my cup of tea”. Люди могут быть универсалами и делать любую работу, какую им дают. Это вроде бы называется “профессионализмом”. Но я лично могу по-настоящему выстрелить и преуспеть только когда у меня горят глаза. Когда я не могу уснуть, размышляя над рабочей проблемой. Когда я могу выскочить из душа и записать идею, чтобы случайно не забыть.

Я выбираю нездоровые отношения с работой вместо скуки. Я могу работать без перерыва над тем, что мне интересно, и в итоге выгореть от физической усталости. Но я также могу работать нормальные часы над тем, что мне неинтересно, и выгореть от скуки. Выбирая от чего выгорать, я выбираю выгореть от чрезмерной увлечённости (хотя стараюсь научиться не выгорать вовсе). Я это прямо чётко осознал на работе в Гугле.

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

Поэтому я решил внести коррективы в карьеру. Сегодня я перехожу в Google Maps, где смогу совместить свою страсть к дизайну, понимание разработчиков и опыт построения платформ. Я буду отвечать за развитие Google Maps API, который позволяет разработчикам встраивать гугловские карты в свои приложения. В чём именно будет заключаться моя работа я пока ещё не знаю, но в неё точно будет входить работа над кастомизацией внешнего вида карт. Дизайн ☺️

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

Мета-поинт здесь в том, что найдёт только ищущий. Жизнь хоть и полна компромиссов с собой, но она у нас одна и её не стоит тратить на то, к чему не лежит душа.


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

Примерно в 20% взаимодействий с людьми в сфере обслуживания и профессиональных услуг (рестораны, врачи, тренеры) сервис на порядок выше, чем в США. Эти люди глубоко клиенто-ориентированы, профессиональны и с огоньком в глазах решают вашу проблему.

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

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

Я говорю про администратора популярного ресторана, которая сказала гостям за соседним столиком “у нас не ресторан быстрого питания” в ответ на их просьбу принять заказ после 40 минут ожидания. Про отвалившуюся плитку, которую просто прислонили обратно к стене, авось не заметят. Про модное французское кафе на Красной Площади, которое открывается с задержкой на несколько минут несмотря на скопившуюся на улице толпу.

Попивая кофе в том кафе, я думал о том, почему в России, стране с первоклассными специалистами, присутствует такая расхлябанность в работе и отсутствие клиенто-ориентированности. И мне в голову пришёл термин “профессиональная апатия”. Люди не вкладываются в работу, не стремятся быть лучше, а просто хотят дождаться конца рабочего дня.

Им всё равно.

В английском есть выражение “do what you love, love what you do”, суть которого в том, чтобы делать любое дело качественно и с любовью. Когда человек выбирает делать только определённые дела качественно, а другие — на “и так сойдёт”, то он предаёт свою внутреннюю страсть к созиданию. Он давит её и превращается в неэмпатичного робота, который механически следует процессу. Можно сказать, что эти 8 часов в день на работе он и не живёт вовсе.

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

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

Долгосрочная ценность для бизнеса — в Customer Lifetime Value (CLV), ценности клиента на протяжении его “жизни”. Для сферы услуг ценность — в повторных заказах и сарафанном радио. Лояльность и увеличение CLV создаётся через “wow”, через экспириенс, которым хочется делиться с друзьями. Его создают люди, которым не всё равно, работающие на таких же, кто готов давать свободу и разжигать внутренний огонь, а не гасить его.


Когда люди меняют работу, они часто бегут “от” чего-то. От неинтересной работы, “не тех” людей, “не той” культуры. Многие ищут место, где трава позеленее, но в итоге приземляются в те же самые проблемы. Даже в популярной песне “Life” Юлия Зиверт поёт “если все вокруг не те, поищи в себе”.

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

Разберём на примере человека, который поставил себе цель стать директором и бежит к ней, делая рациональные шаги, помогающие ему попасть на следующий уровень. По ходу продвижения по иерархии растёт доход и уровень ответственности. Прямо как в мечте. Но одновременно и меняется характер работы. Для кого-то это нормально — ему может быть в кайф или цель оправдывает средства. А кто-то начинает предавать себя и не может соскочить с “успешной” траектории.

С каждым шагом происходит escalation of commitment (эскалация приверженности?), когда ты уже вложил столько усилий в этот путь, что не можешь соскочить с него, став жертвой когнитивного искажения sunk cost fallacy. “Утопленные затраты” это то, что ты уже вложил и, кажется, что, если соскочишь, то всё это было зря. В итоге “топишь” ещё больше затрат и можешь закончить руинами. Эти затраты уже утонули, их нельзя вернуть, но можно сократить будущие потери перестав вкладывать.

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

В подкасте Эзры Кляйна обсуждалась тема перехода из создателя в менеджмент. Эзра — создатель и основал компанию Vox Media, которая делает интересные подкасты. В какой-то момент он стал её СЕО и на шоу он рассказывал, как изменение в характере работы опустили его на самое дно. Он потерял себя. Тогда он принял решение уйти с важного поста и снова вести подкаст. И снова стал счастлив. Он прибежал “к”, убегая “от”.

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

Но в побегах “от” кроются огромные возможности. Желание сбежать — это сигнал тела, говорящий “что-то идёт не так”. Это повод начать внутреннюю работу и начать меняться. В этих поисках вы можете приблизиться к себе и увидеть мир с другой стороны даже в том месте, где вы уже находитесь. И можете более ясно увидеть своё “к”, которое до этого было более размытым. Побег “от” вырывает вас из инерции и застоя.

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

Только при одном “но” — бежать надо не сразу. Стоит остановиться, заглянуть в себя, долго смотреть внутрь, разглядеть новый вектор, а потом уже идти в его направлении. Это будет эксперимент. Там, куда вы придёте, тоже может оказаться не то. Тогда нужно пробовать снова и снова при условии, что вы всё же бежите от объективных факторов несовместимости. Важно не превратить побеги в крысиные бега от самого себя.

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

Все мои годы в DHL я был на качелях и в конце концов сбежал “от” — не дождавшись оффера от программы МВА, я ушёл из компании. В итоге я всё же получил оффер, но изначально я был готов идти на риск, потому что работать там я уже не мог. На МВА я шёл с чётким пониманием того, что хочу и добился этого, идя “к”. Но это не обошлось без падения на дно, пика депрессии, психотерапии и посвящения в духовные практики, которые помогли мне немного узнать себя.

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


Когда я пришёл в Google, синдром самозванца оставил меня примерно на 10-м месяце, а придя в Amazon пятью годами раньше я смог войти в струю и почувствовать себя уверенно за неделю. В чём была разница?

Предыдущие посты по теме: Синдром самозванца ч.2, Синдром самозванца в Google.

Я писал про три фактора, усложняющих смену работы: домен (область знаний и экспертизы), культура компании и позиция. Их и разберём на моём примере.

В Амазон я пришёл интерном Senior Product Manager на проект, связанный с рекламной платформой для amazon.com. Это был знакомый домен и у меня был весь необходимый набор скиллов в статистике, A/B тестировании, SQL, а также опыт с AdWords и AdSense, который был напрямую применим в работе.

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

Придя в AWS (облачный бизнес Амазона) следующим летом, я освоился за пару дней и к концу первой недели уже написал первый черновик требований для нового проекта — платформы аналитики. Я опять попал в знакомый домен и, вдобавок, хорошо ориентировался в культуре. Через 4 года меня промотировали на уровень Principal, а ещё через год я перешёл в Google.

В Гугле система грейдинга немного другая, тут меньше названий, но больше уровней. Я называюсь Product Manager, но мой уровень эквивалентен амазоновскому принципалу. Таким образом, в Гугл я зашёл на более высокий уровень, чем когда начинал в Амазоне. Казалось бы, у меня есть весь опыт, необходимый для успешного начала работы, но начинать на более высоком уровне оказалось сложнее.

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

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

Самое важное в этом переходе — смена домена. Я перешёл из комфортной для себя области чатботов, веб-приложений и аналитики в облачную инфраструктуру. В самые дебри Kubernetes, Knative, Istio и других страшных названий. Что бы я ни делал, что бы ни читал, у меня всегда было ощущение, что я отстаю в понимании технических деталей. Мне приходилось звать с собой инженеров на разговоры с клиентами, потому что на каждом звонке меня заставали врасплох каким-нибудь техническим вопросом.

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

Ситуацию отягощало то, что многие мои вопросы были слишком мелкими, чтобы выдёргивать людей на митинг (они обычно 30-минутные и нужно договариваться заранее), но слишком сложными, чтобы я мог их нормально описать текстом в чате. Я много “варился в собственном соку”, как говорил один из моих первых руководителей много лет назад.

Но в какой-то момент забрезжил свет в конце туннеля. Постепенно, шаг за шагом, что-то начало проясняться. Я много читал и задавал вопросы, когда мог. Не боялся выглядеть глупым, потому что начал понимать, что не могу так долго быть самозванцем, меня ж уволят, блин! И в какой-то момент информация начала складываться в некое подобие системы и я начал видеть связи, а затем и детали.

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

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

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

Я не соответствовал своим собственным стандартам, но вполне соответствовал ожиданиям. Но это было сложно увидеть в ежедневной спешке и хаосе. Поэтому очень полезно делать ретроспективу с позиции времени, а также просить фидбек у окружения. Вы лучше чем вы на себя надумываете!

И, как говорят американцы — “fake it till you make it.” Это про меня, да и, наверное, про всех из вас, кто рискует и идёт в неизведанные для себя дебри.


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

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

История 1: из учителя в программисты.

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

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

Мы “воспользовались” Сандрой, чтобы привлечь в команду больше женщин, так как это делало нашу среду более привлекательной, чем 100% мужской коллектив. К моему уходу из компании наша команда разработки состояла на 25% из женщин, что вполне неплохо для big tech. Сандра помогала нанимать женщин и коучила новичков. Одна из наших новеньких пришла в разработку из профессии медсестры в возрасте под 30.

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

История 2: как женщина-руководитель привлекает больше женщин в организацию.

Моим первым руководителем в Амазоне была вице-президент организации, создающей платформы для облачного UX. Дороти пришла в компанию в конце 90х совсем молоденькой разработчицей и доросла до уровня, который вне досягаемости для большинства людей в индустрии.

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

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

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

А знаете интересный исторический факт? Первые программисты на машинах, занимающих целые этажи университетов были женщинами. Одна из них, Грейс Хоппер, изобрела компилятор программ из текста на английском (высокоуровневого языка) в машинный код. В последствии, по версии Уолтера Айзексона в книге “Инноваторы”, когда мужчины увидели, что железо — это не так круто и будущее за софтом, они переключились на кодинг и женщины были вытеснены из профессии.

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

Поделитесь историями — своими или людей, которых вы знаете.

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

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


Когда я перешёл работать в Google, “что-то как пошло не так”. У меня ушло около полугода, что бы докопаться до причины и, возможно, кому-то из вас эти инсайты будут полезными.

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

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

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

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

Ну и наконец — позиция. Если вы переходите с позиции продакт менеджера в одной компании на такую же позицию в другой, конечно же, будут отличия, но они будут минимальными. Но если вы переходите с позиции разработчика на позицию продакта (или наоборот), то разрыв будет колоссальный и вам придётся обучаться новой профессии на ходу. Люди, которые меняют профессию («войти в айти», я о вас), думаю, хорошо ощущают это на себе.

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

Если вы меняете два фактора, то сложность увеличивается не линейно, а геометрически. Если поменяв компанию, вам при переходе в 2 раза сложнее, чем на старом месте, то поменяв компанию и домен, вам будет в 4 раза сложнее. А если вы при этом ещё и меняете позицию, то сложность возрастает в 8 раз.

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

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

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

Что же пошло не так в моём опыте? Я поменял одну компанию с очень сильной культурой (Amazon) на другую с культурой, во многом диаметрально противоположной Амазону (Google). Я до сих пор адаптируюсь. При этом, я ещё и сменил доменную область на такую, в которой нет лёгких путей, один хардкор. У меня ушло полгода, чтобы не чувствовать себя самозванцем в разговорах с коллегами. Для сравнения, на предыдущих местах я через месяц-два уже был на пике эффективности.


После истории про мой опыт с SQL вы спрашивали как быстро осваивать технические навыки. Держите четыре принципа, которые помогают мне и помогут вам.

1) Фундаментальные знания

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

Моему поколению учиться было и сложнее, и проще. Сложнее, потому что не было бесконечного количества курсов, видео и статей. Была документация и несколько книжек. Многих библиотек и фреймворков ещё не было, а так же не было универсального доступа к информации в Интернете (Гугл запустился в 1998). Мы многое делали своими руками и приходилось делать даже такие вещи как манипуляцию пикселей на экране. Это было сложно и неэффективно, но важно для понимания основ.

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

Мы учились при помощи дедукции (от частного к общему), потому что у нас не было другого выбора. Сейчас можно обойтись без фундаментального понимания и хватать знания на поверхности методом индукции, идя от общего к частному. Но всегда будет оставаться ощущение пробелов в знаниях и новые технологии будут заводить в тупик.

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

2) Начинайте с простого

“Любая сложная система — это эволюция простой системы” (с) Systemantics by John Gall. Не хватайтесь сразу за Node.js, где асинхронность сведёт вас с ума и вы решите, что программирование — не для вас. Не трогайте Java и C++. Вообще не трогайте объектно-ориентированное программирование в самом начале. Начните с Python, который уже установлен на ваш Мак и легко устанавливается на другие платформы.

Идите постепенно от фундаментальных основ к фреймворкам, которые вы будете понимать, а не просто использовать. Первый год пройдёт медленно. Но через 5 вы будете профессионалом, который знает больше, чем 80% остальных людей в профессии и хватает новые технологии на лету, ведь все новые технологии без исключения основаны на старых.

3) Не отвлекайтесь

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

Начали что-то изучать — сидите и изучайте. Отведите минимум 2 часа на каждое занятие, уберите телефон и не вставайте раньше времени. Когда я был в универе, я мог просидеть по 14 часов без еды, занимаясь одним и тем же. Сейчас я не могу себе такого позволить из-за детей, работы, да и выносливость уже не та. Но те часы работают на меня сейчас, 20 лет спустя. Думайте о себе будущем, которому будет легко за счёт вашей боли сейчас.

4) Идите туда, где вам нравится и хорошо получается

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

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


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

Когда мне было 17 (чуть меньше, чем на фото), я очень хотел на каникулах между курсами поработать дизайнером. К тому времени я уже создавал сайты, но денег за это ещё не получал. Это конец 1990х - ранние 2000е, людям нужно было объяснять зачем им нужен компьютер, а интернет был вообще чем-то эзотерическим.

Мой дед Сергей Лаврентьевич (RIP 😢) по ночам сторожил аптеку у родственников, но летом это мешало даче. Он предложил мне поработать за него, а всю зарплату отдать мне. Я согласился и пошёл за 1500 (я не ошибся нулями, полторы тысячи!) рублей ночевать в другом конце города на раскладушке в месте с фармацевтическим запахом.

Я уже не могу вспомнить где именно она была, но это был спальный микрорайон “Юбилейный” в Иркутске. Аптека закрывалась часов в 20, а в выходные в 17:00 и находиться там было адски скучно. Но там был компьютер 😈

На нем я сначала занимался по программе скорочтения и перечитал всего Достоевского. Это быстро надоело, уставали глаза за старым монитором. Тогда я решил научиться современным технологиям для интернета. На тот момент я уже знал HTML, CSS, JavaScript (он был не тот, что сейчас) и Perl. Так же был опыт с C++ и неплохие знания Pascal (под DOS). Я купил книжку по PHP и SQL и начал писать «Гостевую книгу».

В своей обычной ебанатской манере, я освоил оба языка за несколько ночей и после этого устроился на работу к @aleksandrpyankov разработчиком на PHP+SQL. Эта история освещается в подкасте @uehavshie (первый эпизод). Первые годы я использовал SQL исключительно для разработки бэкэнда на PHP и позже — C++ под Windows.

Когда я начал работать в DHL, SQL пригодился мне для коррекции времени сканирования отправок, которое мы зафакапили из-за перевода часов. Чтобы не разрушить операционные показатели, я разобрался как устроена БД корпоративного приложения на FoxPro (кажется), подсоединился к ней и сделал запрос, который убил нафиг все данные за тот день. Пришлось всё переделывать и мы ещё больше зафакапили показатели… хотфиксы в продакшене без тестирования - плохая идея.

Потом подвернулась вакансия аналитика в Москве, где нужно было знать базы данных в MS Access. Я купил книжку и за пару ночей освоил Access, сделал тестовое задание и получил работу в Москве. Так началась 5-летняя сага в бизнес-аналитике и переезды в разные страны.

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

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

Получив оффер на фулл-тайм, я пришёл строить облачную платформу аналитики, анализирующую миллиарды событий в день. Это было бы сложно без глубокого знания SQL. Я работал над ней год и переключился на чатботов, но использовал SQL (+Python) для анализа продукта и понимания паттернов использования продукта.

Когда я пришел в Google, знаете, что я сделал в первую очередь?

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

Сейчас SQL - это базовый навык в айти, но далеко не все знают его глубоко. А многие до сих пор не знают. Я давно писал об этом пост - читайте и учите SQL.


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

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

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

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

Можно провести аналогию с одним из законов сложных систем из книги “Systemantics” (автор John Gall), который говорит, что любая успешная сложная система — это результат эволюции простой системы. А система, которую изначально запланировали как сложную, будет стопроцентно провальной. Так же и с карьерой.

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

Практика же приходит благодаря выходу из зоны комфорта. Мы все работаем в организациях, даже если это организация из одного человека. И всегда есть “геморная” работа, которая приносит ценность, но её не хочется делать ни тебе, ни другим, потому что она не входит ни в чьи прямые обязанности. А ты возьми и сделай её. Пройди через фрустрацию и доведи её до конца.

Потом сделай что-то ещё, съешь эту “лягушку” (заимствую жаргон у Брайана Трейси). В итоге, шаг за шагом, пока все сидят на месте, ты станешь опытным поедателем лягушек. Со временем станешь профессионалом, способным решать определённый класс проблем (неважно организационных или технических), который приводит других людей в ужас.

Это придётся делать через “не хочу”, преодолевая страхи “а вдруг не получится” и синдром самозванца. Некоторые задачи ты не сможешь решить или решишь неправильно, где-то попросту облажаешься, где-то придётся капитулировать и просить помощи. В такие моменты нужно дать себе хорошо отдохнуть, а потом встать, отряхнуться и пробовать снова.

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

P.S. Уже слышу возражения, что на территории бывшего СНГ есть свои нюансы, но описанный мной принцип универсален. Тот, кто проактивно берётся за более сложную работу, имеющую ценность для окружающих, в любом случае выплывет наверх (не самая удачная аналогия в посте про “геморную” работу, но вы меня поняли). Или в рамках компании, или поменяв работу, или создав что-то своё.

P.P.S. С чего начать? Один из способов найти применение себя к сложной задаче с высокой ценностью — это исправить то, на что другие жалуются. Жаловаться — это пассивно-агрессивная и деструктивная позиция, если за ней не следует действие по исправлению ситуации. Не все ситуации можно сделать лучше, но какие-то можно, но только если начать действовать.


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

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

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

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

В какой-то момент начали складываться очертания того, куда я попал, и я начал документ под названием MVSR — Mission, Vision, Strategy, Roadmap. Миссия - это то, зачем мы существуем, высокая идея. Видение - цель на 3-5 лет. Стратегия - как мы достигаем видение и как это увязано со стратегией организации и Google Cloud. Roadmap - конкретные фичи, которые мы планируем сделать в ближайшее время.

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

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

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

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

Эти идеи пришли из трёх источников:

  • Физик Ричард Фейнман практиковал письмо всего, что он знает о предмете, чтобы увидеть границы своих знаний.
  • Мой бывший босс в Амазоне использовал документ MVSR, когда он пришёл в нашу организацию и наводил порядок.
  • Книга «Первые 90 дней» хорошо описывает баланс между техническими знаниями и организационным ориентированием на новом месте.

Итак, когда начинаешь работу в новой для себя сфере/команде/проекте:

  1. Максимально быстро получи общее представление о продукте, процессах, людях и технологиях через общение с людьми, чтение внутренних документов, просмотр видео и т.п.
  2. Начни писать то, что узнал. Это поможет как тебе, так и другим, потому что теперь «племенные» знания (tribal knowledge) становятся задокументированными знаниями и их легко передавать дальше.
  3. Возьми какой-нибудь проект, чтобы окунуться в детали. Погрузись туда с головой. Это поможет понять технические проблемы и ограничения, а также построить отношения с коллегами и пользователями.
  4. Пока у тебя свежий взгляд, подвергай текущие процессы сомнению, но не переусердствуй, так как ты ещё многого не знаешь. Просто задавай вопрос «почему» и изучай ответы. У тебя есть шанс изменить мышление команды к лучшему.
  5. Документируй всё. Повторяюсь, но это важно. Человек, который способен излагать свои мысли и синтезировать информацию письменно, сразу же приносит пользу любой команде. Люди это оценят.
  6. Поставь на паузу другие интеллектуальные задачи. Я на время перестал читать книги не по теме ибо мозг опух так, что я даже не мог нормально разговаривать после рабочего дня. Был перегруз от интенсива. Отдых важен.

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

В комментах к посту прилетел вопрос “как можно судить о том правы ли были мои менторы и сколько времени нужно на оценку их правильности?”, который заставил задуматься.

Люди так устроены, что спустя годы, мы можем выбрать критерий оценки своего действия в прошлом и оценить его как “правильное” или “неправильное”, поддавшись влиянию когнитивного искажения “hindsight bias”.

С позиции времени легко смотреть на жизнь рационально и анализировать её, но в моменте это сделать невозможно из-за неопределённости как будущего так и своих собственных целей. Откуда вы знаете, что для вас будет правильно через 5-10 лет? Принимая решения сейчас, вы определяете будущего себя, который может быть доволен или не доволен этим решением. Но у него нет выбора, ведь он — там, в будущем. А вы — здесь и сейчас.

Размышляя над этим и напевая “I’m walking down the steps on white line straight to nowhere” из песни Alice in Chains, я увидел влияние музыкантов как ролевой модели в моей карьере. Мне вспомнилась история Лэйна Стэйли, со-основателя и вокалиста группы. Он начинал как барабанщик. Потом решил стать вокалистом, резко продал барабаны, купил микрофон, взял уроки пения и в итоге стал одним из главных персонажей, сформировавших новый музыкальный стиль.

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

Принято говорить о том, что кто-то “свернул с пути” — это заблуждение. С пути невозможно свернуть. Туда, куда ты пошёл — и есть твой путь и он единственно правильный. Каждое решение по-своему правильно, потому что оно даёт тот опыт, благодаря которому мы становимся теми, кто мы есть (если исключать тот вариант, что мы живём в матрице и все решения уже приняты за нас).


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

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

Хакатон — это когда компании дают сотрудникам день-два на работу над своими собственными идеями. Те, кто участвовал в хакатонах, знают людей, которые так увлекаются, что могут не спать сутками. Дима работал над своим проектом 19.5 часов с перерывом на поесть и помыться. Потом поспал 4 часа и пошёл его презентовать.

“Дык, компания же за это платит” скажете вы и будете частично правы. Я делал хакатоны в Амазоне и наблюдал, что не все хотят в них участвовать, а из тех, кто участвует, не все идут до конца. Хоть и стоит учитывать факторы вроде семьи, я видел людей, которые в 17:00 шли домой, играли с детьми, а потом снова выходили на связь поздно вечером и полночи кодили.

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

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

Занимаетесь ли вы профессиональным развитием вне работы? Если да, что делаете? Если нет, почему нет?


В марте прошлого года американские компании закрыли офисы. Всё началось с технологических гигантов в Сиэтле: Google, Amazon и Facebook были первыми, кто отправил сотрудников домой. Мы думали посидим пару недель дома и вернёмся обратно в офис, но прошёл уже год.

За этот год я перешёл на работу в Google Cloud в надежде на бесплатный хавчик, эспрессо и массаж, но в офисе я до сих пор ни разу не был. Мне прислали бэдж, но я даже не знаю куда его прислонять. Несколько человек в моей команде тоже перешли в Гугл после начала локдаунов. В отличие от остальных членов команды, мы не знакомы ни с кем лично. Это, пожалуй, самое сложное в смене работы на удалёнке.

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

Такое общение помогало мне на протяжении всей карьеры — я строил отношения с людьми неформально и я везде был “своим в доску”. За всю карьеру я могу пересчитать по пальцам конфликты с другими людьми, так как сложно конфликтовать с человеком, с которым ты на одной волне. А я ловил в коридорах самые разные волны. Интуитивно, без усилий.

А потом всё изменилось — коридоров не стало. Чтобы с кем-то поговорить, нужно запланировать звонок, но тогда важно кого-то не забыть и вот у тебя в митинге уже пять человек. Чтобы что-то быстро спросить, нужно это или напечатать (занимает время и требует усилий), или запланировать звонок. День стал разбит на отрезки времени в календаре, часть спонтанного общения 1:1 заменилась групповым с задержками связи, перебиванием друг друга и излишней вежливостью.

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

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

Локдауны подкосили эту культуру. Люди адаптировались и работают по-новому, но насколько они эффективны? Мне сложно судить, так как я не работал в “настоящем” до-ковидном Гугле. И возможно уже никогда не поработаю, потому что когда всё вернётся на свои места через 2-3 года, культура уже не будет прежней. Она будет травмирована беспощадной разбивкой рабочего дня на получасовые отрезки.

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

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

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

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

У меня всё 🐈


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

СС больше присущ женщинам

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

Правильно ли называть СС синдромом и не идёт ли подмена понятий?

Такая тема была затронута в паре комментов. Мои мысли на этот счёт такие (чистой воды спекуляция, за слова не отвечаю): СС — это страх быть исключённым и отторгнутым. Этот страх происходит от неуверенности в своих силах и сравнении себя с окружающими.

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

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

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

Айтишники более склонны к СС

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

Похоже осталось материала ещё на один пост…

А пока ставь ❤️ и подписывайся, чтобы не пропустить 😎


В Google любят говорить о синдроме самозванца. С первого дня на тренингах опытные “Гуглеры” уверяли нас, что это распространённое чувство не только среди новеньких, но и среди давно работающих в компании.

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

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

С другой стороны, особо впечатлительные перфекционисты могут начать чувствовать себя менее уверенно, потому что постоянные разговоры о самозванстве могут вызвать вопросы из серии “А действительно ли я хорош для работы тут? Может я тоже самозванец, как и они, просто чего-то не вижу?”

Я поднял эту тему с коллегой, который пришёл в Google одновременно со мной, и рассказал ему, что я не чувствую себя самозванцем, но вокруг как будто есть давление, что надо бы. У него отозвались эти же ощущения.

Я читал, что много лет назад культура Google отличалась “интеллектуальной заносчивостью”, что особенно ярко проявлялось на собеседованиях, когда кандидату иногда давали понять, что он разговаривает с “кагбы очень умными людьми и должен знать своё место”. Это уже в прошлом и мой опыт собеседования и работы тут показывает, что люди очень приятные и скромные. Никто не хвастается своими достижениями и способностями.

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

Вы бы стали чувствовать себя менее уверенно, если бы вокруг часто говорили о том, как чувствовать себя самозванцем это норма?


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

Давайте разберёмся что такое кодинг, чем он полезен и с чего начать.

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

Как программирование может помочь не-программисту?

1) Программирование учит логике, оптимизации и анализу

Код практически никогда ни у кого не запускается с первого раза, даже у самого матёрого программиста где-нибудь в Google. Часто не запускается ни со второго, ни с третьего…

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

2) Общение с программистами

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

3) Анализ данных

Бывают ситуации, особенно, на ранних стадиях разработки продукта, когда информация не поступает в системы анализа и базы данных. Данные могут быть в логах (logs) — записях в обычных текстовых файлах на серверах. Если знаешь основы Python, ты можешь создать очень простой скрипт (20-30 строчек), чтобы трансформировать логи в таблицы, которые, в свою очередь, можно импортировать для анализа в Excel или в локальную базу данных вроде SQLite для анализа при помощи SQL.

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

4) Статистический анализ и машинное обучение

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

5) Автоматизация себя

Все, кто работает в больших компаниях, сталкиваются с административной (и часто ручной) работой, которую неохота делать. Можно написать скрипт, который делает эту работу за тебя. Я так делал для автоматизации отчётности — написал скрипт в VBA (visual basic for applications — язык, встроенный в Excel), который делал за меня рутинную работу.

6) Улучшение личной эффективности

Сейчас для того, чтобы запустить свой продукт не нужно никаких серверов и понимания как работает инфраструктура. Можно взять облачный сервис AWS Lambda, прямо в браузере написать код на Python, Node.js или Go, нажать Сохранить и он уже в продакшене (или, скорее, в говнопродакшене, но это ок для мелких личных проектов).

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

С чего начать?

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

Однозначно не стоит начинать со сложных языков типа Java. Я бы также не советовал с нуля идти в Node.js с его асинхронностью, об которую чёрт ногу сломит. Поняв на простом языке основы программирования и фундаментальные концепции, такие как циклы, функции, классы, модули и т.п. изучение других языков будет, скорее, изучением их особенностей, потому что в их основе лежат те же самые принципы.

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