Programar humanos es más difícil que programar computadoras

 (erikbern.com)
1 puntos por GN⁺ 2024-09-28 | 1 comentarios | Compartir por WhatsApp
  • Las herramientas para desarrolladores son más difíciles porque deben diseñar no solo la lógica que ejecutará la computadora, sino también el modelo mental que otras personas entenderán y usarán
  • Un onboarding rápido no es una función adicional, sino casi el producto en sí; debe reducir la fricción de configuración, tokens de API y primera ejecución para que se pueda probar en una laptop en cuestión de minutos
  • Los usuarios aprenden patrones modificando ejemplos que funcionan, más que leyendo largas explicaciones de conceptos centrales; mientras más puntos de partida cercanos al problema haya, mayor será la probabilidad de éxito
  • Los mensajes de error, la cantidad de conceptos, los nombres, la forma de configuración, los valores predeterminados, la magia y el azúcar sintáctico cambian el camino del usuario hacia el éxito, por lo que se necesita un diseño legible y personalizable
  • Una buena experiencia para desarrolladores no consiste simplemente en reducir funciones, sino en disminuir en gran medida la complejidad que hay que conocer, manteniendo el alcance de lo que se puede construir

El código para humanos también aborda modelos mentales

  • El código para computadoras consiste en descomponer grandes objetivos de negocio en enunciados lógicos que una computadora pueda seguir
  • En el código que las personas manipulan directamente, como frameworks, bibliotecas, API, SDK, DSL, DSL embebidos y lenguajes de programación, no basta con que sea ejecutable
  • Este tipo de código da instrucciones a la computadora y, al mismo tiempo, debe ocuparse de cómo el usuario lo leerá y entenderá
  • Diseñar herramientas para desarrolladores requiere no solo ciencias de la computación, sino también una comprensión psicológica de cómo razonan los usuarios

La experiencia inicial es el producto

  • El feedback sobre herramientas para desarrolladores suele venir, en gran medida, de power users que usan el producto con frecuencia
  • Los usuarios que se traban al inicio no dejan feedback, lo que genera sesgo de supervivencia
  • Así como los productos de consumo optimizan el funnel de onboarding, las herramientas para desarrolladores también deben considerar el proceso hasta la primera ejecución como una parte central del producto
  • Para lograr un onboarding rápido, vale la pena cambiar la propia estructura del producto
    • Eliminar configuraciones obligatorias
    • Hacer que configurar tokens de API sea muy fácil
    • Reducir la fricción inicial
    • Permitir que el usuario pruebe el producto en su propia laptop en cuestión de minutos
  • En un entorno donde hay demasiadas herramientas para desarrolladores, es difícil que los usuarios tengan la energía o la paciencia para entender a fondo las diferencias de cierto paquete NPM de LRU cache

Los ejemplos enseñan más rápido que los conceptos centrales

  • A diferencia de las computadoras, que siguen órdenes estrictas, las personas son buenas para el reconocimiento de patrones
  • Muchas documentaciones de herramientas para desarrolladores empiezan explicando el modelo de datos central, relaciones, conceptos atómicos, configuración y forma de ejecución, pero las personas aprenden mejor modificando casos que funcionan y viendo los resultados
  • Varios ejemplos pueden ser más útiles que una explicación de “core concepts” de 5.000 palabras
    • El usuario aprende cómo se comporta la herramienta mirando ejemplos
    • Quien tiene un problema por resolver puede encontrar un punto de partida suficientemente cercano
    • Mientras más puntos de partida haya, mayor será la probabilidad de encontrar un ejemplo cercano a lo que necesita

Empujar a los usuarios hacia el pozo del éxito

  • El estado básico de la programación se parece a corregir continuamente algún tipo de error
  • Los usuarios pueden pasar la mayor parte del tiempo que usan una herramienta intentando entender “qué no funciona”
  • Si un desarrollador tiene éxito más rápido, le gustará la herramienta; si se queda bloqueado por errores una y otra vez, culpará a la herramienta
  • Cada error es una oportunidad para devolver al usuario al camino feliz
    • Incluir snippets de código en los mensajes de excepción
    • Mostrar advertencias útiles cuando exista la posibilidad de que el usuario haga algo extraño
    • Proporcionar las acciones necesarias para que el usuario tenga éxito

Reducir la sobrecarga conceptual

  • Cada nuevo concepto que hay que entender antes de usar una herramienta se convierte en un punto de fricción
  • Dos o tres conceptos pueden ser aceptables, pero no muchos usuarios quieren aprender ocho conceptos nuevos
  • Kubernetes no exige todos los conceptos al comenzar, pero mientras más conceptos nuevos aparecen, mayor se vuelve la carga
  • Hay una elegancia particular en un framework que es potente y aun así tiene solo de 3 a 5 conceptos
  • Al usar React por primera vez, después de superar la cuesta conceptual tras una o dos horas, puede dar la sensación de que se pueden construir grandes estructuras con unos pocos bloques simples
  • El objetivo no es simplemente reducir la cantidad de conceptos, sino reducir los conceptos que el usuario debe conocer manteniendo el alcance de lo que se puede construir
  • Una gran herramienta puede reducir la complejidad en 90% y mantener la misma capacidad
  • Una herramienta que reduce la complejidad en 90% y solo reduce la capacidad en 10% tampoco está nada mal

El principio conceptual del pato

  • Si dentro de un framework hay un elemento que recibe un valor y calcula un nuevo valor, es mejor llamarlo function que darle un nombre nuevo como “compute node”, “valuator” o “frobniscator”
  • El principio de que, si algo camina como pato y grazna como pato, probablemente sea un pato, también puede aplicarse al diseño conceptual
  • Aunque haya diferencias sutiles o el valor se cachee, si se parece lo suficiente a una function, se le puede llamar function
  • Usar términos existentes conecta con el modelo mental que el usuario ya tiene y reduce mucho la cantidad de explicación necesaria

Hacerlo programable

  • Los usuarios harán cosas inesperadas con una base de código, y pueden meter elementos del framework dentro de un for-loop, dentro de una función o dentro de otras estructuras
  • Por eso, casi todo en un framework debería ser programable
  • Las direcciones de diseño relacionadas están conectadas entre sí
    • Permitir que se llame directamente desde código, sin pasar por la CLI
    • Reducir los archivos de configuración y reemplazarlos por un SDK o una API
    • No permitir crear solo uno; parametrizarlo para poder crear n
  • Este diseño puede hacer que los usuarios descubran nuevos casos de uso
  • Aprovechar el deseo de “hackear” sobre un framework puede generar algo de confusión, pero también llevar a descubrimientos inesperados

La magia, los valores predeterminados y el azúcar sintáctico requieren cuidado

  • Supongamos que existe una función run_notebook que ejecuta un Jupyter notebook en la nube, y que el usuario debe especificar qué imagen de contenedor usar
  • Hay varias opciones posibles
    • Hacer que el argumento image=... sea siempre obligatorio
    • Tener una imagen predeterminada con la mayoría de las bibliotecas de ciencia de datos instaladas y permitir que el usuario la sobrescriba
    • Inspeccionar el código de las celdas y elegir una imagen de forma “mágica” según las dependencias necesarias
    • Además del enfoque mágico, permitir que el usuario también elija una imagen específica
  • Para reducir la cantidad de entrada y soportar el conjunto más amplio de casos de uso, la última opción puede parecer buena
  • Pero, salvo la primera opción, quedan problemas
    • La magia se rompe en algunas situaciones
    • Quien lee código que depende de valores predeterminados puede no darse cuenta de que se puede personalizar
  • Si el valor predeterminado no aplica en más del 97% de los casos y la magia no acierta en más del 99%, hay que tener mucho cuidado
  • Programar no es golf, y el trabajo de quien ofrece la herramienta no es solo minimizar la cantidad de código que escribe el usuario
  • Perl optimizaba mucho para código corto, pero los programas podían verse como una secuencia de caracteres especiales; Python, aunque el código fuera 50% más largo, era más legible y fácil de entender
  • Como las personas leen código 10 veces más de lo que lo escriben, la legibilidad importa
  • El azúcar sintáctico debe evaluarse con el mismo criterio
    • Puede ser tentador agregar sintaxis especial para casos de uso comunes
    • Pero puede diluir la consistencia y hacer menos evidente cómo personalizar
    • Si el azúcar sintáctico no aplica en más del 99% de los casos, quizá sea mejor no introducirlo

Principios de diseño para quienes lo usan por primera vez

  • Al escribir código para humanos quedan muchos más problemas de diseño
    • La mayoría debería ser inmutable, pero no todo
    • Evitar scaffolding, es decir, generación de código
    • Hacer que el ciclo de feedback sea muy rápido
    • Permitir que los usuarios respondan fácilmente a funciones que quedarán obsoletas
    • Usar pruebas automatizadas en los snippets de código de la documentación y los ejemplos
  • Diseñar la experiencia del primer usuario se parece a crear una canción pop
  • Aunque el productor haya escuchado la canción mil veces, al escucharla por 999ª vez debe imaginar cómo sonará para alguien que la oye por primera vez
  • En herramientas para desarrolladores, para quienes las construyeron repetidamente, imaginar la experiencia de un usuario primerizo es muy difícil

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-28
Opiniones de Hacker News

  • Cada persona aprende de forma distinta. Yo necesito primero los conceptos clave antes de pasar a los ejemplos. Más aún si esos conceptos clave no son extremadamente simples.
    Muchos tutoriales se parecen a armar LEGO de la mano de alguien. Algo como: “Aquí tienes piezas de LEGO; si sigues cómo armo un proyecto de juguete, para el final del día ya sabrás usar LEGO”.
    A mí ese enfoque no me funciona bien. Quiero saber cómo y por qué se toman las decisiones, y verlo desde la perspectiva del autor. Quiero entender qué sensación da cada pieza de LEGO, cómo se conectan entre sí y cómo se llega a un diseño determinado.
    Seguir un tutorial sin una explicación mínima de conceptos de alto nivel se siente como hacer ingeniería inversa de algo que no debería requerirlo. Cuando veo una biblioteca o framework nuevo, suelo leer la introducción y saltarme los ejemplos de código de “primeros pasos”. Normalmente hay más discusión conceptual en la sección “avanzada”, así que empiezo por ahí; luego voy a la referencia de la API para identificar las interfaces importantes y, al final, vuelvo a los ejemplos básicos de código del inicio del tutorial.

    • Antes pensaba que yo era una persona de “conceptos clave”, pero después me di cuenta de que lo había llevado demasiado lejos. Solía rechazar hacer cosas fuera de mi zona de confort antes de sentir que realmente lo entendía todo de antemano.
      Hoy en día muchas más veces simplemente me lanzo y trabajo directo con ejemplos, y siento que soy más productivo. En cierto modo es una cuestión de confianza: creer que las personas que crearon software de buena calidad pensaron lo suficiente como para hacer que sus interfaces fueran fáciles de entender para los casos de uso comunes, sin tener que escarbar demasiado en sus internals.
      Claro que a menudo me topo con obstáculos que obligan a profundizar más. Pero eso ocurre porque antes hubo otras 10 cosas que pude superar con éxito solo con una impresión superficial. Por eso, cuando realmente profundizo, por lo general no lo considero una pérdida de tiempo.
    • Totalmente de acuerdo. Cuando estaba empezando, odiaba los “generadores de proyectos” como create-react-app. Es solo un ejemplo, y me alegra haber aprendido React mucho antes de que existiera.
      Estas herramientas crean una estructura de carpetas específica, archivos de plantilla y herramientas preconfiguradas. Si no entiendes de inmediato, a alto nivel, qué hacen los archivos generados y por qué fueron creados así, se vuelve incómodo porque hay demasiada magia que no entiendes.
      Cada vez que aparece algo nuevo, necesito una introducción de alto nivel que explique su propósito conectándolo con conceptos que ya conozco. No me siento cómodo tratando con una caja negra mágica hasta entender, al menos de forma aproximada, la interfaz principal de esa caja negra. Por ejemplo, si aprendiera create-react-app desde cero, enseguida empezaría a investigar el propósito de las herramientas que configura, como Babel o ESLint.
    • Lo intenté de esa manera, y no sé cómo logré estudiar y aprobar ciencias de la computación así. Podía reproducir las soluciones, pero no las entendía.
      Solo años después, tras ver muchos buenos ejemplos prácticos, entendí de qué hablaban los conceptos. Después de darme cuenta de eso, afiné mi forma de aprender.
      Primero reviso los conceptos clave por encima; luego pruebo varios ejemplos hasta entender por qué esos conceptos son necesarios; después leo los conceptos clave con cuidado para eliminar los casos límite que faltaban en los ejemplos ingenuos.
    • A mí me pasa algo parecido. También tuve este problema cuando intentaba entender por qué Maven no funcionaba. No necesitaba un tutorial de “cómo empezar”, sino principios básicos que me permitieran entender qué estaba pasando.
      Dicho eso, creo que empezar con ejemplos puede ayudar a diseñar buenas API. Si diseñas una API con un enfoque de “conceptos clave primero”, es fácil que termine siendo una API que solo se puede usar después de entender esos conceptos clave, lo cual no es bueno para usuarios que la usan solo de vez en cuando.
    • Bien resumido. En especial, empecé a sospechar con la frase “los humanos no aprenden así”.
      Muy al estilo hacker, no había citas. He visto apenas un poco de pedagogía, pero es un campo enorme y maduro que extrae principios modernos de la psicología experiencial de Dewey y Piaget. Hay mucho más que decir de lo que podría cubrir una sola publicación de blog, ni hablar de una sección de una publicación de blog.
      El mayor problema, como se señaló, es que cada persona es diferente. El siguiente gran problema es que ni siquiera sabemos con certeza por qué surgen esas diferencias ni qué tan estables son con el tiempo. El texto en sí está bien escrito y profundiza bien en la utilidad práctica de una estrategia educativa específica, pero me habría gustado un poco más de humildad.

  • Hace menos de dos semanas hubo un texto parecido: https://news.ycombinator.com/item?id=41566097
    Escribir para personas, al final, se reduce a dos habilidades: empatía y escritura.
    Hay una gran diferencia entre escribir un poco de código y escribir una aplicación o un producto. Este texto también habla de eso al final, solo que de forma menos obvia. La empatía es importante porque marca la diferencia entre el egocentrismo y la orientación hacia el exterior.
    Un desarrollador egocéntrico se interesa principalmente por la facilidad, la comodidad, la vanidad del código y otros criterios subjetivos. Al final solo considera su propio esfuerzo de comunicación. Un desarrollador orientado hacia el exterior se interesa principalmente por la arquitectura y la documentación, porque entiende que el éxito depende de cómo otras personas reciban su trabajo.
    La simplicidad es más importante que la facilidad. Porque un desarrollador orientado hacia el exterior no puede leer la mente de los demás ni saber qué les parecerá fácil, pero sí sabe cómo reducir la cantidad de pasos y mantener el código pequeño.
    Desde la perspectiva del producto completo, escribir una aplicación no es distinto, dentro del cerebro, de escribir un ensayo, un artículo o un libro. Lo central son la organización y la funcionalidad. El código viene después y es como las palabras sobre la página. Quien solo escribe fragmentos de código no desarrolla la habilidad de organización de alto nivel que une todo.
    Por eso detesto tanto los frameworks. Los frameworks les quitan a los desarrolladores la práctica que necesitan para escribir software original y, como resultado, les impiden desarrollar habilidades de organización. Quien está en esa situación no puede verlo, pero para quienes sí pueden verlo es una brecha enorme y clarísima.

    • Es cierto, y también es un dilema. Quienes crean frameworks lo hacen para que otras personas puedan lanzar productos más fácilmente. En el proceso de crear un framework, ellos mismos se vuelven mejores desarrolladores.
      Pero los demás ahora tienen que aprender sus abstracciones, y eso los aleja en la misma medida de los conceptos de base. Entonces puede volverse más difícil adquirir las habilidades esenciales necesarias para ir más allá del framework. Así me sentí al aprender Rails, y al final, cuando me di cuenta de que ocultaba demasiadas cosas, lo abandoné y empecé desde cero.
    • Soy bastante bueno escribiendo fragmentos de código, pero cuando una aplicación se vuelve lo suficientemente compleja, tiendo a atacar el problema reescribiéndolo en círculos. Cuando la complejidad crece, a veces caigo en un bucle infinito de reescritura.
      Darme cuenta de que esto es una habilidad completamente distinta me abrió los ojos. Por decirlo así, ahora se convirtió en un desconocido conocido.
    • La empatía está bien, pero hay que entender la cognición. Si no, la empatía termina usándose en el lugar equivocado.
      ¿Cómo se verá este código para alguien cuyo jefe le está respirando en la nuca, o para quien está arreglando un problema de producción a las 2 de la mañana? No sabes cuánto vale realmente esa respuesta hasta que la necesitas. Y en el momento en que la necesitas, terminas pagando mucho por ella. Si es que puedes encontrar a alguien capaz de hacer eso. Esa gente es escasa.

  • No estoy de acuerdo con la frase “los seres humanos aprenden a partir de ejemplos, no de conceptos centrales”. Puede que sea buscarle la quinta pata al gato, pero no todos los seres humanos funcionan así.
    Las personas que prefieren ir de lo general a lo concreto ya suelen ser ignoradas en la educación primaria y secundaria, y recién en la educación superior puede empezar a encajarles mejor. Ya están suficientemente marginadas, así que no hace falta negarles hasta su existencia.

    • Hace poco aprendí a manejar con transmisión manual mientras viajaba con mi novia y su padre. Mi novia solo me decía acciones: cuándo pisar el embrague y cuándo soltarlo, y no me ayudó en absoluto.
      No entendía los matices de cuándo hacer qué, qué cosas había que hacer completamente al mismo tiempo y cuáles debían venir inmediatamente después. Entonces el padre de mi novia me explicó brevemente qué hace realmente el embrague y cómo la conexión entre las ruedas y el motor afecta a ambos lados.
      En ese momento lo entendí de inmediato y ya no necesité que me indicaran qué hacer en cada situación específica. Unos 20 minutos después ya podía arrancar con freno de mano en una pendiente inclinada hacia atrás, que dicen que es de lo más difícil con transmisión manual. Para algunas personas, entender cómo funciona algo desde primeros principios es mucho más útil, y creo que entre los ingenieros de software hay bastantes de esas “algunas personas”.
    • Yo necesito ambas cosas. Para mí, el aprendizaje real consiste en aprender los conceptos centrales, pero los ejemplos son casos con respuesta conocida que me permiten verificar esa comprensión.
      Si hay algo sorprendente en un ejemplo, significa que mi modelo todavía no está completo. O que el ejemplo está mal.
    • Quizás soy más lento que el técnico promedio, pero necesito ambas cosas. Gran parte de lo frustrante de mi trabajo actual es que, como es una empresa grande, cada vez que aparece una tarea nueva solo te dan ejemplos de cómo lo hizo la persona anterior.
      En vez de “esto es lo que intentamos lograr, esto funciona así y nosotros lo hacemos de esta manera”, lo que se expone siempre al trabajador es solo “nosotros lo hacemos de esta manera”. Con apenas una pequeña variación, ya no puedes razonar, ajustar ni resolver el problema.
      Para tareas que se hacen con frecuencia hay algo de documentación, pero normalmente está desactualizada o incompleta. No es una wiki, así que cualquiera no puede corregirla en cualquier momento, y para arreglar la documentación hay que pasar por un proceso molesto, por lo que al final no se actualiza. Ahora que lo pienso, se parece bastante a cuando estaba en el ejército.
    • También estoy de acuerdo. Mi forma de aprender, en sentido figurado, es leer un manual de referencia de principio a fin. Muchas veces, la mayoría de los materiales introductorios recomendados cuando intento aprender algo nuevo resultan ser exactamente lo contrario de lo que estaba buscando.
      Todavía me está pasando mientras trato de dedicar tiempo a aprender Drizzle ORM. Los primeros materiales que encontré eran todos “seis ejemplos de consultas”, y me frustraba no saber por qué se usa esa sintaxis ni cuáles son las otras opciones. Cierro ese tipo de material, leo todas las páginas de la documentación y luego hago algo; ese enfoque me resulta mucho más cómodo.
    • En la escuela me empezó a ir bien recién después de comenzar a practicar la construcción de teoría en mi cabeza. Es decir, formular hipótesis, probarlas y refinarlas.
      No sé si hoy podría hacerlo en tiempo real. Este método consume bastantes ciclos de pensamiento, así que ahora me va mejor leyendo texto o pausando videos para procesarlos.
      A menudo terminé enseñando sobre la marcha a personas que todavía no entendían. Si tienes una teoría del sistema, puedes responder preguntas que un compañero que apenas pasó de la memorización mecánica no podría responder.

  • Es una frase de Code Complete: “Una pequeña parte del trabajo de programación consiste en escribir programas para que una computadora pueda leerlos, y una parte mucho más grande consiste en escribirlos para que otros humanos puedan leerlos”. p. 733
    La tengo presente desde hace casi 20 años

    • “Los programas están hechos para que los lean los humanos, y que las computadoras los ejecuten es solo algo incidental”.
      Aparece en el prólogo de la primera edición de Structure and Interpretation of Computer Programs, de Abelson y Sussman, y precede a Code Complete por 10 años
      Es una máxima que intento seguir, aunque curiosamente los empleadores parecen insistir siempre en la parte de que las computadoras lo ejecuten
    • Abelson, uno de los autores de SICP, dijo algo similar. La idea es que el código debe escribirse para que los humanos lo entiendan, y que las computadoras lo entiendan debería venir al final

  • Es un poco tangencial, pero hace unos días, mientras hacía un juego en Unity, me puse a pensar que quizá los IDE no han avanzado mucho en los últimos 10 o 20 años.
    El IntelliSense básico sin duda ha mejorado mucho, pero salvo algunos detalles menores, el concepto completo de programar parece casi igual que antes.
    El mayor cambio positivo está fuera del editor. Es mucho más fácil acceder a bibliotecas y documentación, hay una cantidad enorme de preguntas y respuestas de usuarios, y también aparecieron herramientas nuevas como ChatGPT que de vez en cuando reúnen esas respuestas y dan una respuesta plausible.
    Pero, en general, la acción de escribir código parece estancada. Por eso ahora pausé un poco el trabajo en el juego y estoy haciendo algunos experimentos. No quiero crear un lenguaje nuevo; quiero delegarle a la computadora todo el trabajo tedioso posible para concentrarme en la creación.
    Las tres cosas que quiero probar primero son estas. Por qué tengo que preocuparme por pequeños detalles del lenguaje como paréntesis o terminadores; ¿no podría la herramienta autocompletarlos? ¿No podría la herramienta determinar automáticamente el conjunto más eficiente de modificadores, como cadenas de acceso private-public o unsafe? Cuando estoy concentrado en unos cinco métodos que interactúan entre sí, quiero verlos todos en una sola pantalla sin abrir varias ventanas ni pelearme con los deslizadores horizontales/verticales de VS. Si creé un HashSet y luego debería cambiarlo a Dictionary o Tuple, quisiera que simplemente lo cambiara y me mostrara solo los lugares donde hace falta criterio para aprobarlos o corregirlos manualmente. En Unity, también me gustaría poder hacer clic en un método o conjunto de datos y ordenarle que lo convierta en un Burst Job y su conjunto asociado de NativeData.

    • Que el concepto completo de programar sea casi igual que antes se debe a que el concepto completo de los lenguajes de programación no ha cambiado demasiado. Hay dos grandes pilares, la máquina de Turing y el cálculo lambda, y después vienen las abstracciones. Si una abstracción es buena, la llamamos paradigma.
      Pero al final todo son abstracciones, y lo único que hacemos es escribir órdenes para que una máquina muy tonta calcule datos.
      Dices que la herramienta podría autocompletar paréntesis o terminadores, pero la computadora es realmente simple y el lenguaje de programación es el canal para transmitir las ideas que tenemos en la mente. Esos delimitadores son tan importantes como las palabras clave del lenguaje, porque forman parte de las reglas. Para autocompletarlos harían falta más reglas y más delimitadores.
      Si quieres ver en una sola pantalla varios métodos que interactúan, existen Vim y Emacs, o IDE de Smalltalk como Pharo.
      Las transformaciones de datos se pueden hacer con macros de Vim y Emacs. Pero la verdad es que la codificación de datos es muy importante. Para la computadora todo son bits, y nosotros les damos significado a esos bits y creamos reglas para manipularlos según ese significado. Para cambiar la forma de un conjunto de reglas a otro, hacen falta más reglas.
      Te recomiendo probar un entorno de programación en vivo. Cosas como SLIME de Common Lisp, Pharo de Smalltalk o el inspector web de JavaScript. Es la sensación de trabajar en un barco en medio del mar, en lugar de poner un barco en tierra e imaginar cómo se sentiría navegar.
    • Creo que la razón por la que la experiencia con los editores de texto no ha mejorado mucho es que rara vez ese es el cuello de botella.
      La parte más difícil de programar es pensar y aprender. Teclear más rápido no ayuda demasiado.
    • Estoy de acuerdo con lo del autocompletado. Ya hace al menos 35 años, el editor Brief para MS-DOS permitía definir plantillas arbitrarias y autocompletarlas.
      Por ejemplo, al escribir un programa en C, podías hacer que “f” se expandiera a “for (=; <=; ++) {;}” o al estilo de indentación que prefirieras.
      Muchos editores de programación modernos admiten configuraciones de usuario similares, pero lamentablemente en muchos casos el proceso es más complejo que hace muchísimo tiempo.
      Si se trata de un lenguaje de programación con una sintaxis verbosa, creo que vale la pena dedicar tiempo a definir plantillas en el editor para poder escribir rápidamente cualquier estructura de programa con el mínimo de teclas.
    • Cosas como paréntesis o terminadores hacen explícita la sintaxis y mejoran mucho el soporte de herramientas. Normalmente los editores tienen funciones para insertarlos. Pero en algunos casos, aunque para mí parezca obvio, en realidad es una de varias opciones válidas, y sin algo como un documento de diseño la herramienta no puede leerme la mente.
      Cuestiones como si usar HashSet, Dictionary o Tuple tienen impacto en el rendimiento, y en abstracto no siempre está claro cuál debería usarse. En lenguajes explícitos como Java, y probablemente también C#, se podría refactorizar para que las llamadas a métodos reciban otro tipo. Entonces cambias un método y refactorizas todas sus llamadas.
      Experimenté con Gemini Pro y ChatGPT o1, y ambos son realmente malos programando en Python y JavaScript. Escriben código con bugs y, al intentar corregir un bug, con frecuencia introducen otro. En ambos casos da la impresión de que se apresuran a responder en lugar de pensar en los requisitos. Creo que todavía estamos algo lejos de herramientas que “lean la mente” o entiendan qué es importante y qué no de la forma que queremos.
      Algo que podría ser aún peor son los datos de entrenamiento. Como la mayoría del código lo producen programadores por debajo del promedio y de nivel promedio, estas herramientas terminan adoptando los patrones de pensamiento de un programador promedio. Incluso si se entrenaran solo con código de la máxima calidad, no está claro que la mayoría de los programadores pudiera darles prompts correctamente. Así que si llevas 10 o 20 años programando, es bastante probable que siempre te decepcione un poco una herramienta si esperas magia instantánea.
      Aun así, las herramientas de análisis estático no basadas en IA han sido excelentes desde hace mucho y seguirán mejorando. Si se les suma IA, pueden mejorar aún más. Creo que se puede tener una gran experiencia si pensamos en las herramientas no como artistas a quienes les lanzamos una especificación para recibir un resultado decente, sino como algo que me ayuda a ser el artista.
      También podría ser divertido experimentar diciéndole a una IA qué quisieras que hiciera más tu editor y pidiéndole ayuda para configurarlo. Hay muchas herramientas no basadas en IA en forma de plugins. Usar un modelo de lenguaje grande para elegir plugins que se ajusten a tu estilo de vida puede ser lo más eficiente.
    • Si te interesa ver en una sola pantalla unos cinco métodos que interactúan mientras editas partes de varios archivos, haystack podría ser interesante.
      https://haystackeditor.com/
      No lo he usado personalmente, pero pienso probarlo.

  • El título del artículo es discutible. El código se escribe únicamente para los humanos. La computadora no necesita “código”, y en especial no necesita código de alto nivel. A la computadora le bastan las instrucciones en lenguaje máquina.
    Escribimos código porque las instrucciones en lenguaje máquina son demasiado difíciles de escribir para las personas, y aún más difíciles de leer.
    No hay que pensar en el código como una forma de interactuar con la computadora. El código es una forma en que los humanos formalizan sus ideas para hacerlas tan libres de ambigüedad que incluso una máquina pueda seguirlas.

  • Promociono de forma altruista una entrada de blog que escribí y compartí la semana pasada
    Move Fast & Document Things [1]
    No intentaba escribir un texto filosófico, sino compartir consejos prácticos sobre cómo nuestro pequeño equipo [2] impone una cultura de escritura de código para nosotros mismos y entre nosotros, no mediante automatización o IA, sino a través de revisiones profundas y difíciles
    Amigos personales que son líderes de ingeniería en otras organizaciones me dijeron todos: “nosotros hacemos lo mismo, pero tú sí lo pusiste por escrito”. Si les pareció valioso, les agradecería una recomendación
    [1] https://olshansky.substack.com/p/move-fast-and-document-thin...
    [2] https://github.com/pokt-network/poktroll/graphs/contributors

  • “Demasiados libros y tutoriales de programación van en plan ‘construyamos una casa desde cero, ladrillo por ladrillo’, cuando lo que yo quiero es ‘aquí hay una casa que funciona; cambiemos algo y veamos qué pasa’”
    Yo aprendí programación por mi cuenta de esa manera. Pasé años usando bien programas pequeños, simples y medio malos
    Más adelante descubrí que no era apto para mejores trabajos de desarrollo de software, porque no tenía ningún conocimiento básico de diseño de software, lenguajes de programación ni computadoras. Como no aprendí de la forma aburrida, salir de entrevistas dándome cuenta de cuánto no sabía fue una experiencia que me hizo bajar la cabeza
    Siempre hay que leer la documentación completa y siempre hay que aprender los fundamentos

  • Todo mi código lo escribo para humanos
    Ya sea para mí en el futuro o para alguna pobre persona que, años después, tenga que descifrar mis intenciones
    No creo que escribir código en sí sea difícil. Lo que demuestra talento es razonar un problema de forma integral, colaborar con otras partes interesadas para descubrir el mejor camino y guiarlas, aprender habilidades especializadas como nuevas matemáticas o prácticas de la industria, idear algoritmos eficientes y comunicar la estructura y los patrones del programa para que tengan límites claros y elegantes
    Al final, gran parte de todo depende de la comunicación y la claridad

  • Gran parte de este artículo trata sobre documentación, y habría sido de mucha ayuda que hiciera referencia al modelo 4doc: https://docs.divio.com/documentation-system/
    Básicamente, significa no ofrecer solo documentación de referencia, sino también documentación de uso. Y ponerla al frente, porque normalmente es la parte de toda la documentación que los usuarios quieren ver primero
    Claro, eso es en general; yo suelo ir directo al material de referencia, pero no siempre
    No significa que 4doc sea una solución mágica ni una ley natural. Hillel Wayne también aborda bien sus problemas aquí: https://www.hillelwayne.com/post/problems-with-the-4doc-mode...