MongoDB CTO : ce dont les développeurs d’aujourd’hui ont besoin pour réussir

Mark Porter est CTO chez MongoDB, et un technologue avec de larges intérêts et une longue histoire dans le leadership et la pratique du logiciel. Porter a rejoint MongoDB au début de 2020, après avoir travaillé comme CTO chez Grab, une société de « superapp » de covoiturage, d’expédition et de paiements mobiles basée à Singapour. Avant cela, il a passé neuf ans à développer des services de base de données gérés par Amazon RDS chez AWS. Auparavant dans sa profession, il a investi 12 ans chez Oracle, où il a travaillé sur Oracle RDBMS, a géré l’équipe d’avancement du serveur Oracle RDBMS et a finalement gravi les échelons pour rendre compte directement au PDG Larry Ellison.

I a récemment eu l’occasion de consulter Porter au sujet de l’inscription à MongoDB, de son snobisme de la base de données relationnelle, des avantages du modèle de document, de la manière de ravir les développeurs d’applications logicielles, de la sécurisation des déploiements d’applications logicielles et de ce dont les développeurs d’aujourd’hui ont besoin de la base de données étage. Porter a également expliqué comment c’était de traiter avec Larry Ellison et pourquoi les concepteurs n’ont pas besoin de devenir des superviseurs pour « réussir ».

MongoDB

MongoDB CTO Mark Porter

Matthew Tyson : Hey Mark, merci d’avoir discuté avec moi. Vous avez pris le relais de CTO chez MongoDB au début de 2020. À quoi ressemblait cette expérience, juste au moment où la pandémie se déroulait ?

Mark Porter : Matt, merci d’avoir pris le temps. Mon parcours vers MongoDB a été fascinant. Pour être authentique et un peu gêné, je ne comprenais pas vraiment dans quoi je m’étais embarqué. Alors que j’avais utilisé MongoDB dans plusieurs emplois, je dois dire que j’étais toujours un snob relationnel. Mais au fur et à mesure que j’ai pu voir la puissance de la conception des fichiers, l’évolutivité intégrée et la haute disponibilité totalement architecturée, j’ai fini par être beaucoup plus ouvert d’esprit. Honnêtement, MongoDB est un système dispersé nativement extrêmement disponible qui gère les transactions, tandis que les bases de données relationnelles sont des systèmes transactionnels primaires uniques qui ont du mal avec la circulation et le calendrier. Il m’a également fallu un certain temps pour comprendre pleinement la puissance d’une plate-forme moderne – avec les utilisateurs de MongoDB, vous programmez naturellement dans votre langue et n’avez pas besoin de passer par cette couche de traduction SQL extrêmement difficile sur le plan cognitif. Bien sûr, SQL est mathématiquement très pur. Cependant, MongoDB vous permet de faire les choses de manière plus pratique, plus simple et plus efficace.

Tyson : Quelles sont selon vous les frontières des données ? Où MongoDB examine-t-il l’état de l’art ?

Porter : Eh bien, JSON, croyez-le ou non, repousse toujours la frontière de l’information. Nous avons lancé JSON en 2009, et la puissance de ce type de données qui est à la fois lisible et traitable par le système informatique et par l’homme se fait toujours sentir dans le monde entier. Les standards ouverts comme JSON, Parquet, etc. sont si efficaces. Et leur intégration avec les exigences de streaming et les magasins d’articles économiques substantiels sur les fournisseurs de cloud permet une combinaison de systèmes plus facile que jamais dans le passé. Nous nous concentrons vraiment sur la simplification du déplacement des informations entre les clusters MongoDB et les lacs d’informations, mais également vers et depuis MongoDB. Et nous nous occupons de tout pour vous. Tout comme nous avons supprimé la nécessité de développer un cluster de recherche séparé, de le gérer et de le mettre à niveau, nous avons ajouté la recherche Lucene open source directement dans notre moteur back-end. Pratiquement toutes les applications ont besoin d’une recherche maintenant, et avec Atlas, vous l’activez d’un simple clic sur un bouton ou d’un appel API. J’imagine de plus en plus de combinaisons comme celle-ci, tout en restant basées sur des normes et composables, afin que les individus puissent nous intégrer n’importe où dans leur flux de travail – en tant que système d’enregistrement, en tant que point d’atterrissage pour les données IoT ou en tant que puits pour tous les données à 360 degrés d’une entreprise sur ses clients et ses fournisseurs. Il s’agit d’être simple à construire.

Tyson : C’est fantastique de penser à quel point une fonction de langage relativement inoffensive comme JSON a eu un effet aussi énorme (merci, Douglas Crockford).

Je suis vraiment curieux de savoir comment vous avez fait pour rester en contact avec les designers « sur le terrain ». Comment suivez-vous le pouls des choses alors que vous maintenez et développez une opération aussi importante ?

Porter : MongoDB a en fait toujours été une entreprise axée sur les développeurs. C’est une chose à dire et une autre à le faire; vous devez désirer écouter et apprendre des commentaires qui sont donnés plutôt que d’utiliser simplement « le concepteur d’abord » comme un stratagème marketing surprise. Ils voient clair et à juste titre.

Tout d’abord, je pense que c’est une question d’état d’esprit plutôt que d’exécution du  » comment ? » du temps lors de rencontres et de conférences. De toute évidence, toutes les interactions ne peuvent pas être personnelles et la pandémie a définitivement ramené ce point à la maison pour nous et pour de nombreuses autres entreprises technologiques. Maintenant que nous sommes plus grands, avec d’innombrables téléchargements et des centaines d’innombrables inscriptions mensuelles, nous avons une assez grande équipe de relations avec les designers, un programme Champions, et nous redémarrons exactement les mêmes rencontres et conférences. Honnêtement, ce truc a du mal à évoluer. Nous avons beaucoup d’excellents outils qui nous aident à rester en contact avec les concepteurs et nos racines open source, et de nombreux éléments open source nous permettent de rester en contact avec le quartier.

Nous accueillons toujours les préoccupations et les demandes d’extraction via GitHub. Nous utilisons Jira, et nos tickets pour les améliorations sont publics, donc les utilisateurs en discutent, et ils peuvent correspondre directement avec nos ingénieurs. Nous utilisons Intercom pour l’assistance par chat. Vous pouvez vous connecter aux ingénieurs d’assistance MongoDB et obtenir une réponse normalement dans les cinq minutes, 24 heures sur 24, 7 jours sur 7. Et après cela, nous utilisons Chorus.ai, qui enregistre les enregistrements et les discussions avec les utilisateurs et les transcrit. En fin de compte, notre groupe de produits parcourt ces enregistrements et utilise ces informations pour informer ce que nous priorisons et ce que nous construisons. À un niveau plus global, nous analysons et examinons toutes les enquêtes auprès des concepteurs que nous pouvons trouver chaque année : l’étude JetBrains, l’étude Stack Overflow et l’état de JavaScript en sont quelques exemples.

Je pense que nous sommes souvent exactement dans la même position que notre clientèle, c’est-à-dire que nous avons tellement d’informations – les choisir et les examiner afin de les hiérarchiser et de les choisir – c’est ce qui est difficile. Nous faisons beaucoup de choses pour rester en contact avec les concepteurs personnellement, et en raison de l’échelle, nous apportons également des applications logicielles et des informations pour vous aider. Il n’y a pas d’algorithme de compression ou de raccourci vers cette partie du business – les êtres humains sont rendus complexes !

Tyson : Quand j’ai vu le titre de votre récent article (« Surmonter l’inquiétude et dégoût d’appuyer sur Prod »), j’avais besoin de rire. Il y a toujours une certaine appréhension lorsque le caoutchouc remplit la chaussée et que l’entreprise dépendra du code que nous venons d’écrire.

Vous avez en fait écrit un grand nombre d’excellents articles sur la façon de rendre les implémentations plus robustes (« The 180 Ligne directrice », « La jauge Goldilocks », etc.). Ma préoccupation ici est de savoir à quel point est-il difficile d’amener les individus et la culture à adopter ces pratiques ? Avez-vous des idées à ce sujet ?

Porter : (Rires.) Je suis un peu nerveux que vous lisiez mon em> trucs. Je pense que je peux étonner vos lecteurs avec ma réponse. Ces publications et ces discussions sont en fait beaucoup plus populaires et demandées par moi que tout ce que je dis à propos des bases de données ou des données. J’interviens régulièrement lors de réunions générales d’équipes d’ingénierie, et nous parlons de deux choses principales : la culture d’ingénierie et les implémentations. On m’a récemment demandé de parler à un panel de 56 DSI, et tout ce qu’ils souhaitaient discuter, c’était la culture et les implémentations ! Parce que, comme vous le dites, ce sont les 2 faces d’une même médaille. J’encadre les équipes pour me concentrer sur des discussions honnêtes et ouvertes en amont et en aval de la chaîne de direction. Les superviseurs doivent offrir aux concepteurs un contexte, et les concepteurs doivent donner aux gestionnaires des mises à jour sincères et opportunes, en particulier lorsque les nouvelles sont mauvaises.

Mais revenons à votre vraie question… Je trouve que les gestionnaires et les dirigeants ont besoin être plus courageux. Ils comprennent ce qui rendra leurs versions plus sûres, ce qui rendra leurs concepteurs plus heureux et ce qui rendra leurs sprints plus prévisibles. Quand je leur parle, je leur parle d’avoir des discussions sincères à faible enjeu, où toutes les célébrations parlent et écoutent avec une excellente intention. Une fois que cela est développé, le reste peut avoir lieu. Sans cette confiance, tout est si difficile.

Tyson : Vous avez en fait été impliqué dans un certain nombre de brevets, dont un avec Larry Ellison d’Oracle. Quelle est la procédure de réalisation d’un concept tout au long de la procédure jusqu’à un brevet ? Comment voyez-vous le rôle des brevets dans le secteur des logiciels ?

Porter : Qu’une personne avec Larry a une histoire amusante. J’étais dans un magasin attendant que mes voitures et mon camion soient réparés et Larry m’a appelé à propos de quelque chose de totalement indépendant. Mais, plus d’une heure plus tard, longtemps après que ma voiture ait été préparée, nous développions cette idée d’ajustements de la bande passante et de la résolution sensibles au réseau pour le streaming vidéo. En ce qui concerne la fonction des brevets en général, je me concentre sur deux éléments : ingénierie et commercial. Il y a une pureté particulière à apporter une idée d’ingénierie à une telle clarté que vous pouvez la révéler dans un ensemble de revendications qui forment un oignon élégant, structurer l’idée couche par couche. Et les ingénieurs doivent en être fiers : après tout, réduire le chaos à la commande est en fait ce que nous faisons.

De plus, d’un point de vue commercial, il est très important pour les entreprises d’avoir des portefeuilles qu’elles peuvent utiliser défensivement pour se protéger contre les trolls là-bas, ceux qui essaient de gagner de l’argent sans ajouter de réel avantage à l’espace lointain. Je suis fier de mes brevets, et nous avons également un programme de brevets opt-in ici à MongoDB qui aide les ingénieurs à être fiers de leurs innovations – et il y en a beaucoup en cours !

Tyson : Larry Ellison est une figure tellement connue, comment était-ce de traiter avec lui ?

Porter : Haha, maintenant les gants sont enlevés, c’est ça ? Larry est certainement une personne renommée. J’ai en fait découvert que des dirigeants comme lui, ou Andy Jassy chez AWS, ou peut-être mon patron actuel, Dev [Ittycheria], ici chez MongoDB, définissent la culture de l’entreprise – toute la méthode se résume à tout le monde tapant furieusement pour construire ou soutenir clients de l’entreprise. Larry a une réputation mitigée, cela ne fait aucun doute. Mes interactions avec lui étaient techniques – autour de la construction d’une base de données et d’une technologie de serveur vidéo – et son enthousiasme était constamment de construire le produit élégant idéal, celui qui permettrait aux clients d’économiser de l’argent et les aiderait à aller plus vite. J’ai beaucoup appris de lui au cours des années où j’ai travaillé à la fois indirectement et finalement directement pour lui.

Par exemple, nous avions une culture de réunion où toutes les conférences d’état-major des officiers avaient lieu le lundi, puis le niveau suivant était le mardi, puis dans l’entreprise pendant la semaine. Ce faisant, chaque membre du personnel de l’entreprise a eu la chance de prendre conscience des originalités ou des orientations de la réunion du personnel de Larry, personnellement, avec la possibilité de commenter et de poser des questions en une seule semaine.

Je pense Là où Larry a eu du mal et continue de se débattre, c’est qu’il laisse les cadres supérieurs autour de lui construire une culture de ne pas bien traiter les clients, et il n’intervient pas pour y remédier. Dans l’ensemble, je suis un fan de Larry et j’apprécie profondément les 13 années où j’ai eu l’avantage de travailler avec lui et Oracle. Cela dit, je pense que la culture de l’autonomisation de l’ingénierie, de la sincérité intellectuelle et de l’excellente intention que Dev a construite ici est assez fantastique – et je suis toujours fondamentalement un stagiaire de ce jeu vidéo spécifique.

Tyson : J’ai lu que vous aviez fait du codage sur l’Apple II en Pascal, et je dois vous informer, cela me rappelle des souvenirs. (Lorsque vous produisiez un logiciel pour aider les Alaskiens à découvrir les métiers, j’écrivais Ultima clones Dans le même article, vous dites que « chaque niveau de gestion doit avoir un niveau de gestion de contributeur individuel comparable et le salaire doit être comparable. » Cela m’a vraiment frappé. Comment pouvons-nous convaincre les entreprises de faire en sorte qu’il en soit ainsi ? Surtout compte tenu de la fréquence de la croyance selon laquelle une personne doit arrêter de coder et commencer à gérer à un moment précis ?

Porter : Pour commencer, Ultima ! Quel monde formidable c’était. C’était incroyable ce que nous pouvions faire avec 64 Ko de mémoire, un processeur exécutant un peu plus d’un million d’instructions 8 bits par seconde et 140 Ko sur une disquette conduire ? Fou.

Revenons à votre question sur la nécessité d’entrer dans la gestion pour réussir. C’est un véritable bouton chaud avec moi. Ces dernières années, chez News Corp, AWS, Grab, et maintenant chez MongoDB, j’ai travaillé pour avoir des échelles de facteurs spécifiques et des échelles de gestion comparables. Et pas seulement comparables en termes de rémunération – comment toujours équivalent en obligation et en influence. Par exemple, chez MongoDB maintenant, les ingénieurs distingués sont au même niveau que les vice-présidents et sont impliqués dans les niveaux appropriés de prise de décision et de préparation. Cependant, comme vous le dites, il y a cette croyance répandue selon laquelle vous devez entrer dans la gestion pour gagner le plus d’argent et avoir le titre le plus élevé et le plus d’effet. Déchets dans l’ensemble. Dans chacune de ces entreprises, j’ai rédigé un dossier sur les différences entre être un facteur privé senior et un leader senior. Les deux rôles se soucient profondément de l’entreprise, évidemment, et des individus. Mais les dirigeants individuels ont un intérêt viscéral profond et sont responsables de chacune des batailles, de la croissance, de la rémunération et de la profession de leur peuple. Alors que le facteur individuel senior coache les gens, mais se concentre aussi viscéralement sur la qualité du code, des processus et de l’architecture.

Tyson : J’ai lu quelque part que vous maintenez votre coder des côtelettes en enseignant à vos enfants des programmes (Scala, Java et autres). Avez-vous des idées sur la façon de maintenir cet équilibre travail/vie insaisissable ?