Дефицита технических материалов о 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, другие практики телесной осознанности — очень полезная штука с точки зрения управления вниманием, умения концентрироваться. Она еще немного помогает психологическому комфорту — помогает лучше расслабляться, со стрессом полегче и т.д. Это ближе к физическому упражнению, речь идет о довольно низкоуровневых механизмах в мозге, которые позволяют натренировать некоторое управление вниманием. Люди, которые много напрягают мозг, безусловно выигрывают оттого, что тренируют это место и могут иметь больше контроля над тем, куда направлено внимание и какие пропорции энергии уделяются какой сфере деятельности сознания. Это одна история. Другая история — осознанный выбор, это не то же самое. Осознанный выбор — штука тоже довольно полезная не только в работе инженера, но и везде, где нужно принимать решения.
Например, в жизни бывает много споров. Понятно, что часто нет какого-то наилучшего мнения, поэтому есть какие-то споры. И то, насколько конструктивно проходят споры, напрямую зависит от осознанности участников. Это такая важная часть культуры общения: как мы умеем разделять своё личное мнение и объективную реальность — где что-то, во что я верю, а где есть внешний факт, который неопровержимо что-то доказывает. Люди часто это путают, и даже во всяких психотерапевтических группах и на тренингах есть много замечательных упражнений, которые направлены на то, чтобы человек разделял, что вот это его мнение, а вот это некая внешняя реальность. Есть практики безоценочного общения, ненасильственного общения, очень рекомендую.
И другая вещь. У всех есть интуиция. Бывает, когда ты уверен, что надо делать так. Почему ты уверен? Бывает сложно объяснить, и нужна определенная осознанность, довольно высокая, чтобы признать, что ты не знаешь, почему ты так хочешь. Не придумываешь какие-то странные аргументы, не пытаешься пересилить оппонента напором, силой характера, а четко сформулировать: «Я не знаю, почему так. Мне так кажется. И если ты можешь обосновать, почему так не надо, то я тебе поверю, а если тебе тоже «кажется», то у нас просто разные интуиции, и никто из нас не более прав». Это тоже очень важно. Я думаю, что в целом такая возможность рефлексировать и возможность немного отпустить своё эго в работе очень помогает. Это напрямую связано с осознанностью мотивации, с возможностью делать осознанный выбор. Вы можете отделить своё личное от объективного и рабочего.
— В режиме не психолога, а обычного человека, есть ли в окружающей жизни вещи, в которых люди ведут себя супернеосознанно, и ты, может быть, хотел бы это как-то улучшить?
— По определению большинство вещей, которые мы делаем, мы делаем неосознанно. Дел много, и, если всё осознавать, можно сойти с ума. В разных книгах это по-разному называется, но, грубо говоря, у нас есть «быстрый мозг» и «медленный мозг», «Система 1» и «Система 2». Суть в том, что есть механизмы автоматического принятия решений, которые я не осознаю. Они быстрые, но зато они сформировались без моей воли. Я не знаю, как они получились, я как-то рос, учился чему-то и неосознанно, имплицитно усвоил это всё. Есть такой механизм, имплицитное научение, который, собственно, это всё и формирует. И есть мой медленный мозг, где я осознанно, вербально могу что-то подумать. Это гораздо более свободная система. Они, естественно, связаны, поэтому то, что я усвоил автоматически, влияет на моё мышление, но у меня гораздо больше свободы в области мышления. Но это гораздо более затратно. У меня нет возможности применять это везде, но там, где мне важно, я бы хотел это применять. Если посмотреть вокруг — всё, что люди делают, вообще всё, оно на большую долю неосознанно, и это не всегда плохо, но это часто признак какой-то несвободы: как мы выбираем, чем нам заниматься, с кем нам жить и общаться, как мы решаем, что для нас важно или не важно, очень сильно всё от этого зависит. Очень многие приоритеты, которые мы расставляем в жизни, продиктованы культурой. То есть какие-то люди, как правило, очень давно, сформировали какое-то представление, которое может быть абсолютно неактуально сегодня, и поэтому я сегодня делаю какой-то выбор, который влияет на всю мою жизнь. Мы этого всего не осознаем и думаем, что делать такой выбор — это же «естественно».
— Ты сейчас о религии?
— Я обо всём в принципе, почему обязательно только о религии? Например, есть люди, которые считают, что к какому-то возрасту надо обязательно создать семью. Этот возраст у разных людей разный, но я знаю немало людей, которые считают, что сделать это нужно достаточно рано и на всю жизнь. Почему «надо»? Почему важнее создать семью сейчас, чем разобраться в том, как вообще работают отношения между людьми? Это же распространенная тема, когда ты встретил какого-то человека, вы влюбились друг в друга, всё здорово, давайте создадим семью прямо сейчас, потому что в сказках написано, что это самое главное, чего ты можешь достигнуть в жизни. Чтобы состояться как человек, я «должен» завести семью, и отсюда ощущение, что чем скорее я это сделаю, тем лучше. Но чем скорее я это сделаю, тем, как правило, хуже получится.
Когда-то было общество, в котором всё было не так, в котором никого абсолютно не интересовало, насколько вы были счастливы в браке, брак — это были имущественные отношения, достаточно осмысленные по тем временам. Были совершенно другие представления о счастье, о функции семьи, и тогда это было актуально. С тех пор всё поменялось. То, как мы сегодня оцениваем после создания семьи, хорошая она получилась или плохая, никак не связано с тем, как это оценивали люди, которые нам в некотором смысле диктуют, что нам это нужно сделать как можно скорее. Эти люди давно вымерли, а мы до сих пор думаем, что нужно поскорее создавать семью и что человек, который этого не сделал, не реализовался. И дело не в том, что надо обязательно заводить семью поздно. Надо просто обязательно подумать, зачем я это делаю сейчас, что я умею/не умею, какие у меня риски, и осознанно принять решение. Не потому, что на меня давит моё воспитание, книжки, которые я прочел, или мнение других людей, бабушка на мозг капает, что тебе 25 лет, а у тебя всё еще нет детей, какой ужас. Можно иметь детей и в 21 год, и в 18 лет — вопрос в том, почему я это сделал, как я принимал решение.
— Те вещи, в которые люди верят, эти часто используемые заблуждения выстраивают систему. И когда ты пытаешься поменять один кусочек, все остальные тоже тянутся. Например, с семьей связаны юридические вопросы.
— Да, связаны. Юридические вопросы, которые реально связаны с семьей, влияют не на всех. Например, пока нет детей — стоит подумать, нужен ли брак. Кому-то нужен, кому-то нет, зависит от того, как вы хотите управлять имуществом. Если кто-то заключает брак, чтобы иметь какие-то юридические возможности, то всегда пожалуйста, только объясни себе, что ты заключаешь брак ради этих юридических возможностей, а не для того, чтобы партнера к себе привязать веревкой. Это совершенно нормальное объяснение. Любое объяснение, которое правдиво, — нормальное. Главное, себя не обманывать.
Про семью очень много стереотипов. Например, очень сложный вопрос: хорошо или плохо жить с родителями? Важно, что очень многие люди думают об этом в категории «хорошо или плохо», а на самом деле это «полезно или не полезно», об этом надо думать. Или, например, про меня известно, что со мной можно поговорить на тему того, моногамными должны быть наши отношения или немоногамными. Нет никакого универсального ответа для любого человека, а в культуре — есть, и это противоречие. В культуре считается, что обязательно должны быть отношения, и они должны быть моногамными. Еще считается, что они должны быть гетеросексуальными, и это вообще странно. Но нигде не показано и не доказано, что так реально должно быть. Отношений может не быть, они могут быть не гетеросексуальными, не моногамными, они могут быть устроены вообще как угодно, если люди это выбрали осознанно и действуют не во вред друг другу. Другое дело, что что-то из этого удобно, что-то нет, что-то полезно или нет. Вопрос в том, как выбрано. Не ЧТО выбрано, а КАК.
— Кстати, вы же в Котлине тоже культуру строите. У вас есть один универсальный ответ на всё?
— Нет. Вопросом осознания того, какую мы хотим культуру, мы маловато занимались, надо позаниматься больше. Культура строится подспудно. Поначалу нас было мало, и мы как-то общались, нам нравилось, всё было хорошо. Потом нас стало больше, мы стали быстрее расти, стало заметно, что разные люди по-разному общаются, что-то не работает, и хочется какие-то вещи улучшить. Мы недавно начали пробовать тренинги: с какими-то внешними людьми тренерами отрабатываем разные человеческие навыки, от общения до принятия решений. В команде Котлина попробовали только один тренинг для тим-лидов, было интересно, мне понравился результат. Это хорошо даже как тимбилдинг, возможность пообщаться. Причем есть разница, как общаться: можно выпить пива, за жизнь потереть, а есть способ пообщаться продуктивно. Второй вариант мне нравится больше. Это не значит, что не надо трепаться за обедом о чем попало, но из продуктивного общения можно вынести какие-то результаты, есть, над чем подумать — есть пост-эффект. Это был хороший опыт, сделали мы это не так давно, и, думаю, будем делать еще. Культура строится не по какой-то модели («надо вот так»), она вырабатывается изнутри. У нас есть представление о том, как нам комфортнее и эффективнее, мы, разговаривая друг с другом, его постепенно синхронизируем, и так строится какая-то культура. При этом элементы каких-то готовых решений снаружи приносятся, перерабатываются, продумываются и воплощаются.
— Забавно было бы иметь такую культуру, в которой осознанные решения являются важной частью этой культуры.
— Я, честно говоря, думаю, что общение со мной немного подчеркивает такую необходимость, потому что я начинаю довольно сильно нервничать, когда вижу, что человек на чем-то настаивает и не может мне объяснить, почему. Я начинаю волноваться, что человек, исходя из этих непонятных соображений, будет дальше принимать решения, и вдруг его ветром вынесет в странное место — и что мы потом будем делать? Поэтому, когда я с кем-то спорю, я часто задаю вопросы «Почему ты так думаешь? Объясни!».
— Мозг же очень умный, он даже по текущему состоянию может достроить картинку «почему ты так думаешь».
— Да, есть такая штука, как рационализация. Есть у меня какое-то интуитивное ощущение, что вот так надо сделать, и я дальше могу с очень умным видом объяснять, почему, подгоняя аргументы под ответ.
— Например, что надо писать типы слева.
— Да-да. И это как раз тот случай, когда хорошо бы разделять «мне просто так нравится» и «есть объективные причины так считать».
Еще важно уметь признавать свои ошибки. Говорить: да, это мне просто так показалось, я не прав. Логика в этом помогает. Если я говорю: «Нам нужно А, потому что В», а кто-то мне на это сказал: «Слушай, нет, что-то А из Б не следует», то я могу посмотреть и убедиться, что да, действительно, не следует. Может случиться такой момент прозрения. Я что-то сказал, мне казалось, что это железно так, а потом оказалось, что нет, не железно, и возможно, что даже не так.
Естественно, тут есть социальные эффекты. Тот, кто должен признать свою ошибку, должен быть достаточно уверен в том, что его социальный статус от этого не понизится. Вообще, нередко он может даже повыситься, но интуитивно кажется, что это же ужасно, если я оказался не прав — меня будут меньше уважать. Это действует не только в котлиновской команде, не только среди инженеров, это действует среди всех людей в принципе. Люди очень иррационально беспокоятся за свой социальный статус, поэтому признавать ошибки трудно. Но если люди вокруг работают с тобой в одной связке, и это думающие люди, то тот факт, что ты умеешь признавать ошибки, повышает твою договороспособность, к тебе повышается доверие, и вообще, это вызывает уважение — человек явно довольно сильно в себе уверен, если он может признать: «Я только что сказал фигню, нет, всё не так». Всякий раз, когда я понимаю, что я сказал что-то не то и кто-то другой меня опроверг или переубедил, я стараюсь говорить вслух, что он прав, а я нет.
— Но это нужна какая-то процедура самотестирования. Списки когнитивных искажений.
— Да, само это не работает, можно разными способами тренироваться. Я вообще большой зануда. Когда я, очень давно, познакомился с какими-то, скажем, законами логики, они мне очень понравились, и я их часто применяю. Судя по всему, среди инженеров таких людей много, поскольку люди часто цепляются ко всякой мелочи, которая даже не важна в разговоре. Иногда это просто замедляет коммуникацию без видимого результата, но в принципе, это хороший инструмент. Есть и другие, например, те самые списки когнитивных искажений — это достаточно интересный инструмент, которым можно оттачивать свой механизм рефлексии. Но очень важно, если другому сообщаешь, что он ошибся, делать это вежливо, корректно, не нападать, потому что, конечно, признавать ошибки важно, но, когда при этом другие злорадствуют — это очень неприятно. И в следующий раз признать ошибку будет гораздо труднее.
— Особенно если это какой-то скрам-митинг и на тебя 15 человек показывают.
— Да, чем больше человек показывает, тем неприятнее. Чем больше социальная масса неодобрения, тем это неприятнее. Поэтому очень важно, чтобы, когда мы общаемся, мы делали это корректно.
— Можешь что-нибудь пожелать/посоветовать нашим читателям на Хабре?
— Очень желаю всем людям принимать решения свободно, как на работе, так и в жизни. И я считаю, что «свободно» значит, как правило, осознанно.
— Спасибо тебе большое!
Ещё больше о том, как выглядит «один день из жизни дизайнера языка программирования», Андрей расскажет 19 октября на нашей конференции Joker. А после выступления в дискуссионной зоне можно будет как следует уточнить всё интересующее, так что близкий Андрею формат «люди задают вопросы» тоже будет.
Комментарии (10)
i_osipov
22.09.2018 00:10Приятно было почитать про осознанность. Особенно интересно, что было упомянуто два её вида. По той о которой говорит Андрей, если я правильно помню, была книга "Думай медленно, решай быстро" Д. Канемана, а по той, которая про медитации есть другая книга с большим набором практик, которая так и называется "Осознанность". Рекомендую обе.
true-grue
22.09.2018 14:11+2Отрадно, что в интервью оказалась затронута и техническая составляющая. Прокомментирую пару тезисов с точки зрения академической разработки компиляторов.
1. «А про синтаксис понятно, синтаксис — это просто». Действительно, в современном учебнике по компиляторам теме синт. разбора (должно быть) отведено от силы 10-15% материала. Остальное-то, как раз, и есть самое сложное, интересное и плохо формализованное. Впрочем, понятно, что для пользователей языка это самое «остальное» не столь заметно, как синтаксис.
2. «Например, нам бы в компиляторе очень пригодились некоторые языковые фичи, которые больше никому не нужны». Вот этот момент по поводу использования конструкции сопоставления с образом для меня является очень важным. Потому что во многих даже очень солидных современных компиляторах все еще применяют неуклюжий шаблон Visitor (родом из корпоративной/ООП-культуры разработки) для обхода и трансформаций AST/IR. При этом, опять же, в хорошем учебнике по компиляторам вы «посетителей» не встретите. Вместо них используются функции высших порядков и сопоставление с образцом на деревьях/термах. На эту тему высказывались и Питер Норвиг (https://norvig.com/design-patterns/ ), Мартин Одерски (https://www.artima.com/weblogs/viewpost.jsp?thread=166742 ). В связи с этим приятно, что автор Kotlin думает о том, как переписать компилятор в более изящном, декларативном духе.jorgen
24.09.2018 10:21+2Вот здесь я тоже по Visitor прошёлся на пути к паттерн-матчингу писал https://habr.com/post/270173/
Вообще, паттерн-матчингу (ПМ) находится применение довольно быстро… если он есть. Мой самый востребованный сейчас юскейс — ассёрты в тестах. Иногда гораздо проще с ПМ писать, чем кастить результат и доставать необходимое для сравнения.
Аргументы "у нас не будет ПМ" — понятны. В дизайне языка — всё компромиссы. Но вот что интересно было бы услышать — есть ли попытки сделать синтаксис языка таким, чтобы сторонние решения по ПМ было удобно использовать (пусть даже и не так эффективно как будь это встроено в язык).true-grue
24.09.2018 12:30+1“Какие у моего велосипеда промышленные аналоги?”
В первую очередь вспоминается LLVM-код: llvm.org/doxygen/PatternMatch_8h_source.html
Вопрос по поводу реализации сопоставления с образцом «из подручных средств» мне тоже весьма близок. Для решения сложных задач внутри компилятора не хватает возможностей и в тех языках, где эта конструкция имеется (да, даже в Haskell). Кстати, в этом смысле любопытно представить, что в идеальном мире разработчики с конца 70-х годов компиляторы пишут на Пролог-подобном языке. Есть совершенно замечательная статья как раз на эту тему:
sovietov.com/tmp/warren1980.pdf
Впрочем, и здесь только лишь встроенных в язык возможностей все еще недостаточно.
И еще отдельная интересная тема — сопоставление на произвольных графах.
voidnugget
22.09.2018 19:53Списки когнитивных искажений.
Не особо помогают пофиксить эстимейты — Time-saving bias и прочее имеют совершенно иную природу чем вообще принято думать.
Когнитивное искажение формируется чаще всего из-за определённой внутренней компенсаторной потребности: "больно думать" / "больно признать" / "приятно думать" / "приятно думать только о приятном" etc
Чаще всего, в разработке, это Гало-эффект. Возникает при объектных отношениях (не люблю Кляйн), может быть применим не только к людям, но и к инструментарию.
поскольку люди часто цепляются ко всякой мелочи, которая даже не важна в разговоре
Переход от Blame Culture к Compassion Culture не решён — все коллективы успешно невротизированы, ведомы страхом и подчинением, с эмоциональной и вербальной депривацией. Subordinate Satisfaction даже у Google сейчас около 17%, и это считается нормальным повсеместно в Штатах.
Blame на русский прямо не переводиться и состоит из Accusation, Criticism, Punishment и Humiliation. Как раз то что принято у англоговорящих называть токсичным поведением.
когда при этом другие злорадствуют — это очень неприятно
Коллективов нет — есть стада и племена, с стандартными племенными "обычиями" и "ритуалами". Задачи достигнуть поставленной цели общими целями нет в принципе, потому что отношение к работе "мы — не продукт", "мы — не компания", "З/П платят — вот и чудно".
От бабушек едущих в забитом автобусе и орущих друг на друга — кому кто на ногу наступил, не особо отличается. Автобус поломается — подождут, и сядут на следующий, благо маршрут активный.
potan
22.09.2018 20:51+2«Очень мало кто страдает от того, что нет чистых мейнстримовых языков.»
От этого страдают пользователи, когда программы падают, когда уводят деньги со счета, когда разработчики не могут реализовать нужные фичи.
Только связь не все понимают.phillennium
23.09.2018 09:02Вы можете привести реальный пример того, как деньги были уведены со счёта из-за недостаточной чистоты языка?
potan
23.09.2018 14:36+1Из-зи арифметического переполнения в Solidity.
Много случаев взлома из-за переполнения буфера в C/C++, но я не знаю, использовались ли они для кражи денег.
gleb_l
Мне абсолютно импонирует способ выражения мыслей Андреем — «в основном вся энергия обсуждений рассеивается где-то в районе синтаксиса» — это же офигительно образно!
А определение свободы и попытка направление усилий на систематизацию рефлексии индивидуумов означает, что этот человек находится в N+m-ной системе ценностных координат, уже на несколько уровней выше и шире, чем уровни личного благосостояния, затем личного же душевного комфорта итд.
Один из то ли (научных) журналистов, то ли писателей, пообщавшись с ученым мировой величины, когда-то очень емко сказал, что явно чувствовал гравитацию от масштаба (читай, массы) личности, находящейся с ним рядом. Здесь похожая история — масштаб личности чувствуется из интервью абсолютно явно. Спасибо!