El Next Chapter de Dev Productivity: Alineando la Experiencia con la Excelencia

Hola a todos. Gracias por unirse a esta charla sobre el próximo capítulo de la Productividad de Desarrollo, alineando la experiencia con la excelencia. Mi nombre es Jeff Schnitter. Soy Arquitecto de Soluciones en Cortex, y francamente, no estoy seguro de si estoy calificado para dar la charla sobre la Productividad de Desarrollo y la alineación de la experiencia con la excelencia en toda la industria. Trabajo con un equipo de marketing increíble que estudia esto, y ellos analizan el panorama y la competencia.

Así que, la intención de mi charla no es realmente hablar de todo eso. Se trata realmente de compartir mi experiencia personal que he visto tanto como cliente de la Productividad de Desarrollo, la Excelencia en Ingeniería, y luego mostrarles el otro lado, que es mi oportunidad de trabajar con otros clientes en este espacio.

Así que, me gustaría comenzar con una pequeña historia sobre la parábola de la rueda de bicicleta del 25%. Ojalá hubiera una parábola, en realidad. No hay una parábola. Tuve un sueño anoche antes de dar esta charla, y iba a montar mi bicicleta en la ciudad. Yo llevé la bicicleta a la ciudad.

Estaba en el coche, y saqué la bicicleta del maletero, y noté que el 75% de la rueda delantera había desaparecido, y había sido comida por roedores, y pensé que esto debía ser algún tipo de señal para esta charla. Ahora, puedes ver en la imagen que hice que ChatGPT creó para mí que no tengo idea de lo que estaba pasando aquí, y estaba tratando de pensar, ¿hay una parábola aquí? Me gustaría señalar que en mi sueño, miré esa rueda, y el primer pensamiento que tuve fue, ¿sería posible que pudiera montar esta bicicleta aunque solo tengo el 25% de la rueda? Y ChatGPT es realmente amable. Después de que le pedí que mostrara una rueda del 25%, puso el 23% en este objetivo. Me hizo preguntarme, ¿hay una historia aquí? Y probablemente estoy agarrándome de las ramas, pero creo que para relacionar esto con la productividad de desarrollo y la excelencia en ingeniería, hay una parte de mí que piensa que solo estamos como al 25% del camino. El software es un viaje, y este espacio, la capacidad de tener la necesidad de un portal de desarrollador interno para este tipo de producto, existe debido a la evolución del software, y hay una parte de mí que piensa que esto es una señal, número uno, de que me estoy agarrando de las ramas para encontrar una metáfora, pero número dos, pensando que tal vez hay una historia aquí, y creo que parte de la historia es que la excelencia en ingeniería es difícil, y yo creo que he tenido días en los que al final del día, siento que he estado montando una bicicleta que solo tiene un cuarto de rueda, y es un poco doloroso en la parte trasera, pero lo que pasa es que lo superamos. Así que me encantaría escuchar sus comentarios después de que escuchen esta charla. ¿Creen que estamos al 25% del camino en este viaje desde la productividad de desarrollo, la excelencia en ingeniería, y dónde podríamos potencialmente completar el resto de las porciones aquí? Puedo imaginar que estas cuñas podrían relacionarse con inteligencia artificial, cómo vamos a hacer la propiedad automatizada, cómo vamos a averiguar su ecosistema basado en las integraciones que están alimentando, pero me encantaría escuchar sus pensamientos.

Gracias por escuchar esa loca historia sobre la parábola de la rueda de bicicleta. Así que, lo que van a ver en esta charla es que van a ver algunas diapositivas geniales preparadas por el equipo de marketing, y luego será muy claro las diapositivas que yo he preparado, pero esta diapositiva realmente resuena conmigo porque es el mismo viaje que he estado en. Creo que cuando comencé mi carrera en los últimos 15 años, descubrí que estaba pasando mucho tiempo en la experiencia del desarrollador, aunque no lo llamábamos así en ese momento. Yo era un ingeniero de construcción y liberación.

Estaba trabajando en herramientas que los desarrolladores usaban, y descubrí que estaba tratando de averiguar la mejor manera en que podríamos usar esas herramientas para hacer que los desarrolladores fueran más productivos, hacerlos más felices, lograr el trabajo que querían hacer. Creo que ha sido una evolución natural avanzar hacia la excelencia en ingeniería porque la experiencia del desarrollador es parte de la historia, pero no abarca todo. Creo que DevEx se trata realmente de las herramientas que estás usando y reducir la fricción para que los desarrolladores hagan sus vidas más fáciles.

La excelencia en ingeniería toma una mirada a la historia completa, y creo que lo que he encontrado es que hay una gran cantidad de superposición entre los dos. La historia que voy a contar es sobre lo que encontré trabajando en Workday. Estuve allí durante 16 años, y voy a guiarte a través de ese viaje sobre cómo pasé de la experiencia del desarrollador a la excelencia en ingeniería, y luego voy a extender la historia desde que me he unido a Cortex, que construye un portal de desarrollador interno, y tuve la oportunidad de hablar con numerosos clientes sobre su viaje.

Así que, una buena experiencia de desarrollador hace felices a los desarrolladores. Un gran NGX hace prosperar el negocio, y esto se relaciona con la felicidad de los desarrolladores. Yo veo estas cosas como una y la misma de alguna manera porque, aunque NGX observa el negocio en su conjunto, si tienes un NGX realmente bueno, significa que has allanado el camino para que los desarrolladores hagan lo que quieren hacer, que es escribir código, y entraremos en eso un poco más.

Así que, soy ingeniero de corazón. No soy un creador de diapositivas, así que realmente necesitaba ayuda para armar esta presentación, y lo que quería transmitir es que la excelencia en NGX es realmente un viaje constante. Nunca vas a alcanzar realmente ese objetivo final porque esto es un cambio constante que está ocurriendo, y mi experiencia fue que siempre te estás moviendo hacia la siguiente gran cosa. Esa es la cuestión sobre el software: implementas algo y luego descubres que hay una manera mejor y más inteligente de hacerlo.

El problema es que si trabajas en una empresa que se está volviendo cada vez más exitosa, comenzarás a adoptar estas cosas en diferentes momentos a través de tu organización. Tendrás tus primeros adoptantes. Tendrás tus adoptantes tardíos, así que, ¿cómo gestionas todo eso? ¿Cómo averiguas todas esas cosas que están ocurriendo dentro de tu organización y tratas de averiguar el camino a seguir porque tendrás tus adoptantes tardíos que no tienen esa nueva tecnología? Nuevamente, tienes tus primeros adoptantes, y luego la siguiente cosa vendrá, y por eso creo que la excelencia en NGX es realmente difícil porque estás tratando de proporcionar esas herramientas para la experiencia del desarrollador. Estás tratando de proporcionar la manera que hace que las cosas sean más eficientes, funcionen mejor, cuesten menos, así que, ¿cómo impulsas todo eso?

Así que, ChatGPT al rescate. Y cuando ChatGPT creó este gráfico para mí, me di cuenta de que mi trabajo realmente no está amenazado, al menos a corto plazo, por lo que ChatGPT puede hacer. Creo que este es un gráfico tan horriblemente llamativo que quise incluirlo. De alguna manera, creo que soy como esta mujer con el vestido y un ojo, como, ¿qué está pasando? Es un poco como mi rueda de bicicleta de un cuarto. Es un verdadero caos ahí afuera, y quise mantener esta diapositiva aquí porque, aunque es una diapositiva sin sentido, el gráfico realmente no tiene sentido. Hay mucha confusión ahí afuera con todas las grandes herramientas que están llegando. La adopción de esas herramientas tiene sentido. Sabemos que te llevará por este camino hacia la excelencia en ingeniería. Aún es realmente difícil entender todo eso, así como este horrible gráfico.

Así que, quería compartir mi viaje en Workday. Como mencioné, estuve allí durante 16 años, una empresa super exitosa, realmente avanzada técnicamente. No quiero repasar todos los elementos de esta diapositiva, pero quería señalar que aquí hubo una evolución. La evolución muestra que siempre te estás moviendo de una cosa a la siguiente. A veces, puedes perder esa perspectiva del bosque por los árboles y darte cuenta de que estás trabajando en una sola migración o en una sola característica. Creo que a menudo es útil dar un paso atrás y mirar la suma de las cosas en las que has estado trabajando a lo largo de varios años para entender verdaderamente que este es un viaje. Te estás moviendo constantemente de la cosa anterior a la siguiente, y realmente es muy difícil mantener todas estas cosas funcionando juntas porque a menudo habrá múltiples flujos.

Ahora, he seleccionado un puñado de ellos que quería mostrar aquí, pero el punto es que estas cosas a menudo van en paralelo. Así que, los desarrolladores están trabajando en múltiples cosas a la vez. A menudo no conocen todas estas tecnologías.

Así que, piensa en un desarrollador cuyo trabajo es realmente entender, digamos, que van a estar escribiendo código Java. Podrían tener que entender la red, cómo todo eso funciona junto, pero además de eso, vas a cambiar la forma, número uno, de cómo vas a empaquetarlo, cómo lo vas a desplegar, los diferentes tipos de entornos donde ese código va a ser escrito. Esto es una gran carga cognitiva para el desarrollador. Así que, aunque estás haciendo todo por esos desarrolladores, tratando de darles las mejores herramientas, las herramientas que tienen más sentido, introduces mucha complejidad.

Y una de las cosas que aprendí en este viaje al mirar la lista de herramientas CI CD es que sentí que el camino hacia la excelencia en ingeniería era tener estandarización. Así que, esencialmente luché una guerra santa al principio de mi carrera donde quería asegurarme de que los equipos estuvieran usando las mismas herramientas CI CD. Aprendí de la manera difícil. Esa no es una pelea en la que quieras involucrarte. Lo que pensé que era excelencia en ingeniería, que era la misma forma de hacer las cosas para tener estándares, no resonó con los desarrolladores. Así que, aunque fue doloroso tratar de luchar esa batalla por un tiempo, lo que terminé aprendiendo es que los desarrolladores quieren usar las herramientas que los hacen más eficientes.

Así que, la productividad del desarrollador se trata de dar a los desarrolladores las herramientas que quieren usar y la capacidad para que ellos logren el resultado final, que es escribir buen código, escribir código eficiente, escribir código seguro, código que no va a romper el banco basado en la forma en que está arquitectado, en la forma en que está desplegado. Y así, eso fue algo clave que aprendí. Ha sido un largo viaje para mí, pero creo que comencé a aprender el marco del desarrollador, que es reducir la fricción para que puedan hacer lo que quieren hacer, que es escribir más código de características. Todo lo demás se interpone en el camino de eso.

Así que, incluso en este viaje que encontré en Workday donde cambias herramientas CI CD, rompiste un monolito en cientos de microservicios, cambiaste la forma en que empaquetas. Cualquiera que haya tenido una larga carrera podría estar familiarizado con ver la forma en que se empaqueta el código desde un simple archivo tar hasta el gestor de paquetes de Red Hat, rangos de documentos, gráficos de Helm, despliegues de Kubernetes. Todas estas cosas están destinadas a facilitarte la creación de buenas aplicaciones, pero realmente ponen carga cognitiva en el desarrollador. Así que, el desafío realmente es cómo tomamos la productividad del desarrollador y nos aseguramos de que se alimente en la excelencia en ingeniería. Así que, quería mostrar cómo fue mi viaje, y le pedí a ChatGPT una vez más, que mostrara cómo he estado aprendiendo este camino que mencioné. Tratar de imponer y establecer estándares en los desarrolladores no era lo correcto. Así que, este fue mi aviso para intentar mostrarte cómo ha sido mi viaje. Nuevamente, no estoy preocupado por la IA tomando el control del mundo en el corto plazo. Me alegra no haber tenido que crear este gráfico. Soy un gran fan de los 49ers. Perdí un poco la fe y simplemente no volví a mi viaje de aprendizaje después de que los 49ers perdieron el Super Bowl hace años. Todos tuvimos una caída durante la pandemia. Pero en serio, lo que estoy tratando de mostrar con este gráfico es que realmente es un viaje. Estoy tratando de entender ese camino hacia la excelencia en ingeniería. Tienes que probar cosas. Vas a probar cosas que funcionan.

Vas a probar cosas que funcionan. Vas a probar otras que no. Pero aprenderás sobre la mentalidad del desarrollador y la mentalidad de realmente la organización y tratar de hacer que las dos cosas se unan.

Así que, quiero hablar un poco sobre lo que he aprendido sobre la excelencia en ingeniería, ahora que me he unido a Cortex, donde tengo la oportunidad no solo de ver la forma en que una empresa está abordando el problema, sino la forma en que numerosas empresas lo miran. Y lo que he aprendido es que los clientes están en diferentes caminos. Así que, van a comentar en diferentes puntos de entrada de ese viaje de DevEx a la excelencia en ingeniería. Y algunos de ellos van a ser como yo, donde podrían estar tratando de imponer estándares que pueden o no funcionar dentro de su organización. Tienes que entender que diferentes culturas se adaptarán al viaje de Dev productividad a la excelencia de manera diferente. Y así, eso ha sido realmente útil para mí para entender que la cultura juega un papel en esto.

Y la disposición a ser reacio al riesgo o estar dispuesto a asumir riesgos a medida que avanzas es un diferenciador clave sobre cómo podrías querer abordar el problema. Y luego creo que definitivamente estoy viendo dónde puede encajar la IA, a pesar de los gráficos cuestionables y las imágenes de bicicletas que la IA ha construido para mí en esta presentación. Creo que hay una gran oportunidad para que la IA encaje. Tienes una amplia gama de un ecosistema de ingeniería donde tienes diferentes herramientas. Estás extrayendo datos de múltiples fuentes, múltiples equipos, tal vez has tenido múltiples adquisiciones de diferentes maneras de extraer datos. La IA va a poder ayudar. He visto esto en mi empresa donde estamos trabajando en la incorporación automatizada y tratando de mantener a los equipos actualizados automáticamente. Puedes observar las señales que existen en las diversas herramientas e integraciones que tienes y extraer eso. Y creo que hay una gran oportunidad allí. Es parte del viaje.

Tal vez sea parte de esa rueda de bicicleta del 25% donde estamos a mitad de camino, pero aún no hemos llegado del todo. Y definitivamente he visto que con los portales de desarrolladores internos, es más que solo el catálogo y los propietarios. Tienes que tener eso como tu base. Pero, ¿a dónde vas desde allí? ¿A dónde vas desde asegurarte de que sabes cuáles son tus herramientas de on-call , cuáles son tus herramientas de CICD, cuáles son tus herramientas de cobertura de código? Tienes que ir más allá de eso y quieres ver una imagen mucho más grande. ¿Tienes las métricas? A todos les encanta DORA. ¿Tienes las métricas para mostrar qué tan bien las buenas herramientas de experiencia del desarrollador que tienes han establecido esa buena base, allanado el camino para la excelencia en ingeniería, la cosa que la organización quiere asegurarse de que tienes todas esas cosas, seguridad, rendimiento, costo, integrados en la forma en que haces tu negocio.

Así que esta es parte de ese viaje más grande que he visto la forma en que diferentes empresas están mirando ese problema y cómo están avanzando con ese camino de DevEx a la excelencia en ingeniería. Y creo que lo que terminé afinando para terminar esta historia de viaje y la metáfora del viaje es que creo que DevEx y la excelencia en ingeniería son esencialmente la misma cosa. Que, mientras he trabajado no solo apoyando a un grupo de desarrolladores cuando estaba trabajando en DevEx en Workday, cuando estaba trabajando en ese camino hacia la excelencia en ingeniería con esos usuarios que estaban construyendo una aplicación muy robusta, y desde que llegué a Cortex y pude ver lo mismo con los clientes, DevEx y la excelencia en ingeniería para mí significan lo mismo. ¿Cómo liberas a los desarrolladores para asegurarte de que tienen tiempo para hacer lo que quieren hacer, para hacer lo que mejor saben hacer? Y eso es correcto, código de características. El código de características lleva tu producto al mercado, puede convertirse en el diferenciador para tu competencia.

Y por eso creo que es lo mismo. Ahora podríamos etiquetarlos de manera diferente, DevEx son las herramientas y el reducir la fricción para el desarrollador, la excelencia en ingeniería realmente lo mira en su totalidad, cómo la organización piensa sobre el éxito, cómo piensan sobre todos esos factores, pero en última instancia, realmente es uno y lo mismo. Se trata de reducir la fricción de la manera más económica, la manera más eficiente y la manera más segura que puedas para llevar tus ideas y tu producto a producción.

Finalmente, me gustaría terminar para hacerte saber que nos encantaría continuar esta conversación contigo sobre la excelencia en ingeniería. Cortex está organizando una serie de actividades de excelencia en ingeniería en las siguientes ciudades. Nos encantaría verte unirte a nosotros para añadir a la conversación. Me encantaría escuchar tus pensamientos sobre completar ese 25% de la rueda de bicicleta. ¿Qué significa esa cuña? ¿Cuáles son los próximos pasos que ves en el viaje de DevEx a la excelencia en ingeniería para completar la historia? Y al completar la historia, digo simplemente llevarnos al siguiente paso porque el viaje realmente nunca termina. Habrá la próxima mejor cosa, habrá la próxima innovación. Así que tenemos que asegurarnos de que tenemos procesos, tenemos que asegurarnos de que tenemos las herramientas adecuadas en su lugar que puedan ayudarnos a adaptarnos a ese cambio, estar preparados para ese cambio, y estar listos para estar en ese viaje, idealmente con la bicicleta que está completamente construida.

Así que yo espero continuar la conversación contigo. Muchas gracias por tu tiempo hoy.