Почему не стало больше стартапов на языках программирования?

Почемунесталобольшестартаповнаязыкахпрограммирования

Несколько недель назад я модерировал панель, на которой кто-то спросил: «Почему из сообщества языков программирования не выходит больше стартапов?»

Это было на панели о карьерном росте, связанной с конференцией по разработке и реализации языков программирования (PLDI). Человек спрашивал, почему мы не видим коммерциализации более передовых языков программирования и технологий анализа программного обеспечения.

много боли программиста. Но почему мы не видим передачи этих «глубоких» технологий из исследований в промышленность – это то, о чем я думал с тех пор, как учился в колледже , когда я решил, что хочу провести свою жизнь, улучшая жизнь программистов. Многие другие области, от робототехники до баз данных, имеют более четкие пути к коммерциализации. Но когда дело доходит до новых языков программирования или анализа программного обеспечения, путь передачи технологий часто длится десятилетия, если он вообще существует. Я думал об этом как аспирант по языкам программирования, затем как профессор, а теперь как основатель Akita, API-ориентированной компании по наблюдению, основанной на применении методов анализа программного обеспечения к трафику API.

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

The Tweet thread that led to this post.

Тема твита, которая привела к этому сообщению.

В этом посте я сосредоточусь на том, почему мы не видим больше быстрорастущих стартапов, ориентированных на разные языки и инструменты, исходящие от сообщества PLDI, на «глубокую технологическую» сторону инструментов программирования. Есть много других инструментов для разработчиков, которые отлично подходят для быстрорастущих стартапов. Есть и другие способы успешной передачи технологий (крупные компании; проекты с открытым исходным кодом), которые я здесь не буду описывать.

Команды разработчиков программного обеспечения покупают инструменты

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

A popular point of view about developer tools buying.

Популярная точка зрения на покупку инструментов разработчика.

По 2027, все согласны с тем, что в инструментах разработчика есть деньги. За последние несколько лет мы наблюдали, как Salesforce приобрела Heroku за $ 420 миллионов, а Microsoft приобретает GitHub за 7,5 миллиардов долларов. Сегодня частная компания Postman оценивается в 2 миллиарда долларов, а HashiCorp – в 5,1 миллиарда долларов. Компании-разработчики также стали публичными и преуспели: рыночная капитализация New Relic составляет более 4 миллиардов долларов; рыночная капитализация Datadog превышает $ 43 млрд.

Но люди не тратят большие деньги на что-то, основанное на новых языках программирования и технологиях, особенно на технологиях, ориентированных на помощь людям в написании. код с большим количеством гарантий. Полный размер рынка статического анализа в 2021 оценивается в $ 748. 1 миллион в 2020 и является планируется достичь всего $ миллионов по 2027 . А разработка языков программирования в основном осуществляется при поддержке крупных компаний, как в случае с Go и Python, или предприимчивых разработчиков языков, которые находят другой способ поддержать себя, загоняя свои сообщества разработчиков ПО с открытым исходным кодом, как в случае с Ruby, Elm. , и Джулия.

Ясно, что программисты испытывают боль – и боль, которую могут решить некоторые из этих новых языков и инструментов. Что дает?

Но программисты голосуют своими бюджетами

Может ли быть, что руководители инженерного отдела выбирают инструменты вопреки желанию своих разработчиков? Так говорят многие (например, см. Здесь ).

Частый вопрос о покупке инструментов разработчика.

Но данные этого не подтверждают. Согласно состоянию нации разработчиков в ( через SlashData ), 83% разработчиков теперь имеют право голоса при выборе инструментов. И они предпочитают потратить этот бюджет на продукты, которые облегчают их работу, а не на инструменты, повышающие качество их кода. Хорошо это или плохо, но эти две проблемы не одно и то же.

Графика из блога SlashData.

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

Так почему же разработчики предпочитают тратить деньги на одни инструменты, а не на другие?

Работающие разработчики не согласны t покупка «предметов роскоши»

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

Вот несколько потребностей программистов, которые не не соответствует мировоззрению PL:

  • Отсутствие ошибок: обычно это не главный приоритет. Общей целью в языковом дизайне и анализе программного обеспечения является «надежность»: если есть ошибка, инструмент ее найдет. Если вы строите космический корабль, на котором одна ошибка означает, что вы потеряете жизни и миллионы долларов, имеет смысл устранить возможные ошибки с помощью зубчатой ​​расчески. Однако для обычного веб-приложения существует большой компромисс между исправлением ошибок и функциями доставки. Разработчикам веб-приложений часто требуется что-то, что помогает им быстро создавать программы, не жертвуя излишней правильностью – не наоборот.
  • Люди не хотят знать обо всех своих проблемах. Я часто вижу «причудливые» техники, предполагающие, что разработчики хотят знать обо всем, что не так с система. Ваш друг, который всегда говорит вам все, что может пойти не так, ваш самый популярный друг? Люди не хотят знать все свои проблемы, особенно когда не все проблемы имеют значение. Если вы хотите порадовать разработчиков, дайте им упорядоченный список того, что делать дальше, а не исчерпывающий список потенциальных проблем, которые заставят их отключить ваши уведомления.
  • Технологические стеки представляют собой органически развивающиеся экосистемы, а не централизованно планируемые объекты. Теперь о том, почему ни один язык программирования или фреймворк не возьмут верх. Мечтать об идеальных решениях в любой другой области так же приятно, как мечтать об Едином Истинном Языке. Но большинство систем с определенной степенью зрелости выбирают второй язык, а затем и третий. Различные слои технологического стека берут свои собственные языки и технологии. Это не потому, что организации дезорганизованы или не продумали все до конца. Языки развиваются, потребности системы развиваются, и новое поколение программистов развивается.
  • С точки зрения работающих разработчиков идея ноль ошибок, наличие временной шкалы, позволяющей устранить все ошибки, и полный контроль над технологическим стеком могут показаться невозможной роскошью.

    Методы, разработанные сообществом языков программирования, не сломаны, но их нужно адаптировать к потребностям работающих разработчиков! В следующем разделе я расскажу, как это сделать. (И если вам интересно, как узнав об этом, мы изменили то, что делает Акита, мы поговорим об этом подробнее в

это сообщение в блоге .)

Инструменты должны вписываться в повседневную жизнь разработчиков

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

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

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

  • Проблема в том, что инструмент решение важнее всего остального. В сообществах технических языков программирования я часто вижу больше упор на то, что люди создают, а не на проблемы, которые они решают, и часто допустимо иметь смутное, гипотетическое представление о пользователе. Например, я часто вижу, как энтузиасты функционального программирования приводят аргументы о том, что их языки лучше для разработчиков по техническим причинам (больше гарантий; элегантность), которые не связаны с первоочередными проблемами, с которыми сталкиваются команды разработчиков программного обеспечения. Если люди не применяют эти технологии, возможно, они не «понимают», насколько хороша эта технология, а то, как они могут помочь им в решении их основных проблем.
  • Встраивание в рабочие процессы имеет большее значение, чем техническое «вау». Специально для инструментов «глубоких технологий» часто делается акцент на том, что они делают. это ново или круто. После нескольких десятков пользовательских интервью с разработчиками я пришел к выводу, что в какой части экосистемы живет каждый инструмент. Когда я спрашивал разработчиков, почему они приняли инструмент X или Y, часто отвечал, что он работает с их языком программирования или инфраструктурой. , или что у него была интеграция со Slack / GitHub / Jira, которую они хотели. Многие из инструментов «глубоких технологий», которые я вижу, предполагают, что разработчик переключится на совершенно новую цепочку инструментов, чтобы получить относительно небольшой набор преимуществ. Для большинства команд разработчиков ПО это не запускается. Упаковка часто имеет большее значение, чем хнический раствор. Если вы один разработчик, запускаете что-то несколько раз с целью показать, что что-то возможно, тогда это нормально, если вывод будет неуклюжим, и вам придется запрашивать его или вручную украшать, чтобы понять его. Если это инструмент, который вы собираетесь использовать изо дня в день и делиться результатами со своей командой, то наличие инструмента, который потратил время на сглаживание острых углов, упростит вам задачу результат, который вам нужно увидеть, и облегчить вам выполнение того, что вы хотите, с результатом имеет большое значение.

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

Путь вперед

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

Что касается инструментов программирования, вот какие инструменты необходимы, чтобы получить более широкое распространение:

  • Более удовлетворение потребностей разработки и рабочих процессов там, где они есть
  • Более совместимость с существующими инструментами разработчика
  • Дополнительные дополнительных улучшений, которые работают с существующими
  • Более дизайн, который априори подходит разработчику галстуки
      Меньше фокусироваться на 125% гарантии
    • Меньше сосредоточьтесь на создании «новой вселенной»

    • Потребитель средств программирования, желающий иметь лучшие инструменты, для вас тоже есть роль! Вот что, я считаю, должно произойти, чтобы экосистема стала более приветливой к инструментам «глубокого» программирования:

      • Более принятие инструментов, которые немного грубоваты – трудно создать хороший опыт разработчика для чего-то, чего раньше не существовало!
      • Более принятие исследования сложности инструменты
      • Дополнительные отзывы о проблемах, которые вы хотите использовать с определенными инструментами / классы инструментов для решения
      • Меньше вера в «серебряные пули»
      • Меньше мечтая об «одном языке, чтобы править ими всеми»
      • Меньше терпение к процессам, которые приводят к снижению продуктивности разработчиков, особенно в тех случаях, когда это влияет на бизнес (и, следовательно, их легче исправить)

      Очевидно, легче сказать, чем сделать! Я был в многолетнем путешествии по этому вопросу в Akita – и мы все еще много чего пытаемся понять. Но чем больше мы говорим об этом, тем больше у нас появляется надежда на то, что энтузиасты инструментов разработки смогут объединиться, чтобы сделать жизнь разработчиков лучше, используя самые современные возможности!

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

      Фото Alex Knight на Unsplash .

  • Leave a comment

    Your email address will not be published. Required fields are marked *