Kotlin a explosé en popularité au cours des dernières années et est devenu la langue préférée de Google pour créer des applications Android, mais ce n’était pas le plan initial. Dans cet épisode de Dynamic Developer, nous avons discuté avec Hadi Hariri, vice-président de la défense des développeurs chez JetBrains , de la façon dont une entreprise, mieux connue pour les IDE, a créé un langage de programmation et construit une communauté florissante autour de lui. Cet article est une transcription de notre conversation éditée pour plus de lisibilité.

Bill Detwiler: Parlons de l’expérience de JetBrains avec Kotlin et de la construction de la communauté autour d’elle. Dites-moi comment cela s’est produit. Parlez-moi du processus de démarrage. Commencez par le début.

Hadi Hariri: Bien sûr. Je pense que lorsque nous avons lancé Kotlin, nous avions essentiellement une communauté établie autour de JetBrains. JetBrains cette année avait en fait 20 ans. Nous avons lancé Kotlin en 2010, nous avions donc déjà 10 ans d’avance en termes de construction d’une communauté autour de notre marque et de certains de nos produits.

Donc d’un côté, je dirais, ce n’est pas comme si nous avions commencé sur un état propre. Mais de l’autre côté, dans un sens, nous l’avons fait, parce que nous étions une entreprise qui construisait essentiellement des outils de développement, des IDE. Alors que la majorité d’entre nous, la plupart d’entre nous chez JetBrains, et je dirais que beaucoup de gens dans la communauté accepteraient qu’une langue soit aussi un outil, il semble y avoir une différence entre une langue et un IDE pour beaucoup.

Lorsque nous avons annoncé que « Oh, nous créons maintenant un langage », tout le monde a dit: « Non. Tenez-vous-en aux IDE. JetBrains ne devrait pas faire de langages. » Nous sommes comme, « OK ». C’était donc assez difficile. C’était assez difficile.

Je pense qu’il a fallu de très nombreuses années, je dirais, pour commencer à … Enfin pas beaucoup, beaucoup d’années. Il a fallu un bon nombre d’années aux gens pour commencer à s’intéresser à la langue et à construire une communauté autour d’elle. Nous avons franchi certains jalons qui ont rendu ce tournage soudain très haut et très rapide. Mais au début, c’était très, très difficile, je pense.

Bill Detwiler: Que pensez-vous de cette résistance dans la communauté qui existait déjà autour des outils de JetBrains? Pourquoi pensez-vous qu’ils hésitaient?

Hadi Hariri: Je ne pense pas que cela concerne vraiment JetBrains en tant qu’entreprise elle-même. Je pense que les gens commencent à identifier certaines marques pour certaines choses. C’est un peu comme Google est un moteur de recherche et ils vendent des publicités. Demain, s’ils proposent une voiture, vous vous dites … D’accord, eh bien, Google est différent. Ils peuvent proposer une voiture ou acheter une entreprise qui fabrique une voiture.

Mais si Nike demain arrive et dit: « Eh bien, je fabrique des parapluies », les gens se diront: « Pourquoi [faites-vous] des parapluies? » Je pense que si, encore une fois, un langage est un outil de développement, il y avait beaucoup de cet état d’esprit du genre: « Eh bien, vous ne faites que des IDE. Vous faites des IDE et des outils pour d’autres langues. Pourquoi voulez-vous créer votre propre langue?  » Ensuite, bien sûr, la chose supplémentaire est juste comme, « Eh bien, vous ne créez pas simplement un autre contrôle de version. Vous créez un langage. »

Je pense qu’il y a cette barrière psychologique entre ce qu’est une langue et tout autre outil. Avec une langue, les gens, il faut vraiment les convaincre, et ils ont vraiment besoin de voir la valeur pour l’adopter. Parce que c’est beaucoup d’investissement. C’est beaucoup de risques. Comme je vais prendre mon …

Comme demain, si vous prenez une entreprise qui écrit, par exemple, du code Java, et que quelqu’un utilise IntelliJ IDEA, qui est notre outil, et que quelqu’un utilise Eclipse; demain, si cette personne part, et qu’elle choisit, elle pourrait simplement utiliser l’autre IDE. Ce n’est pas fondamental pour le succès ou l’échec du projet.

Alors qu’avec une langue c’est. Droite? Avec une langue, il y a plus d’engagement. Vous devez vous assurer que les personnes qui montent à bord connaissent la langue, les personnes qui partent ne vous laissent pas dans le froid. Il est donc beaucoup plus difficile d’adopter simplement une langue que ce n’est qu’un outil. Droite? Même si nous pensons que c’est essentiellement la même chose. Donc, je pense que la barrière psychologique pousse également les gens à revenir contre cela, si cela a du sens.

VOIR: 
Développeurs: 7 guides gratuits sur les langages de programmation populaires

(TechRepublic)

Kotlin n’a pas été créé spécifiquement pour Android

Bill Detwiler: C’est une excellente transition, je pense, vers quelque chose que je voulais en venir, à savoir les leçons que vous avez apprises lors du développement de Kotlin, qui est vraiment devenu le langage préféré pour le développement sur la plate-forme Android, non? Quelles sont les leçons que JetBrains a apprises en surmontant cette résistance, en développant ce langage et en construisant la communauté, en disant: « Eh bien, ils ne sont pas seulement un créateur d’IDE. Ils ont ce langage, et oui, J’en suis assez content, et oui, je vais l’adopter. « 

Hadi Hariri: Je pense que tout d’abord, les leçons apprises. C’est difficile, un peu de répondre, car cela dépend de qui et de quoi, car il y a tellement de gens impliqués dans Kotlin. Je pense que la seule chose que nous, non pas que nous apprendrions, mais quelque chose que je ressens, dans un sens, que nous essayons d’éviter, c’est d’être démotivé avec la réaction initiale.

Si vous regardez la réaction initiale, il y avait une certaine positivité, et il y avait quelques personnes dans la communauté qui ont dit: « Oh, ça a l’air intéressant. Oh, ça a l’air génial. Peut-être que nous devrions lui donner une opportunité. » Mais il y avait aussi beaucoup de négativité. Il y avait aussi beaucoup de choses comme: « Tenez-vous-en à ce que vous faites. Nous n’avons pas besoin d’une autre langue. Ceci est très similaire aux langues existantes. Vous n’apportez aucune valeur. »

Notre persistance à prendre les bons commentaires, à en tirer parti et à essayer d’ignorer le négatif qui n’était vraiment pas constructif, et à persister, je pense, a été la plus grande leçon que je dirais que nous avons également apprise, et je pense aussi que c’est important pour les gens à prendre la négativité avec une pincée de sel. Écoutez-le, mais ne soyez pas démotivé. Si vous avez une vision claire, si vous avez une idée claire de votre destination, essayez de suivre cette voie. Soyez persévérant avec ça.

Une autre chose est que peu de gens le savent vraiment, mais nous n’avons jamais créé Kotlin pour Android. Nous avons créé un langage que nous voulions utiliser pour développer nos propres IDE, car nous étions fatigués de certaines choses avec les langages existants. Nous avons dit: « D’accord, essayons de faire ceci. C’est une bonne opportunité d’offrir également de meilleures expériences à d’autres personnes. »

Puis, très tôt, nous avons reçu des commentaires de quelques personnes disant: « Oh, je l’ai essayé sur Android. Cela ne fonctionne pas. » Et nous avons dit: « Eh bien, désolé. Android n’est pas notre objectif. » Mais peu de temps après, nous avons commencé à voir, non, ce n’est peut-être pas si difficile de résoudre ce problème, et peut-être que cela pourrait être une bonne opportunité, ce qui était formidable. Leçon apprise. Écoutez la première fois. Droite? Mais c’est là que ça a commencé à reprendre.

C’est cette idée d’écouter les gens, de comprendre leurs besoins et d’essayer de mettre cela dans le même genre, de s’aligner sur la vision que vous avez pour aller de l’avant, je pense que c’est important.

Je dois dire qu’une chose qui, selon moi, nous a caractérisés au fil des ans, et il y a certainement des leçons que nous devons apprendre ici, et il y a certainement place à amélioration, c’est que nous sommes assez ouverts sur ce que nous faisons, les produits que nous construisons, les feuilles de route, et essayons d’écouter autant que possible la communauté.

Mais c’est aussi, lorsque vous développez en plein air et que vous obtenez beaucoup de retours, vous devez trouver un équilibre entre la vision et où vous voulez aller et où tout le monde veut aller. Qui est-ce qui a dit … C’était Ford, non? Cela dit à propos des voitures.

Bill Detwiler: C’est vrai. Il aurait donné aux gens, s’il avait demandé aux gens ce qu’ils voulaient, ils auraient dit des chevaux plus rapides.

Up to Edit: Ouais.

VOIR:
Les meilleurs langages de programmation à apprendre en 2020

(TechRepublic)

Soyez réceptif aux commentaires constructifs des clients

Bill Detwiler:  Je pense que c’est un point très important, car ce sont les entreprises de toute l’histoire, grandes et petites, qui doivent essayer de faire face au même problème. Comment était-ce pour JetBrains? Vous avez tous ces retours. Certains sont négatifs. Une partie peut être constructive. Vous voulez créer une communauté, vous ne voulez donc pas priver tout le monde de ses droits. Comment avez-vous trouvé cet équilibre dans le cas de JetBrains?

Hadi Hariri: Je pense que nous sommes plus ou moins bons en termes de raisonnement avec les gens. Si vous considérez JetBrains en tant qu’entreprise, nous le sommes généralement … Cela a commencé avec trois personnes il y a 20 ans. Quand je suis arrivé, il y avait environ 150 personnes. D’accord? Maintenant, il y a environ 1 400 personnes. Pourtant, malgré cela, il est très plat dans la hiérarchie.

Je ne peux jamais … Je ne … Généralement, la façon dont cela fonctionne est que vous n’imposez pas vos manières chez JetBrains. Vous dites: « D’accord, je pense que nous devrions le faire. Voici les millions de raisons pour lesquelles je ressens cela fortement à ce sujet. » Mais quel que soit mon poste ou mon titre, si quelqu’un trouve un bon raisonnement selon lequel nous devrions le faire différemment, nous le faisons. Nous essayons de tout raisonner. Lorsque nous voulons ajouter une fonctionnalité à un produit, même au sein des équipes, nous essayons de comprendre pourquoi cela est précieux, pourquoi nous devrions l’ajouter, pourquoi nous devrions l’ajouter de cette manière.

Je pense donc que l’équipe de Kotlin a été très bonne, et en particulier Andre, qui est le chef d’équipe de Kotlin, il a toujours été très bon et réceptif aux idées, et a donné aux gens les raisons pour lesquelles cela peut ne pas fonctionner et la façon dont cela fonctionne. Je pense que faire cela au grand jour, par exemple, comme tous les …

Nous avons maintenant ce processus ouvert, appelé Kotlin Evolution and Enhancement Process, où les gens peuvent en fait déposer des demandes de fonctionnalités sur GitHub ou sur notre outil de suivi des problèmes. Ils proposent un scénario, puis nous en discutons ouvertement. Nous disons: « D’accord. Eh bien, ce scénario peut couvrir cela, mais il ne couvrira pas ces choses, alors peut-être que ce ne serait pas une bonne idée, car cela ouvrirait les vannes à tous ces autres problèmes. »

Je pense que cela semble généralement fonctionner. Être réceptif aux commentaires, mais essayer de raisonner avec les gens pour savoir pourquoi nous devrions ou ne devrions pas l’accepter. Je pense que c’est généralement ainsi que nous essayons d’équilibrer les choses.

VOIR:  Les développeurs Android devraient-ils passer de Java à Kotlin? Voici les conseils de Google sur l’échange de langages de programmation (TechRepublic)

Bill Detwiler: Pensez-vous que cela produit une communauté plus investie? C’est quelque chose dont je parle régulièrement aux entreprises. Cela semble encore plus évident lorsque je parle à des éditeurs de logiciels et à des personnes qui font du développement open source. Les développeurs, les ingénieurs, les codeurs et les personnes impliquées dans le processus de développement s’attendent à ce que ces concessions soient acceptées. « Hé, écoute. Je vais faire une demande de fonctionnalité. » Vous allez le regarder. Vous allez m’en parler. Vous allez faire … Il y a juste plus que, disons, pour utiliser une sorte d’analogie, un constructeur automobile.

Il semble y avoir quelque chose dans la communauté du logiciel où cela ressort le plus. Lorsque les entreprises, lorsque les personnes travaillant sur des projets peuvent exploiter cela et faire preuve de transparence, elles obtiennent beaucoup de récompenses. Les gens ont tendance à aborder cela et à dire «Oh ouais». Ils apprécient que même si la réponse est non, ou même si la réponse est peut-être impopulaire, au moins vous deviez prouver aux gens par la logique et la raison et, comme vous l’avez décrit, « Hé, voici pourquoi nous allons faire cela, ou voici ce que nous n’allons pas faire. « 

Hadi Hariri: Ouais. C’est drôle en fait, car il y a quelques jours à peine, j’ai tweeté, j’ai dit qu’imaginez si les constructeurs automobiles agissaient comme nous le faisons en tant que développeurs de logiciels. Quelqu’un dépose un problème pour Tesla et dit: « Je veux six roues. Si vous ne me donnez pas six roues, je vais acheter une Ford. » C’est comme si vous deviez essayer de dire: « D’accord. Essayons de comprendre pourquoi vous ne pouvez pas avoir six roues, ou pourquoi nous n’avons pas la bande passante pour implémenter six roues aujourd’hui. »

Alors oui, je pense qu’il y a un compromis. Mais je pense qu’en fin de compte, cela fonctionne bien. L’une des raisons pour lesquelles, l’une des choses … Parler des leçons apprises. Lorsque vous avez un outil de suivi des problèmes, qui consiste essentiellement à déposer des demandes de fonctionnalités, de bogues, peu importe, qui est ouvert, ce qui est notre cas, c’est très, très transparent.

Pour vous donner un exemple, nous avons un problème qui existe depuis 12, 15 ans. Il a beaucoup de votes. Une leçon que nous avons apprise, que même si nous n’avons pas la bande passante, même si nous n’avons même pas de plans … Si nous n’avons pas de plans pour mettre en œuvre cela, nous devrions le dire. Nous disons simplement: « Écoutez. Cela n’arrivera pas. » Les gens apprécient cette transparence et ils apprécient cette honnêteté. Ils apprécient que vous communiquiez, ce sont les leçons que nous avons apprises. Communiquer. Dites-leur ce qui se passe.

Maintenant, c’est aussi parfois difficile. Quand vous avez, comme par exemple, une demande qui dure depuis cinq ans, ce qui ne devrait pas, mais bon, c’est la vie, c’est comme ça que les choses fonctionnent, et il se passe quelque chose depuis longtemps … De votre point de vue , vous vous dites: « Dois-je vraiment envoyer une mise à jour tous les six mois et dire: » Eh bien, nous ne travaillons toujours pas là-dessus. Eh bien, nous ne travaillons toujours pas là-dessus. «  » Non? C’est donc un équilibre très difficile.

Ensuite, vous faites venir des gens qui disent: « Oh, pourquoi est-ce que vous nous ignorez? » et d’autres choses. Maintenant, avec les médias sociaux, c’est un peu comme une attaque de foule, non? « Ecoutez. JetBrains a ignoré ce problème pendant quatre ans. Allons tous leur dire. »

Mais je pense que la chose importante ici est, si vous êtes transparent, si vous dites aux gens: « Regardez. Voici le plan. Nous travaillons là-dessus » ou « Nous ne travaillons pas là-dessus », c’est la chose la plus précieuse. Certaines personnes pourraient l’aimer. Certaines personnes pourraient détester ça. Certaines personnes pourraient dire: « Eh bien, si vous ne travaillez pas là-dessus, je vais utiliser un concurrent. » Mais vous ne pouvez pas rendre tout le monde heureux tout le temps comme on dit.

VOIR:
Google: si vous créez une nouvelle application Android, utilisez le langage de programmation Kotlin

(TechRepublic)

Bâtir une communauté prospère, c’est être là où se trouvent vos clients

Bill Detwiler: Y a – t-il eu une erreur que vous pensez avoir tous commise tôt et dont vous avez appris ou que vous voyez faire d’autres entreprises? Vous avez beaucoup parlé de leçons. Y a-t-il quelque chose que vous dites: «J’aurais aimé que nous le fassions», qui sert d’avertissement à d’autres personnes qui essaient de créer une communauté autour d’une langue, d’un ensemble d’outils, d’un produit ou d’une plate-forme?

Hadi Hariri: Je pense que la seule leçon que nous avons apprise est que nous devons communiquer davantage avec nos utilisateurs sur l’état des choses.

Bill Detwiler: D’accord.

Hadi Hariri: Même quand nous sentons qu’il n’y a rien à mettre à jour, un coup de coude occasionnel de notre part en disant: « Mes amis, nous examinons toujours cette question. Elle est toujours en cours. Nous y reviendrons dès que nous peut, « les gens apprécient cela. Ils n’ont pas l’impression que vous les ignorez. Je pense que c’est important.

Je ne dirais jamais que nous avons fait une erreur en faisant des demandes de fonctionnalités et des bogues à l’air libre. Je pense que c’est très, très précieux. Cela nous a vraiment donné cet ADN d’être aussi transparent que possible avec nos utilisateurs, et de leur fournir de nombreux canaux de communication.

Je pense que c’est aussi une leçon très importante pour les entreprises. Souvent, lorsque vous regardez les entreprises, elles les considèrent du point de vue de la manière la plus efficace pour nous de fournir un soutien, par opposition à pourquoi nous n’activons pas autant de canaux que possible pour les clients, afin qu’ils pas besoin de faire un effort massif pour nous joindre. Je pense que c’est une leçon très importante qui …

Bill Detwiler: Il s’agit donc d’abaisser ces barrières entre …

Hadi Hariri: Oui, exactement.

Bill Detwiler: … vos clients, les développeurs et vous, et en veillant à ce que les gens se sentent comme, « Hé, écoute, même si la réponse est non, j’ai une réponse. »

Hadi Hariri: Ouais. Je pense que c’est important.

Bill Detwiler: Pensez-vous que c’est une exigence maintenant pour réussir dans l’environnement actuel? Il semble que c’est exactement ce à quoi les gens s’attendent, qu’il s’agisse de votre constructeur automobile dans une certaine mesure ou d’un logiciel.

Maintenant, je serais d’accord avec vous. Je pense qu’il y a certains publics qui sont beaucoup plus passionnés, et les développeurs s’intègrent dans cela, en tant que personne qui a une ingénierie et a appris à coder sur Fortran et Pascal à l’époque, les gens se sentent passionnés par les choses sur lesquelles ils travaillent, les langues. ils ont passé du temps sur les outils qu’ils utilisent.

Mais cela semble persister dans une variété de produits et d’entreprises que nous vivons aujourd’hui. Il semble que ce soit le monde dans lequel nous sommes. Pensez-vous que … C’est votre expérience, on dirait, avec Kotlin, avec les autres outils que JetBrains fait?

Hadi Hariri: Je pense que c’est essentiel. Je pense que si vous voulez bâtir une communauté, vous devriez être là où se trouvent les gens. Vous devriez être là pour eux. Vous devriez vous engager avec eux. Vous devriez interagir avec eux. Vous devez être aussi transparent que possible avec eux pour essayer de construire cette confiance et construire un produit réussi autour de lui. Sinon, cela ne fonctionne tout simplement pas. Surtout dans notre domaine.

Sûr. Vous avez absolument raison. Nous nous attendons à cela, en particulier avec les médias sociaux. De nos jours … Mais il y a deux types d’entreprises, non? Il y a ces entreprises qui sont activement présentes sur les réseaux sociaux, sur différents canaux, essayant de vous aider. Ensuite, il y a ceux qui veulent contrôler les dégâts. Lorsque vous vous faites arnaquer, ou que vous êtes ignoré … Vous-même, vous avez probablement vu un million de fois quelqu’un tweeter et dire: « Merci beaucoup, XO et Y, de m’avoir ignoré, bla bla, blabla. » Puis immédiatement, ils vous répondent sur les réseaux sociaux.

Ensuite, il y a d’autres entreprises qui … À l’époque, je ne sais pas si vous vous en souvenez, nous avions ces choses, des avions. Ils volaient dans les airs. Ouais. Promoteur développeur, je volais beaucoup. Il y avait deux types de compagnies aériennes. Il y en avait un que je pouvais annuler, réserver, changer de réservation, faire tout ce que je pouvais sur Twitter avec eux. Ensuite, il y a eu l’autre à laquelle leur interaction sur Twitter était limitée, «Veuillez remplir ce formulaire ou appeler ce numéro de téléphone».

Je suis fan du premier. En fin de compte, mieux leur entreprise vous traite, mieux vous en faites la promotion, plus elle obtient de bouche à oreille. Donc pour nous, si vous voulez bâtir une communauté, vous devez bien traiter les gens. Ensuite, cela s’épanouit dans le bon sens.

Pour vous donner quelques chiffres, lorsque nous avons lancé Kotlin, en termes de communauté, nous utilisions le BBS. Vous vous souvenez du BBS?

Bill Detwiler: Les anciens services de babillard électronique?

Hadi Hariri: Avec l’ASCII …

Bill Detwiler: Oui, oui, oui.

Hadi Hariri: Mais nous étions sur IRC. C’était comme six d’entre nous, littéralement comme six d’entre nous, deux d’entre nous de JetBrains et quatre autres personnes. Il ne s’est jamais rien passé. Puis un jour, j’ai dit à mon collègue, je me suis dit: « Vous savez quoi? Peut-être que nous devrions juste essayer Slack. » Nous avons créé une chaîne Slack. Ensuite, cela a commencé à s’accumuler. Nous avons maintenant, je pense, environ 30 000 personnes sur la chaîne Slack. Et il y a une centaine de chaînes différentes là-bas. C’est une communauté très accueillante.

Mais cela prend aussi du temps. Cela demande des efforts. Vous devez être là. Vous devez modérer. J’y suis souvent. Mes collègues sont souvent là-bas, s’assurant que nous avons un code de conduite en place, en nous assurant que si quelqu’un sort de la ligne, nous les poussons en quelque sorte et disons: «Écoutez, ce n’est pas le comportement attendu». Il ne s’agit pas seulement de développer la communauté, mais il est également important de garder cette communauté conviviale, un endroit sûr et un lieu accueillant, ce qui est tout aussi essentiel.

Infolettre pour les développeurs

Des langages de programmation les plus en vogue aux emplois avec les salaires les plus élevés, obtenez les nouvelles et les conseils des développeurs que vous devez savoir.
Hebdomadaire

Inscrivez-vous aujourd’hui

Regarde aussi