Язык программирования — это тоже продукт. Он помогает разработчикам выражать свои идеи так, чтобы их мог интерпретировать компьютер. Может показаться, что развивать язык — это брать последние достижения теории языков программирования, реализовывать их и из года в год выкатывать разработчикам. Это не так. Егор Толстой, Kotlin Product Manager, и Андрей Бреслав, руководитель проекта Kotlin, рассказали, зачем JetBrains бесплатный язык программирования, как он устроен и откуда приходят новые пользователи. Статья вдохновлена выпуском подкаста make sense о Kotlin.
Язык — это в первую очередь рабочий инструмент, который миллионы людей используют ежедневно по много часов. Все эти люди решают разные задачи и сталкиваются с разными проблемами. Для команды разработки Kotlin знание этих сценариев и болей — основной источник идей, как улучшить пользовательский опыт и дать новые возможности программистам.
Мы начали делать Kotlin десять лет назад, а первый релиз вышел зимой 2016 года. Изначально он задумывался как язык, который улучшит жизнь Java-программистов. Сейчас на Kotlin пишут даже приложения для браузеров и iOS. Современный Kotlin — универсальный язык программирования с большим количеством приятных для разработчиков фич, статически типизированный, заточенный под большие проекты и поддержку крупных кодовых баз.
В серии статей мы расскажем про то, как Kotlin организован с продуктовой точки зрения, как устроен менеджмент продуктов у программистов для программистов, что такое developer experience, как его можно измерить и улучшить.
Зачем JetBrains делает бесплатный язык программирования
Мы на этот вопрос отвечаем, кажется, с 2011 года — когда анонсировали, что делаем Kotlin. Напрямую на Kotlin JetBrains не зарабатывает, у компании другие источники дохода — платные продукты. Это целая экосистема инструментов, которые разработчики используют каждый день.
Кстати, у Егора в блоге есть отдельная статья про исследования рынка инструментов для разработчиков. Если вам интересно узнать, сколько в мире разработчиков, какие языки сейчас популярнее всего или что в своей работе каждый день используют фронтендеры — обязательно прочитайте.
У JetBrains есть четыре причины заниматься созданием языка.
Продажа инструментов. Если нашим языком пользуется много разработчиков, можно пытаться продавать им какие-то платные инструменты. Прямо сейчас мы этого не делаем напрямую — у нас нет никаких специфичных платных инструментов для Kotlin.
Но при этом Kotlin поддерживается в IDE от JetBrains, которые не заточены под какую-то конкретную технологию. Например, та же IntelliJ IDEA поддерживает Kotlin — и какая-то часть ее продаж приходится на Kotlin-разработчиков. Это достаточно сложно отследить, но мы видим, что среди пользователей платной версии IntelliJ IDEA их немало.
Узнаваемость бренда. Если раньше JetBrains была компанией, которая делает классные IDE, то теперь мы — компания, которая сделала Kotlin. А это совершенно другой уровень интереса — просто потому, что за кофе люди чаще обсуждают языки программирования, чем IDE. И нам это действительно помогает. Если когда-то в самом начале JetBrains был локомотивом для Kotlin, то теперь уже оба бренда помогают друг другу — и мы видим, что все больше людей знает про JetBrains благодаря Kotlin.
Kotlin как наш собственный инструмент. У нас в JetBrains много разработчиков, и от их продуктивности сильно зависит эффективность компании. Идея начать делать Kotlin вообще родилась из того, что мы не хотели продолжать использовать Java. И сейчас Kotlin используется почти во всех наших продуктах. Например, в IntelliJ IDEA на Kotlin написано 1,5 миллиона строк кода. А недавно мы запустили Space — инструмент для интегрированной работы команд, который написан на Kotlin сразу для всех платформ: Android, iOS, сервер, веб, десктоп. Ребята, которые его разрабатывают, говорят, что без Kotlin такой продукт создать было бы в разы сложнее.
Потому что это круто. Огромная часть культуры JetBrains — это любовь к решению сложных инженерных задач. Делать свой собственный язык программирования — это очень-очень круто, и даже одного этого факта уже достаточно, чтобы оправдать все усилия.
Итог — Kotlin приносит деньги компании косвенно. Он — верхушка воронки продаж, потому что к тому моменту, когда люди задумываются о покупке наших продуктов, они уже знают JetBrains как «тех ребят, которые сделали один из самых популярных сегодня языков программирования». И это важно.
Как устроен язык программирования
Язык программирования — это не только синтаксис, но и целая система различных инструментов. Далеким от программирования людям мы объясняем это так: представьте себе Word. Так вот — мы работаем над тем, чтобы в «Word для программистов» можно было удобно описывать свои идеи и превращать их в приложения для мобильных устройств или веба.
То есть задача команды Kotlin — помочь программисту выражать свои идеи, минимально отвлекаясь на какие-то посторонние детали, предостерегать его от ошибок, подсказывать, как писать качественный и легко читаемый код. В решении этой задачи участвуют десятки различных компонентов, которые объединены в сложную инженерную систему с большим количеством внутренних связей.
Синтаксис. Это набор правил, по которым пишется программа. За синтаксис отвечают дизайнеры языка. Код в первую очередь пишется для людей, которые его читают и редактируют. Из этого следует две важные задачи:
Нужно дать пользователям единый понятийный аппарат, который поможет понимать идеи друг друга.
Сделать язык выразительным, чтобы у каждой задачи могло быть несколько способов решения.
Интегрированная среда разработки (IDE). Правильно работать с синтаксисом позволяет поддержка языка в IDE, том самом «Word для программистов». Что делает IDE:
подсказывает подходящие по смыслу конструкции;
подсвечивает некорректный код;
запускает код и помогает искать в нем ошибки;
упрощает частые преобразования.
Помимо этих базовых операций, IDE — целый комбайн разных фич, которые упрощают конкретные пользовательские сценарии. Например, помогают работать с системой контроля версий, заниматься отладкой микросервисов, управлять инфраструктурой.
Библиотеки. Есть множество библиотек для всего на свете — от асинхронного программирования до записи на диск. Пересылка данных по сети, обращение к веб-сервисам, запись или парсинг чего-то в формате JSON, общение с другими девайсами по Bluetooth — что угодно может существовать в виде библиотеки. Особняком стоит стандартная библиотека, которая поставляется с языком. Она включает в себя манипуляции с числами, строками, коллекциями и тому подобными вещами.
Библиотеки позволяют создавать свою программу из готовых блоков, написанных другими людьми. Чем слабее развита библиотечная экосистема, тем обычно тяжелее разработчику. Писать все с нуля — долго и сложно, а библиотеки помогают сразу выполнить полезную работу.
Компилятор. Это специальная программа, которая переводит код на Kotlin в машиночитаемый формат. Kotlin умеет компилировать код сразу для трех окружений — JVM, JS и Native. Это значит, что технически Kotlin можно исполнять практически на любой платформе, которую вы знаете: браузер, смартфоны, холодильник или умная колонка.
Помимо этого компилятор делает еще много всяких полезных вещей — проверяет код на ошибки, оптимизирует его объем.
Подробно и глубоко компилятор Kotlin мы разбирали в отдельном выпуске подкаста Podlodka.
Документация. Когда разработчик сталкивается с проблемой, он может найти помощь на четырех уровнях: в самом продукте, в документации, в сообществе или в команде техподдержки. Мы стараемся держать документацию максимально полной, потому что это основной источник знаний — как для новичков в Kotlin, так и для опытных кодеров, которые ищут ответ на какой-то вопрос.
Сообщество. Программы, правила, инструменты и все такое — это замечательно, но Kotlin — это в первую очередь люди. За последний год почти 6 миллионов людей работали с кодом на Kotlin, из которых 1,2 миллиона делали это регулярно.
Часть из них активны в сообществе: они пишут библиотеки, проекты на Kotlin, обмениваются знаниями, задают вопросы, отвечают на вопросы, шарят что-то в соцсетях, рассказывают друг другу, как что делать, пишут книги, выступают на конференциях. Это помогает распространять знания о Kotlin, привлекать в продукт новых людей и помогать уже существующим пользователям.
Влияние языка программирования на продукт и людей
Язык программирования влияет на продукт только косвенно. Итоговый результат сильно зависит от прямоты рук программиста: можно на «хорошем» языке написать очень плохой код, а можно и наоборот — создать отличный код на «плохом» языке. Но даже такое косвенное влияние — довольно сильное.
Итак, на что влияет язык:
UX продукта — от него зависит размер итогового приложения, скорость его работы, платформы, доступные для запуска.
Надежность и стабильность продукта. Отличный пример – billion dollar mistake.
Создадите ли вы в целом свой продукт. В некоторых случаях разработчиков искать очень легко, а в других вам придется месяцами охотиться за редкими специалистами.
Атмосферу и культуру вашей команды. Сообщества программистов очень отличны по своему духу. Поклонники одного языка могут быть в среднем более токсичны или, наоборот, открыты всему новому, чем поклонники другого.
Последний пункт стоит развернуть отдельно. Например, программисты на COBOL очень редко делают хипстерские сервисы, так же, как и значимая часть программистов на С++ — у них фокус внимания с опыта конечного пользователя и красивого UI смещается в сторону технических деталей.
Но отличия видны и на менее радикальных примерах. Возьмем Java и JavaScript. На обоих языках можно писать бэкенд, но делать это будут разные люди, с разной ментальностью, подходом к работе и разной культурой. Соответственно, продукты тоже получатся разные, ведь они похожи на тех, кто их создает.
Откуда берутся новые пользователи
Когда ты работаешь над продуктом, который не приносит денег компании напрямую, измерить его успех — довольно нетривиальная задача. Мы смотрим на это с двух сторон: прагматичной и эмоциональной.
Эмоциональная. Это то, что мы видим своими собственными глазами. Фидбэк счастливых пользователей в социальных сетях, новые кейсы по использованию Kotlin в крупных компаниях вроде Atlassian, Adobe или Netflix, или факт, что большая часть Android-приложений, которыми мы пользуемся каждый день, написана на Kotlin. Понимание, что твои решения и их реализация напрямую влияют на миллионы разработчиков, а косвенно — и на всех пользователей Android-приложений, просто безумно драйвит.
Прагматичная. Продиктованная как нашим собственным видением, так и целями JetBrains — это количество активных разработчиков на Kotlin, которые пишут какой-то код регулярно. Глобально на этот показатель влияют две вещи: приток новых пользователей и их возвращаемость.
Возвращаемость — комплексный показатель. На него влияет сразу многое: простой онбординг, стабильность и качество продукта, простые пути, с помощью которых можно сразу использовать язык для решения своих рабочих задач. Про это я детально расскажу в следующей части цикла статей.
Приток новых пользователей идет из трех основных источников.
Разработчики из других экосистем. Причины у них могут быть разные. Самая простая — смена места работы или проекта, вместе с которыми меняется и технологический стек. Поэтому мы сильно заинтересованы в том, чтобы Kotlin появлялся в списке используемых технологий в разных компаниях. Другая причина — это решение какой-то крупной боли, от которой страдают разработчики какого-то другого языка. Именно это произошло, когда Android-разработчики получили доступ к Kotlin. Им настолько понравилась разработка на нем, что под их давлением Google сделал Kotlin официальным языком разработки. Третья причина — возможность попробовать что-то новое или запрыгнуть на волну хайпа.
Новички в программировании. Каждый год рынок разработки растет примерно на 8,5% за счет выпускников университетов, самоучек, специалистов, которым приходится изучать элементы программирования. Они ищут язык, который не только поможет изучить основы программирования, но и даст возможность найти хорошую работу или уйти во фриланс.
Новые возможности для существующих пользователей. Это случается, когда существующие пользователи получают возможность легко и просто делать что-то новое — например, Android-разработчикам становится проще завести бэкенд для своего проекта.
Один из залогов роста аудитории языка программирования — четкое понимание, в какие сегменты мы хотим идти и какой у них объем. Например, нужды мобильных разработчиков сильно отличаются от нужд бэкенд-разработчиков, и без дополнительной работы над инструментами, создания новых библиотек язык очень трудно использовать на разных платформах. Поэтому делать язык, который сразу отлично закроет сценарии всех сегментов — практически невыполнимая задача.
Анализируя сегменты, мы смотрим на их объем, динамику роста, существующие проблемы и боли, какие задачи для них Kotlin уже решает хорошо, а какие пока не очень, где стратегия выхода на рынок понятна, а где — нет. Это регулярная работа, которая помогает нам реагировать на изменения структуры всего рынка.
Для анализа мы используем известную классификацию стадий роста продукта из книги «Crossing the Chasm». Ранние последователи у нас сейчас есть практически во всех сегментах разработки. Люди используют Kotlin для Data Science, пишут на нем игры, решения для IoT и даже занимаются научными вычислениями — физическим моделированием процессов и подобными вещами. В сегменте кроссплатформенной мобильной разработки мы только подходим к бездне, в бэкенд-разработке — перешагиваем ее, а в Android вовсю захватываем Late Majority и смотрим на Laggards.
Ранних последователей получить достаточно просто. Но чтобы полноценно выйти в новый для себя сегмент рынка, мало быть просто языком программирования — надо быть продуктом, который решает конкретные боли пользователей в этом сегменте. Нужно предоставлять новым пользователям какую-то ценность. И она должна быть существенной, потому что для любого человека изучение нового языка и технологии — это серьезная инвестиция.
Ценность инструмента для разработчиков
Ценность языка программирования сильно зависит от самого человека, от его бэкграунда и целей. И хотя в Kotlin заложено конечное количество ценностей, люди очень по-разному расставляют для себя субъективные приоритеты. Осознанный человек может говорить, что ему Kotlin нравится из-за возможности быстро обнаруживать ошибки или из-за того, что код получается короче. Но если его разговорить, окажется, что ему «просто нравится» — в целом комфортно, и все. Это признак синергии. Разные аспекты, складываясь вместе, дают гораздо большее удовольствие и комфорт, чем в языке, которым программист пользовался раньше.
Мы опираемся на следующие ключевые ценности:
Читаемость кода. Люди в реальности пишут гораздо меньше кода, чем читают. Пишем мы только тот код, который способны написать в одиночку, а читаем то, что написали многие другие разработчики. Kotlin оптимизирован для удобства чтения.
Безопасность. Kotlin старается предостерегать разработчика от ошибок и поддерживать его в процессе написания кода. Это помогает удерживать его в состоянии потока, которое, с одной стороны, позволяет разработчику быстрее добиваться результата, а с другой — дает чистый приток дофамина.
Интероперабельность. Kotlin позволяет программисту использовать библиотеки, написанные на других языках. Это очень важно, потому что, несмотря на молодость языка, разработчики получают доступ к 20−25 годам работы других сообществ. С другой стороны, Kotlin очень легко интегрировать в уже существующий проект. Для этого не нужно выкидывать всю кодовую базу и переписывать с нуля — можно это делать по одному файлу.
Эти базовые ценности мы используем, чтобы выстроить value proposition (ценностное предложение) для любого сегмента. Например, в нашем кроссплатформенном мобильном SDK KMM, мы делаем упор на:
Переиспользование одной и той же бизнес-логики на двух платформах во избежание ошибок.
Возможность легко реализовывать функциональность, специфичную для каждой платформы, самостоятельно.
Простое встраивание в существующие большие кодовые базы.
Кто такие менеджеры продуктов в Kotlin
Исторически в JetBrains главным инструментом менеджмента продуктов была техника догфудинга — когда сотрудники тестируют решение на себе. Например, разработчики IDEA сами принимают продуктовые решения: начиная от того, какие конкретно проблемы решать, и заканчивая тем, как именно реализовать ту или иную фичу. Это становится возможным, потому что они ежедневно используют свой продукт и регулярно сталкиваются с теми же болями, что и пользователи (подробнее см. в видео о культуре догфудинга в JetBrains).
В команде Kotlin ситуация отличается. Мы своими руками не разрабатываем конечные пользовательские продукты, а делаем компилятор и инструменты, поэтому догфудинг не дает нам полного понимания своей аудитории. Роль менеджера продуктов — лучше всех знать свой сегмент пользователей, их боли и сценарии. Эта информация помогает находить самые важные проблемы и драйверы роста и вместе с командой разработки придумывать крутые решения для них.
Эту информацию менеджер продуктов обычно получает из интервью с разработчиками, продуктовой аналитики, статей и докладов, анализа обратной связи, самостоятельной разработки демо-проектов. От менеджера продуктов не ожидается, что он будет экспертом в разработке — в команде и так много крутых инженеров. Важно понимать свой продукт на таком уровне, чтобы разговаривать с его пользователями и быть способным понять обратную связь. В нашей команде есть менеджеры продуктов и с техническим бэкграундом, и совсем без него.
Опыт показывает, что самое главное — не собственный опыт разработки, а гибкое мышление и любознательность. Мы постоянно ищем новых специалистов — а на отдельном лендинге рассказали про вакансии.
Развивать язык программирования — сложная, но очень интересная задача. В этой статье мы коснулись только одной из ее составляющих — рынка языков программирования. В следующий раз я расскажу, как выглядят программисты с точки зрения менеджера продуктов: какими инструментами и методами исследовать их поведение, помогать решать их проблемы, что такое developer experience и на какие метрики языка программирования он влияет.
Статья вдохновлена выпуском подкаста make sense о Kotlin с Андрем Бреславом и Егором Толстым. В подкасте make sense Юра Агеев, основатель ProductSense, вместе с гостями говорит о том, что важно при создании продуктов. Еще несколько интересных эпизодов:
— о выстраивании отношений с командой разработки и важности технических навыков;
— об аутсорс-разработке, работе с заказчиком и развитии бизнес-мышления;
— о продуктовом мышлении у разработчиков, технических навыках у продактов и культурном коде.
