Каково делать Kotlin: интервью с Андреем Бреславом
Дефицита технических материалов о Kotlin нет, узнать о корутинах или nullability можно много где. Но остаётся куда менее освещённой другая сторона:, а как вообще выглядит процесс разработки языка? Как принимаются решения? Каковы задачи у «самого главного человека»? Остаётся ли у него в жизни время на что-либо ещё?
И сейчас, когда вот-вот выйдет Kotlin 1.3, мы расспросили «самого главного» Андрея Бреслава не про корутины, а про совсем другое: от того, чем он занимался до Kotlin, до того, чем полезна психотерапия.
— Ты разработчик языка программирования. До этого ты чем-то таким занимался?
— До этого я много преподавал программирование и занимался академической работой. Это была исследовательская деятельность про предметно-ориентированные языки (DSL), по сути чисто умозрительная, без пользователей. Сейчас все по-другому: язык общего назначения, куча пользователей и задач, связанных с реальной разработкой.
— А зачем тебе это всё вообще?
— Это довольно интересная инженерная деятельность. Она необычная, с большой отдачей — если удается сделать что-то хорошее, то получается большой эффект. Раз — и глобально изменилось то, на чем люди пишут. Когда я начинал работать на Котлином, было понятно, что это потенциально продукт с большим количеством пользователей. Риск, конечно, высокий, но и мотивация, в свою очередь, тоже высокая. Это интересно, потому что система сложная, вовлекает много разных знаний. Наверное, это самые главные вещи: большой эффект и сложные и интересные задачи.
— Это всё мотивация для технаря. А вообще по жизни — почему ты этим занимаешься? Ты мог бы стать, например, политиком или еще кем угодно.
— Вопрос сложный. Профессию я выбирал достаточно рано. Что у меня тогда получалось, что мне тогда нравилось — этому я и посвящал много времени. В школе мне понравилось программировать, я программировал много, пошел учиться этому в университет. Затем довольно быстро переключился на преподавание, занимался этим сначала full time, лет восемь, наверное, потом — параллельно с программистской работой и дальше окончательно переключился на разработку Котлина. Еще я попробовал позаниматься наукой, computer science, но в академическом мире мне не понравилось.
— В общественном сознании разработка языка программирования — это и есть тот самый computer science.
— Ну, в общественном сознании часто смешиваются понятия. Разработка языка программирования — это инженерная работа, computer science — это исследование чего-нибудь нового, тут нужна какая-то научная новизна. Чтобы получить научный результат, нужно, чтобы результаты были хотя бы как-то измеримы или доказаны. В случае с языком программирования что-нибудь общеупотребительное померить крайне сложно. Есть люди, которые занимаются разработкой академических языков — по языку Haskell написано невероятное количество научных работ, и он специально так построен, чтобы по нему можно было доказывать теоремы. По языку вроде Котлина теоремы доказывать крайне сложно, потому что он просто не для этого. С точки зрения математики мейнстримные языки очень грязные, там очень сложно что-то до конца формализовать. Люди пытаются, для этого делаются маленькие версии этих языков. И оказывается, что те доказательства, которые были написаны для этих маленьких версий, для больших могут уже не работать. Не так давно была распиаренная статья Ross Tate и Nada Amin про то, что системы типов Scala и Java — unsound. Это как раз связано с тем, что маленькие модели, которые рассматривались до этого, не учитывали одно важное свойство настоящего языка.
— А что ты по этому поводу думаешь?
— Это неважно. Мейнстримовые языки потому и грязные, что просто это неважно. Очень мало кто страдает от того, что нет чистых мейнстримовых языков. Это не имеет заметного эффекта, люди как пользовались Джавой, так и будут ею пользоваться, несмотря на эту статью. Аналогично со Скалой. Довольно долго не было известно, например, разрешима ли система типов Джавы, можно ли написать корректный компилятор — потом выяснилось, что нельзя. Ну и что? Реальные программы всё равно можно компилировать. С системой типов Скалы изначально было известно, что она неразрешима. Но это не важно, потому что мы всё равно пишем программы руками, и таких странных программ, которые не может скомпилировать ни один современный компилятор, мы всё равно не пишем.
— А что важно?
— Это очень интересный психолого-философский вопрос. Очевидно, что людям важно, чтобы их не раздражало. Например, из опыта с Джавой: мы знаем, что если очень много слов надо повторять, то это бесит. Видно, что современная Джава отлично идет в сторону того, чтобы бесить поменьше. Котлин во многом был придуман на волне того, что некоторые вещи очень бесили, а Джава не развивалась. Нужно чувствовать, что система не очень сопротивляется тому, как ты хочешь выражать свои мысли. Вот у меня есть что-то в голове, я что-то хочу написать, и если мне для этого надо прорваться через язык программирования, это мучительно. То есть, если это надо делать постоянно, это тяжело, если редко, то нормально. Мне кажется, это одна из важных эмоциональных вещей.
Мы сейчас видим какие-то опросы, по которым Котлин — «один из самых любимых языков на планете, люди, которые пользуются Котлином, очень его любят». Это очень приятно. Почему так получилось, сложно сказать. Во-первых, конечно же есть эффект хайпа, потому что язык новый, когда появляется «новая игрушка», это само по себе нравится. Но похоже, что, действительно, Котлин не очень бесит, то есть меньше сопротивляется по сравнению с другими языками, когда реализуешь на нем то, что родилось у тебя в голове. Людям явно важно, насколько коротко или длинно они выражают свои мысли. Им важно не повторять одно и то же по много раз. Важно, насколько удобно читать программы после того, как они написаны.
Мысль о читаемости кода довольно долго прорастала в умах. Было несколько поколений языков программирования, которые было трудновато читать. Наверное, самый яркий из поздних примеров — это Perl. А в былые времена, например, какой-нибудь APL — очень яркий представитель. Сейчас уже более-менее все сошлись на том, что читать программу гораздо важнее, чем писать. Кстати, и программы стали гораздо больше и сложнее, чем раньше, что тоже подталкивает к этой мысли. Хочется как-то бороться с этой сложностью, как-то ее сдерживать. Поэтому, например, многие ненавидят boilerplate — «очевидный» код, в котором нет ничего содержательного, хочется его пропустить при чтении, но там по-прежнему могут прятаться баги.
Людям важно уметь повторно использовать какие-то структуры в своих программах. Я не хочу писать тысячу раз одно и то же. Очень хочется какие-то общую структуры вынести в библиотеку. И средств абстракции в языках программирования всегда недостаточно для того, чтобы переиспользовать всё на свете. Это закон бытия. Всё на свете никогда нельзя будет переиспользовать. Но можно выбрать класс вещей, которые встречаются часто, и научиться переиспользовать эти вещи. Поэтому в Котлине, например, появились какие-то абстракции, которых в других мейнстримовых языках раньше не было, например, delegated property или inline-функции как структура в языке. Другие языки экспериментируют с другими абстракциями. Например, в Scala невероятное количество абстракций, в Haskell много всяких абстракций, которых нигде больше нет, и т.д. Это всё попытки сделать так, чтобы какие-то вещи можно было повторно использовать, чтобы то, что я один раз сделал, мне потом пригодилось много раз.
Вот эти вещи явно важны. Конечно, людям еще важна и просто культура вокруг них. Если есть экосистема, есть комьюнити, есть возможность с кем-то общаться, получить ответы на свои вопросы, есть библиотеки, которые развиваются, еще какая-то инфраструктура — это очень сильно поддерживает, люди чувствуют, что система живая, в ней приятно находиться.
— Вы как-то занимаетесь тем, что поддерживаете культуру?
— Мы очень стараемся работать с комьюнити, оно у нас довольно дружелюбное, люди любят отвечать на вопросы, подсказывать что-то новичкам, обсуждать какие-то сложные вещи. Комьюнити живое, мы пользуемся слэком, там у нас какое-то невероятное количество людей — десятки тысяч, кажется. Естественно, не все активные, но тем не менее. Там есть много активных пользователей, которые общаются друг с другом. Мы с ними работаем — сами отвечаем на вопросы, ну и стараемся следить за тем, чтобы все было цивилизованно. Еще мы помогаем организовываться юзер-группам, их уже, кажется, под две сотни, если я не ошибаюсь. Это тоже очень приятная история, классно смотреть на карту юзер-групп, они есть много где — от самых больших технических центров до вообще неизвестных мне стран в Африке. Мы стараемся поддерживать активных людей в комьюнити. Если кто-то пишет много постов, делает какие-то туториалы, пишет библиотеки, мы стараемся этих людей как-то подсвечивать, поддерживать, давать им возможность высказаться. Мы проводим свою конференцию KotlinConf, люди присылают туда свои доклады, мы отбираем самые интересные. Так что с комьюнити мы работаем довольно активно.
— Я правильно понимаю, что ты сам тоже отвечаешь?
— Я отвечаю не очень часто, у меня не всегда хватает времени за этим следить, но бывает, что отвечаю. Иногда мы устраиваем какие-то целенаправленные мероприятия. Один раз была видеодвижуха, когда мы собирали вопросы в Твиттере и стримили ответы, я сидел и отвечал на вопросы. Еще был довольно успешный «Ask me anything» на Reddit.
— Когда мы искали людей, которые могут рассказывать о языках программирования, библиотеках и т.д., оказалось, что скилл «хорошо программировать» и скилл «хорошо рассказывать» — это вещи не так часто встречающиеся. Как вы находите и подбираете себе людей? Как должен получиться человек, который должен одновременно и думать о пользователе, и кодить?
— К счастью, таких людей нужно ограниченное число. Понятно, что каждый разработчик должен в какой-то мере думать о пользователях. В этом смысле если человек очень хорошо программирует, но программирует что-то отвлеченное от пользователей, то мы с ним вряд ли найдем общий язык. В какой-то мере все должны о пользователе заботиться. Есть какое-то небольшое множество людей, которые совсем много работают с пользователями, то есть люди, у которых есть такие склонности. Это не очень связано с умением зажигательно рассказывать длинный доклад, это уже немного другая деятельность. Вообще говорить и писать — это очень разные умения, и есть люди, которые с огромным удовольствием пишут подробные хорошие понятные тексты и при этом не любят выступать, потому что это другой формат взаимодействия. Есть люди, которые любят и то, и другое. Это как раз мой случай, но мне гораздо меньше нравится выступать со слайдами, чем участвовать в каком-то живом диалоге. На TechTrain вот у меня, к счастью, был формат Q&A: люди задавали мне вопросы, а я отвечал. Потому что каждый раз, выступая с докладом, у меня есть ощущение, что та структура слайдов, которую я придумал заранее, она какая-то неправильная, вот тут бы по этой логике рассказ стоило бы чуть по-другому повернуть, но слайды ведь по дороге не поменяешь, и это мешает.
— Обычный вопрос: что тебя толкнуло сделать первый доклад?
— Сейчас попробую вспомнить, как это было. Очень просто сказать, когда был первый доклад про Котлин — мы анонсировали Котлин на JVM Language Summit в 2011 году, и там была задача заявить о проекте как можно громче. И нам хотелось собрать фидбэк от специалистов. И как раз в том году я поехал делать несколько первых больших публичных докладов, это были мои первые выступления на английском языке. То есть меня толкнула исключительно маркетинговая необходимость.
— А есть какие-нибудь удивительные наблюдения с докладов? Что-то, что ты не знал о людях?
— Особо ничего нет удивительного. Всё-таки я и преподавал до этого много, и в целом основные вещи понятны. Например, далеко не все люди приходят на доклад, чтобы что-нибудь узнать. Сомневаюсь, что даже половина аудитории приходит, чтобы реально что-то узнать. Много кто приходит пообщаться с докладчиком. Например, когда человек по какой-то причине известен, вроде меня («один из создателей Котлина»), люди приходят на мой доклад не потому, что хотят что-то узнать про Котлин, вопрос мне какой-то задать, а просто потому что это доклад человека, про которого они раньше слышали. Часть людей приходит себя показать, причем это бывает как конструктивно, так и нет. Иногда люди, которые пришли себя показать, задают очень интересные вопросы. Я не уверен, что они это осознают, но в чем заключается их задача — они хотят как-то выступить, задают интересные вопросы, потому что у них есть какие-то соображения. А иногда себя показать хочется, а интересный вопрос придумать не получилось, тогда вопросы получаются какие-то странные. Ну, а есть еще те, кто хочет чему-то научить докладчика или всех присутствующих. Иногда это бывает очень смешно, когда приходит человек и, вместо того, чтобы задавать вопросы, просто формулирует своё мнение, произносит целую речь.
— А был такой человек, который тебя всё-таки чему-то научил?
— Про «научил» сложно сказать. Может и было такое, но я просто не запомнил. Но понятно, что когда люди высказывают какое-то мнение, оно обычно репрезентативно — так думает какая-то группа людей. В этом смысле такое мнение всегда ценно. Другое дело, ценно ли его высказывать именно в таком формате — когда ты задаешь вопрос на докладе — это уже сложно сказать. Но вообще любые мнения, в частности те, которые кажутся мне некорректными, важны, потому что важно же не только то, что на самом деле верно, а то, что люди думают. Если у кого-то в голове возникает цепочка аргументов, даже тех, которые я умею опровергать, мне важно знать, что она возникает, и тогда я могу с ней взаимодействовать. В принципе это всё полезно. Другое дело, что преподносится это всё всегда по-разному.
У нас на раннем этапе, еще когда Котлин не зарелизился, были всякие смешные разговоры. Как-то мы говорили со Стивеном Колборном, и он с нами очень много спорил о том, что писать типы справа после двоеточия — это ужасно, нужно обязательно писать типы слева. И всем, кто хоть немного погрузился в языки, было понятно, что это спор остроконечников с тупоконечниками — ни о чем, это не принципиально. Уже были популярны Pascal, Scala — какая разница, с какой стороны тип писать. Где удобнее с точки зрения структуры остального языка, там и надо писать. Но есть люди, которые верят, что это действительно очень важно, и готовы потратить очень много энергии, чтобы это обсудить. Это бывает странно, но всё равно приходится какие-то аргументы формулировать, потому что такой человек не один, это не просто так взялось. Стив же не просто так вцепился в это, а остальным было всё равно — нет, была достаточно большая группа людей, которым казалось, что это важно. Про синтаксис такое часто бывает. Языки программирования — штука достаточно сложная, и не так много чего из этой области легко понять. А про синтаксис понятно, синтаксис — это просто. Во-первых, очень многих учили тому, как это всё формируется, в университете часто есть курс про формальные грамматики. Да даже если не учился, это всё не очень сложно понять, и поэтому про синтаксис очень много мнений. А там чем дальше (семантика времени выполнения, система типов и так далее), тем меньше мнений, потому что понять сложно. И это жалко, потому что вообще-то тут очень много чего интересного можно обсудить, но в основном вся энергия обсуждений рассеивается где-то в районе синтаксиса, как это ни жалко.
— Все обсуждают то, что понимают. Ладно, идем дальше. Ты работаешь не один, а в команде. Команда тоже формирует какую-то свою репрезентативную группу?
— Конечно. У нас, безусловно, мнения людей внутри команды играют большую роль в развитии языка. И команда подбирается так, чтобы мнения были релевантны. Вообще JetBrains — это такая компания, которая очень сильно зависит от догфудинга. Мы все наши продукты активно догфудим (это от английского выражения «to eat your own dog«s food» — если мы что-то делаем, мы сами этим пользуемся). И Котлином мы тоже сами пользуемся, и в котлиновской команде, и за ее пределами. Фидбэк изнутри доходит быстрее всего. Надо понимать, что у нас юзкейс специфический. Например, нам бы в компиляторе очень пригодились некоторые языковые фичи, которые больше никому не нужны.
— Можешь привести пример?
— Есть такой глобальный спор про паттернмэтчинг. В функциональных языках программирования принято иметь паттернмэтчинг, а в Котлине его нет. Есть только довольно ограниченный вариант. И мы в какой-то момент сознательно не стали делать полный. Он был когда-то запроектирован, но мы не стали реализовывать. Фича достаточно большая, сложная, для объектно-ориентированного языка программирования достаточно грязная. Мы посмотрели по сложности, сколько стоит реализация этой фичи, и решили попробовать не делать её и посмотреть, что будет. Попробовали. Выяснилось, конечно, что компилятор можно было бы писать и поудобнее. А всё остальное — похоже, что большинству пользователей всё равно. Конечно, всегда есть часть людей, которая знает, что есть паттернмэтчинг, и им очень хочется в тех редких случаях, когда он релевантен, его использовать. Но похоже, что, как всегда, 80+ процентов юзкейсов не требуют этой фичи. Это всё довольно забавно, потому что сейчас Java пытается смотреть в сторону паттернмэтчинга, и мы с Брайаном Гётцем об этом говорили не раз. Я пытался его агитировать, что не надо так сильно усложнять Джаву, и так всё непросто во многих местах. Но Брайан говорит, что паттернмэтчинг людям нужен, у него есть какие-то свои аргументы. Я пока не очень понимаю, насколько его аргументы веские. Зато у нас теперь есть шанс, что они эту фичу добавят, мы посмотрим, что у них получится, и там решим.
— Если добавят.
— Ну, это очень вероятно. Судя по тому, насколько Брайан оптимистичен, я думаю, рано или поздно добавят. Сколько времени это займет, правда, непонятно. Надо заметить, что в Котлине не то чтобы вообще нет следов паттернмэтчинга, есть что-то достаточно похожее. За счет того, что у нас есть смарткасты, есть when expression, есть destructuring assignment. Вообще очень большая часть юзкейсов паттернмэтчинга покрывается в языке. Мы с ним не умеем делать только сложные вещи. И вот похоже, что их можно и не уметь. Но если окажется, что всё-таки очень нужно, значит, нам станет легче писать компилятор.
— Можешь немного рассказать о команде — как вы живете?
— Мы живем очень весело. Нас уже очень много. Когда мы начинали, я был единственным full time-разработчиком, но это было давно, 8 лет назад. С тех пор мы сильно выросли. Нас уже около 50 человек, мы сидим в разных офисах. В Питере больше всего, но есть люди в Мюнхене, в Новосибирске, возможно, появятся в Москве. Есть еще какие-то изолированные удаленные люди. Внутри проекта несколько команд. У нас есть команда, которая занимается фронтендом компилятора и, как исторически получилось, JVM-ным бэкендом. Есть команда джаваскриптового бэкенда, Kotlin/Native, библиотечная команда, которая занимается всеми библиотеками, есть команда IDE и другого тулинга, build-тулы в первую очередь, инкрементальная компиляция и так далее. У нас довольно разнообразный профиль, мы много всего делаем, поэтому есть очень много задач по координации: надо, чтобы все команды, делающие разные вещи, к каждому релизу сошлись в одной точке и выдали что-то полезное.
— Как вообще это выглядит? Сидишь ты сверху, бог на Олимпе, и мечешь молнии — «Ты делай то, ты делай это, всё, разошлись»?
— Нет, так это, конечно же, не работает. Во-первых, за всем следить невозможно. В основном я занимаюсь дизайном языка и какими-то общестратегическими вопросами. Это значит, что ко мне в какой-то форме попадают разные соображения о том, что у кого болит, у меня есть какие-то свои мысли по поводу нашей стратегической линии развития. Мы пытаемся это как-то совместить с текущими возможностями, с технической ситуацией: что у нас случилось (или не случилось) в компиляторе, и что у нас болит по инфраструктуре, где у нас накопился технический долг или еще что-то. Это всё надо составить и решить, что мы делаем в следующем большом релизе. Это коллегиальная работа, совершенно не в одну голову. Мы на всё это смотрим такой группой лиц: дизайном языка занимается одна подгруппа лиц, технической частью — пересекающаяся, но не совпадающая подгруппа лиц, есть еще Q/A, который достаточно сильно помогает с тем, чтобы понять, на что надо обращать внимание, где у нас проблемы, где пользователю непонятно — этим занимаются support и Q/A. И вот из всей этой разнообразной информации у нас получается картина того, где у нас приоритеты и на что надо обращать внимание. Я в этом смысле тот человек, к которому приходят, если оказывается, что непонятно, что делать. Например, надо выбрать между двумя несовместимыми разумными стратегиями, это уже решается с моим участием. И дизайн языка на мне замыкается в том смысле, что язык должен быть внутри логически согласованным, все решения должны пройти через какую-то одну голову. Сегодня это моя голова.
— Хочу кое-что уточнить. Многие компании, особенно энтерпрайзная и банковская разработка, которые, вполне возможно, читают нас сейчас как пользователи языка, организованы по принципу армии. У вас как? Это армия, это спецназ, это набор ресерчеров — что происходит? Потому что когда смотришь на YouTrack снаружи, тебе дается очень странный вью на компанию — там даже есть отдельные люди.
— Компания и проект — это немного разные разговоры. В компании JetBrains есть проекты с абсолютно разной внутренней организацией. Традиционно, когда-то на заре, JetBrains был командой автономных разработчиков, у каждого была какая-то зона ответственности, и каждый в ней более-менее сам решал всё, что случится: что делать, как делать, сам общался с пользователями и так далее. И в некоторых проектах эта модель до сих пор доминирует. В IDE это вполне жизнеспособная штука, по крайней мере, пока IDE еще не огромная. Есть проекты, которые работают по Скраму, кто-то работает в режиме вертикальной организации, где кто-то наверху решает, как что делается. Понятно, что какая-то самостоятельная деятельность там всё же есть, но есть какая-то более вертикальная конструкция. Что касается нас, сложно сказать, где мы в этом спектре находимся. У нас точно не Скрам, у нас достаточно легковесный процесс, который мы со временем больше формализуем, потому что нам приходится координировать всё больше людей — всё-таки 50 человек совсем ad hoc трудно координировать. Сейчас мы как раз пытаемся чуть больше формализовать наше планирование, чтобы мы точнее понимали, когда мы что собираемся успеть, потому что команды иногда не могут понять, какие у кого приоритеты, и происходят какие-то сбои, к счастью, пока не очень заметные снаружи.
Схема у нас следующая: есть подкоманды, у подкоманд есть тимлиды, информация ходит через них. При этом внутри очень много чего решается самостоятельно, коллегиально. Важные решения мы в основном принимаем консенсусом. Обычно мы разговариваем, пока все не придут к более-менее общему мнению, только если не надо решить что-то очень срочное. В таком случае решение может быть принято очень быстро, аврально: «так делаем, так не делаем, обсудим потом». Но это бывает очень редко. По-научному это, наверное, называется «синхронная организация».
— Работа влияет на расклад жизни?
— Очень влияет. Работа занимает огромное количество времени.
— Не оказывается ли так, что ты работаешь 24 часа и спишь в офисе?
— Я не могу работать 24 часа. Когда-то очень давно в юности у меня был год, когда я работал где-то 80 часов в неделю. На следующий год я решил, что больше никогда не буду так работать, потому что это физически очень тяжело. Мне приходится достаточно сильно следить за распределением рабочего и личного времени, потому что иначе я просто очень устаю, перестаю соображать и впадаю в грустное состояние. Я работаю фиксированное количество часов в день и сознательно стараюсь не работать на выходных, по вечерам. Вообще стараюсь время вне офиса уделять другим вопросам. У меня параллельно есть еще один проект, стартап про поиск психологов и психотерапевтов. Это тоже работа, но другая, и есть некое выделенное количество времени, которое я этим занимаюсь.
— Работаешь ли ты после работы?
— Нет, я стараюсь делать всё в таком порядке: в определенные дни я занимаюсь одним проектом, в другие — другим проектом. Если делать это всё подряд, то можно сойти с ума. Работать несколько часов над чем-то одним, а потом сразу несколько часов над другим — это очень тяжело.
— По поводу твоего второго проекта: ты же разработчик, при чем тут психологи?
— Хоть я и разработчик, но я же не перестаю быть человеком? У меня есть ощущение, что полезность психотерапии очень сильно недооценена в современном обществе. Люди уже выучили, что ходить в спортивный зал или в бассейн — полезно, многие люди выучили, что полезно развиваться как-то еще — кто-то книжки читает, кто-то тренирует прикладную рациональность, еще что-то. Это развитие разных «органов», функций организма. А можно развивать то, что связано с осознанностью.
Сложно коротко описать то, чем занимается психотерапевт. Мне больше всего интересен перевод решений, которые мы принимаем, из автоматического режима (когда я что-то сделал и не знаю, почему, и вообще не знал, что могу по-другому) в более осознанный (когда я что-то сделал, я знаю, почему, знаю, что мог бы по-другому, и выбор сделал сознательно).
Дисклеймер: все решения принимать осознанно физически невозможно. Это очень хорошо, что у нас есть какие-то автоматические механизмы, потому что иначе можно просто сойти с ума. Каждый раз думать головой о каждой вещи, которую ты делаешь — это слишком много времени и сил. Но при этом уметь те решения, которые важны, принимать сознательно, очень важно, потому что это дает свободу. Свобода, с моей точки зрения, — это как раз возможность сделать собственный осознанный выбор, а не ехать по каким-то рельсам, которые предписывает культура, родители, традиции или еще что-то такое. Это одна из вещей, которые, мне кажется, немного недооценены в современном продвинутом обществе, хотя сама ценность такой свободы принятия собственных решений есть. А инструмент, который очень полезен для того, чтобы туда попасть, недооценен. И мне кажется, что стоит как-то продвигать эту мысль в массы.
Я когда-то думал о том, что я бы как-то порекламировал это всё, но меня заела совесть, потому что вот я начну это рекламировать, а меня спросят, где можно найти специалистов, которые будут с нами работать. Ответа на этот вопрос у меня на тот момент не было, и поэтому я пошел заниматься проектом, который помогает найти себе такого специалиста. Выяснилось, что я совсем не один про такие вещи думаю. Я нашел единомышленников, с которыми мы вместе делаем этот проект.
Сейчас есть какие-то другие проекты, которые пытаются делать что-то подобное. Так что у нас все по-настоящему: конкуренция, азарт. Я в наш проект очень верю. Мы, мне кажется, выделяемся тем, что мы обращаем внимание на некоторые вещи, на которые обращать внимание неудобно с точки зрения бизнеса, но очень важно с точки зрения результата. Мы занимаемся тем, что на входе отбираем самих психотерапевтов, очень строго, по профессиональным характеристикам. Если вы получили рекомендацию у нас, то это будет очень хорошо проверенный специалист, профессионал. Мы потратили кучу времени, чтобы сформировать методику, как отличать хороших специалистов от не очень хороших, работаем с учеными из московского научно-исследовательского института ПИ РАО. Методика эта достаточно разносторонняя, и мы уверены, что те специалисты, которых мы предлагаем, действительно хорошие. Кроме этого мы собираем обратную связь и следим за тем, чтобы больше не рекомендовать тех, кто сделает что-то не то. Это как раз та часть, на которую наши коллеги из других проектов обращают маловато внимания, нужно обращать побольше. Мы еще стараемся научиться подбирать автоматически, что достаточно интересно.
В общем, я считаю, что психотерапия — это полезно, и поэтому стараюсь делать так, чтобы она была более доступной.
— Какой спусковой крючок? Когда надо идти на психотерапию?
— К этому вопросу есть два подхода. Первый — когда есть ощущение, что что-то не устраивает в эмоциональной сфере: я всё время грустный, у меня повторяется одна и та же эмоциональная ситуация, я всё время расстраиваюсь, когда мне говорят что-нибудь, у меня в отношениях с партнером всё время повторяется одно и то же — например, такой круг длиною в год и т.д. В таких вещах имеет смысл разбираться с терапевтом, потому что, во-первых, это очень эффективно, можно быстро узнать много чего полезного, а во-вторых, это вещи, которые очень сложно осознавать самому, даже если мне кажется, что я всё понимаю — 100%, что это неправда. И дело не в том, что я недостаточно умный, чтобы в себе всё понять, а в том, что сознание имеет ограниченные возможности рефлексии: мы одним и тем же инструментом под названием «мозг» пытаемся изучать тот же самый инструмент — физически тот же, не такой же, а тот же.
А психотерапевт во многом выступает как зеркало. Он не должен давать вам советы, одна из его функций — отражать, дать мне возможность по-настоящему увидеть, что у меня в голове происходит. Все решения всё равно буду принимать я, все приоритеты буду расставлять я, но другой человек может мне помочь узнать, что там на самом деле творится. Важно, чтобы это был именно профессионал, потому что, вообще говоря, рассказывать всё подряд, что у меня в голове творится, какому-нибудь человеку, который вообще непонятно, как на это отреагирует, может сделать мне неприятно, сделать что-то, что в дальнейшем на меня повлияет (или даже еще кому-нибудь расскажет) — это просто опасно. Поэтому важно найти специалиста, который, во-первых, работает экологично, во-вторых, связан обязательством неразглашения. Это сильно отличается от друга или родственника, потому что с ними у меня есть какие-то отношения, и, если я что-нибудь такое расскажу, это может повлиять на эти отношения. А в случае с психотерапевтом что бы я ни рассказал, я ничем особо не рискую.
— Это как когда с компилятором говоришь.
— Ну не знаю, компилятор на меня очень обижается, но ничего не может сказать в ответ, это уже немножко другое.
Так вот, это был один повод идти к психотерапевту — когда есть какой-то дискомфорт, тебя что-то не устраивает, хочется что-то улучшить. Другой повод — когда хочется просто развиваться (даже когда в принципе всё комфортно, всё в порядке), мне кажется, крайне полезно позамечать какие-то вещи, которые вы делаете автоматически. Вот я делаю что-то, казалось бы, важное, но не знаю, почему. Мне это вроде не мешает, но, если я узнаю, почему, и получу в этом месте свободу принимать решения, я буду еще круче. Это, по-моему, достаточно хороший повод идти на психотерапию.
— Насколько важна осознанность в работе разработчика? Я слышал, в Гугле сейчас стали в качестве чуть ли не полуобязательного упражнения в некоторых тестовых группах проводить медитацию или что-то еще.
— Это очень интересно с точки зрения терминологии. Словом «осознанность» обозначаются разные вещи. Есть история про медитацию или mindfulness, другие практики телесной осознанности — очень полезная штука с точки зрения управления вниманием, умения концентрироваться. Она еще немного помогает психологическому комфорту — помогает лучше расслабляться, со стрессом полегче и т.д. Это ближе к физическому упражнению, речь идет о довольно низкоуровневых механизмах в мозге, которые позволяют натренировать некоторое управление вниманием. Люди, которые много напрягают мозг, безусловно выигрывают оттого, что тренируют это место и могут иметь больше контроля над тем, куда направлено внимание и какие пропорции энергии уделяются какой сфере деятельности сознания. Это одна история. Другая история — осознанный выбор, это не то же самое. Осознанный выбор — штука тоже довольно полезная не только в работе инженера, но и везде, где нужно принимать решения.
Например, в жизни бывает много споров. Понятно, что часто нет какого-то наилучшего мнения, поэтому есть какие-то споры. И то, насколько конструктивно проходят споры, напрямую зависит от осознанности участников. Это такая важная часть культуры общения: как мы умеем разделять своё личное мнение и объективную реальность — где что-то, во что я верю, а где есть внешний факт, который неопровержимо что-то доказывает. Люди часто это путают, и даже во всяких психотерапевтических группах и на тренингах есть много замечательных упражнений, которые направлены на то, чтобы человек разделял, что вот это его мнение, а вот это некая внешняя реальность. Есть практики безоценочного общения, ненасильственного общения, очень рекомендую.
И другая вещь. У всех есть интуиция. Бывает,
