Developer Experience¹ es un término² con un significado autodeclarable – la experiencia de los desarrolladores – pero elude la definición en el sentido de que las personas lo invocan en diferentes momentos por diferentes razones que se refieren a diferentes cosas. Por ejemplo, el puesto actual de nuestra propia Sarah Drasner es “VP de Experiencia de Desarrollador” en Netlify, por lo que es algo muy real. Pero el título de un trabajo es solo una de las formas en que se usa el término. Profundicemos un poco y apliquémoslo a las diferentes formas en que la gente piensa y usa el término.
La gente piensa en empresas específicas.
Escucho mucho a DX y Stripe juntos. Eso tiene sentido. Stripe es una empresa de pasarela de pago casi exclusivamente para desarrolladores. Se toman en serio la tarea de brindar una buena experiencia a sus clientes (desarrolladores), de ahí la “experiencia de desarrollador”. Solo escuche a Suz Hinton hablar sobre “diarios de fricción”, que es la idea de sentarse a usar un producto (como Stripe) y anotar cada pequeño momento WTF, confusión y frustración para que se puedan realizar mejoras:
Netlify es como Stripe en este sentido, al igual que Heroku, CodePen y cualquier número de empresas en las que toda la base de clientes son desarrolladores. Para empresas como esta, es casi como si DX fuera lo que UX (experiencia de usuario) es para cualquier otra empresa.
La gente piensa en tecnologías específicas.
Es común escuchar la invocación de DX al comparar tecnologías. Por ejemplo, algunas personas dirán que Vue ofrece una mejor experiencia de desarrollador que React. (No estoy tratando de comenzar nada, ni siquiera tengo mucha opinión sobre esto). Están hablando de cosas como API. Quizás el Expresar es más intuitivo de administrar en uno que en el otro. O están hablando de funciones. Sé que Vue y Svelte tienen ayudantes de animación integrados, mientras que React no. Pero React tiene ganchos y, en general, a la gente le gustan. Estos son aspectos del DX de estas tecnologías.
O podrían estar hablando del sentimiento en torno a las herramientas que rodean la tecnología central. Sé que create-react-app es muy querido, pero también lo es Vue CLI. React Router es muy popular, pero Vue tiene un enrutador bendecido (y mantenido) por el equipo central que ofrece un cierto sentimiento de confianza.
> vue create hello-world> npx create-react-app my-appNo estoy usando marcos / bibliotecas de JavaScript como un ejemplo aleatorio. Escucho a la gente hablar sobre DX en lo que respecta a JavaScript más que cualquier otra cosa, lo que podría deberse a las personas en mis círculos, pero se siente notable.
La gente piensa en el mundo que rodea a la tecnología.
Todo el mundo piensa que los buenos médicos son importantes. No existe una tecnología que sea mejor que otra pero que tenga documentos mucho peores. El que tiene los mejores documentos es mejor en general porque tiene mejores documentos. Esa no es la tecnología en sí; ese es el mundo que lo rodea.
¿Alguna vez ha visto un producto de desarrollador con una API, y cuando ve los documentos de la API mientras está conectado, utiliza claves de API y datos y configuraciones de su propia cuenta para demostrarlo? Eso es extraordinario para mí. Eso se siente como DX para mí.
Documentos de Airtable que me muestran el uso de la API con mis propios datos.
“Facilite lo correcto” señala Jake Dohm.
Esa palabra, fácil, se siente muy relacionada con DX. Las tecnologías que facilitan las cosas son las tecnologías con buen DX. Tanto en el uso como en la comprensión. ¿Con qué facilidad (y con rapidez) ¿Puedo entender qué hace su tecnología y qué puedo hacer con ella?
Lo que hace la tecnología suele ser solo la mitad de la historia. El camino feliz puede ser genial, pero ¿qué sucede cuando se rompe o se equivoca? ¿Cómo es la notificación y el registro de errores? Pienso en Apollo y GraphQL aquí en mi propia experiencia. Es una gran tecnología, pero los informes de errores se sienten horribles porque es muy difícil rastrear incluso cosas como errores tipográficos que desencadenan errores en el desarrollo.
¿Cómo es la historia de depuración? ¿Existen herramientas especiales para ello? Lo mismo ocurre con las pruebas. Estas cosas son cuestiones fundamentales de DX.
La gente piensa en ofertas de tecnología.
Por ejemplo, una tecnología ya puede ser “buena”. Digamos que tiene una API que les gusta a los desarrolladores. Luego comienza a ofrecer una CLI. Eso es (generalmente) una mejora de DX, porque abre las puertas a los desarrolladores que prefieren trabajar en ese mundo y que construyen procesos a su alrededor.
Pienso en cosas como Netlify Dev aquí. Ya tienen esta gran plataforma y luego dicen, aquí, también puede ejecutarlo todo en su propia máquina. Eso es tomarse DX en serio.
Un aspecto de Netlify Dev que es bueno: el comando de terminal para iniciar mi entorno de desarrollo local en todos mis sitios en Netlify, independientemente de la tecnología que los impulse, es el mismo: netlify dev
Tener una CLI dedicada es casi siempre un buen paso de DX, asumiendo que está bien hecho y mantenido. Recuerdo WordPress antes de WP-CLI, y ahora mucha documentación asume que lo estás usando. Ni siquiera sabía que Cloudinary tenía una CLI hasta el otro día cuando la necesitaba y me sorprendió gratamente que estuviera allí. Recuerdo cuando los scripts de npm empezaron a apoderarse del mundo. (¿Qué sería de npm sin una CLI?) Solíamos tener una variedad de ejecutores de tareas diferentes, pero ahora se asume en gran medida que un proyecto ha ejecutado comandos integrados en el package.json que usa para hacer cualquier cosa que el proyecto necesite hacer.
Melanie Sumner piensa en CLI inmediatamente como core DX.
La gente piensa en la experiencia literal de codificar.
No hay nada más directamente DX que la experiencia de escribir código en un software de edición de código y ejecutarlo. Eso es “codificación” y eso es lo que hacen los desarrolladores. No es de extrañar que los desarrolladores se tomen esa experiencia en serio y estén constantemente tratando de mejorarla para ellos y sus equipos. Pienso en cosas como VS Code en la forma en que es esencialmente el DX lo que lo ha hecho tan dominante en el espacio de edición de código en tan poco tiempo. VS Code hace todo tipo de cosas que les gustan a los desarrolladores, las hace bien, las hace rápido y permite un grado muy amplio de personalización.
TypeScript sigue creciendo en popularidad, sin duda, en parte debido a la experiencia que ofrece dentro de VS Code. TypeScript literalmente te ayuda a codificar mejor mostrándote, por ejemplo, qué funciones necesitan como parámetros y dificultando hacer lo incorrecto.
Luego está la experiencia fuera del editor, que en el propio navegador. Hace años, escribí Style Injection is for Winners donde mi punto era, como desarrollador de CSS, la experiencia de guardar el código CSS y ver los cambios instantáneamente en el navegador es un DX que definitivamente querrás tener. Ese concepto sigue vivo, creciendo también a JavaScript, donde la “recarga en caliente” es digno de la piel de gallina.
La diferencia entre un entorno de desarrollador deficiente (sin ayuda de IDE, guardados lentos, actualizaciones manuales, pipelines lentos) y un gran entorno de desarrollador (asistencia de editor elegante, recarga en caliente, todo rápido) es sorprendente. Un buen entorno de desarrollo, un buen DX, te convierte en un programador mejor y más productivo.
La gente lo compara con la experiencia del usuario (UX).
Hay una fuerte connotación negativa a DX a veces. Sucede cuando la gente Cúlpalo para que exista a costa de la experiencia del usuario.
Pienso en cosas como bibliotecas solo para desarrolladores del lado del cliente. Piense en la biblioteca clásica que a todo el mundo le encanta mojar: Moment.js. Moment le permite manipular fechas en JavaScript y, a menudo, se usa en el lado del cliente para hacerlo. A los usuarios no les importa si tiene una API elegante disponible para manipular fechas. Eso es completamente una conveniencia para el desarrollador. Entonces, envías esta biblioteca por ti mismo (buen DX) a costa de ralentizar el sitio web (mala UX). La mayoría de los JavaScript del lado del cliente se encuentran en esta categoría.
Con la misma frecuencia, la gente conectar la experiencia del desarrollador y la experiencia del usuario. Si los desarrolladores están capacitados y son efectivos, eso se “filtrará” para producir un buen software, dice la teoría.
En el peor de los casos, estamos en una situación en la que UX y DX están en un tambaleo. Apila algunos problemas de DX y UX en el otro lado. En el mejor de los casos, encontramos formas de desenredar DX y UX por completo, encontrando valor en ambos y tomándolos en serio. Aunque si uno tiene que ganar, seguro que deben ser los usuarios. Como dice la especificación HTML:
En caso de conflicto, considere a los usuarios sobre los autores sobre los implementadores sobre los especificadores sobre la pureza teórica.
La gente piensa en el tiempo.
¿Cuánto tiempo se tarda en adoptar una tecnología? Good DX considera esto. ¿Puedo aprovecharlo sin reescribirlo todo? ¿Qué tan rápido puedo girarlo? ¿Qué tan bien juega con otras tecnologías que utilizo? ¿Cuál es mi inversión de tiempo?
Este tipo de cosas me hace pensar en una experiencia reciente con Cloudflare Workers. Es una tecnología realmente genial en la que no tenemos tiempo para analizar aquí, pero basta con decir que le brinda control sobre un sitio web a un alto nivel en el que a menudo no pensamos. ¿Qué pasaría si pudiera manipular una solicitud de red incluso antes de que llegue a su servidor web? No tiene que usarlo, pero debido al nivel en el que opera, se abren nuevas puertas sin preocuparse o interferir con cualquier tecnología que esté usando.
No solo la tecnología en sí misma se posiciona bien, el DX de usarla, si bien hay algunos aspectos ásperos, está al menos bien considerado, proporcionando un entorno de prueba basado en navegador.
Una herramienta poderosa con un alto costo de inversión, eh, eso es genial. Pero una herramienta poderosa con un bajo costo de inversión es un buen DX.
La gente no quiere pensar en eso.
Dicen que la mejor tipografía pasa desapercibida porque todo lo que ves es lo que te dicen las palabras, no la tipografía en sí. Eso puede ser cierto en la experiencia del desarrollador. El mejor DX es que nunca notas las herramientas o la tecnología porque simplemente funcionan.
Buen DX es simplemente poder Haz tu trabajo en lugar de luchar con herramientas. Las herramientas podrían ser su entorno de desarrollador, podrían ser herramientas de construcción, podrían ser elementos de alojamiento o incluso podrían ser las API con las que esté interactuando. Es la API intuitivo y útil, u obtuso y engañoso?
Siéntete libre de continuar con esto en los comentarios. ¿Qué es DX para ti?
- ¿Estamos capitalizando la experiencia del desarrollador? Solo voy a ir a por ello.
- Parece que Michael Mahemoff tiene un reclamo decente al acuñar el término.