Programar es, en su mayor parte, un proceso de pensamiento (2014)

• El resultado visible como código se parece más al resultado puro que queda al final de leer, investigar, depurar, verificar y decidir, que al trabajo completo de un día
• En una pregunta informal planteada a programadores durante varios años, la respuesta más común sobre cuánto tardarían en volver a teclear un cambio de 6 horas viendo solo el diff fue unos 30 minutos
• Esta proporción no proviene de un estudio científico, sino de encuestas y de observar diffs, pero sirve como una referencia práctica para ver la programación como 1/12 acción y 11/12 pensamiento
• El desarrollo de software se parece más a un trabajo de diseño que a una fabricación en serie, y después del diseño inicial la copia la hacen las máquinas con un costo marginal cercano a cero
• Si la gestión y los procesos se optimizan para aumentar el tiempo de tecleo, producen efectos desviados; son más importantes el entorno y la forma de colaborar que elevan la calidad del pensamiento

---

Cuánto tiempo toma volver a teclear 6 horas de trabajo

• La premisa es un buen día en el que, casi sin reuniones ni interrupciones, un programador hizo 6 horas de programación seria
• Antes de salir imprimió el diff, pero durante la noche el sistema de control de versiones se arruinó y se restauró desde el respaldo del día anterior, haciendo desaparecer el trabajo del día
• La esencia de la pregunta es cuánto tardaría ese programador en volver a introducir en la base de código esas 6 horas de trabajo teniendo el diff en la mano
• Durante varios años, esta pregunta se planteó en convenciones, en clientes, entre colegas y a programadores recién conocidos, y la respuesta más común fue unos 30 minutos
• Como en 6 horas caben 12 bloques de 30 minutos, esta observación lleva a la idea de que programar es 1/12 acción y 11/12 pensamiento

La naturaleza y los límites de la proporción

• Esta cifra no salió de una investigación científica rigurosa ni de una encuesta formal con buenos registros
• El objetivo no era encontrar una ley estadística o matemática de la actividad de programar, sino hallar una respuesta razonable a una pregunta razonable
• Como ninguna empresa quiso borrar de verdad todo el trabajo de un día para demostrar o refutar el experimento, la base quedó en estimaciones y observación diaria de diffs
• Tras revisar muchos changelogs y diffs, el volumen neto de cambios de un buen día parecía ser, por lo general, de 30 minutos ± 10 minutos

Teclear no es el cuello de botella

• La frase “teclear no es el cuello de botella” se ha repetido desde hace mucho en stickers y redes sociales
• Para algunos programadores teclear sí puede ser un cuello de botella, pero la clave para producir código rápido normalmente no es solo la velocidad al escribir ni el dominio de herramientas
• En una respuesta larga de Quora a “How do programmers code so quickly?”, una persona mencionó memoria muscular, dominio de herramientas, capacidad de depuración, habilidad para teclear y capacidad para buscar información
• Pero en la producción rápida de código, el tecleo y las herramientas se parecen más a medios auxiliares, y pesa más el tiempo dedicado a decidir qué hay que hacer

La diferencia entre una fábrica de software y un trabajo de diseño

• En la producción de productos físicos, la mayor parte del trabajo visible es movimiento: laminar acero, estampar, presionar, fresar, colocar y ensamblar se ve como trabajo
• Las fábricas modernas realizan movimientos precisos basados en modelos abstractos, es decir, datos, como hacen las máquinas CNC, y los humanos administran esas máquinas en vez de operarlas manualmente
• En el software, la fábrica ya está terminada, y el usuario obtiene una bit-perfect copy al pulsar el botón “copy” o “download”
• Una vez que existe el modelo inicial, el costo marginal de las copias posteriores es prácticamente cero, y el software es un bien intelectual
• Uncle Bob Martin ha dicho que el desarrollo de software no es trabajo de fabricación sino de diseño, y que, después del diseño inicial, las máquinas realizan la copia a costo casi cero
• Programadores, testers, PO, Scrum Masters y gerentes de software diseñan modelos de datos que sirven como base para las copias que usarán clientes y comunidades

El trabajo intelectual es difícil de observar

• La forma de pensar propia de la era industrial intenta ver el desarrollo de software como una fábrica, y se presiona a los desarrolladores para que parezca trabajo físico aunque eso perjudique el proceso real
• La actividad intelectual es difícil de observar y medir, y una idea completada al 80% no tiene forma física
• Puede haber experimentos, código de proof-of-concept o notas, pero no muestran un porcentaje de avance exacto como sí parece hacerlo el trabajo físico
• Una silla en fabricación parece estar aproximadamente 50% terminada cuando va por la mitad, y al completarse se ve como un producto terminado
• El diseño de una silla puede no existir en papel hasta que ya lleva más del 70% de avance, y antes de terminarlo ni siquiera es fácil saber si realmente está 70% completo

Por qué un cambio de 30 minutos puede representar 6 horas de trabajo

• Esos 30 minutos son el tiempo para reproducir el resultado puro del código que durante todo el día se escribió, se borró, se editó y se rehízo, no el esfuerzo total invertido
• Mientras escribe código, el programador evalúa continuamente y formula hipótesis para evitar defectos y vulnerabilidades de seguridad
• El texto del código solo contiene lo que el programa debe hacer al ejecutarse; normalmente no deja por qué se eligió ese enfoque, qué impacto tiene en otras partes del sistema ni qué errores se introdujeron y luego se eliminaron
• La mayor parte del trabajo real no está en el cambio mismo, sino en decidir cómo hacer el cambio; además, hay que entender el código existente, por lo que toma más tiempo cuando el código o el diseño son desordenados aunque eso no se vea en la fuente
• El resultado del programador se integra en una base de código compartida, así que tiene un contexto social, y ayudar a otros programadores, testers y operadores a entender el trabajo también genera costos y beneficios que no aparecen en el código

Las líneas de código no son una medida de avance

• Seis horas de trabajo intelectual pueden convertirse, tras leer, investigar, decidir, confirmar, verificar y revisar, en 30 minutos de cambio neto en la base de código
• Esto no significa líneas de código agregadas; a veces, incluso después de corregir bugs y añadir funciones, el total de líneas al final de la semana es menor que al principio
• Sin saber que la alta gerencia del equipo estaba reportando SLOC como si fuera una métrica de avance, hubo un problema por registrar durante varias semanas una cantidad negativa de líneas de código
• Lo que realmente hizo el programador se parece más a leer, aprender, entender, suponer, investigar, depurar, probar, compilar, ejecutar, formular hipótesis y refutarlas
• Gran parte del trabajo termina siendo, al final, pensar y decidir

Escribir menos puede ser desarrollar más rápido

• Una de las respuestas en Quora decía que se ve cómo se mueven los dedos sobre el teclado, pero no se ve el tiempo dedicado a hablar con usuarios, discutir problemas con colegas, investigar y pensar
• Otra respuesta decía que ayudar a los clientes a eliminar ideas innecesarias que llaman “requisitos” o “must have” es lo que más acelera la entrega de una solución
• Otra persona respondió que un gran desarrollador hace más del 90% del trabajo antes de tocar el teclado, entendiendo los requisitos e ideando una solución apropiada
• “Saber qué no escribir”, “hacer menos”, “trabajar en pasos más pequeños” y “descubrir primero qué hacer” fueron respuestas que aparecieron repetidamente
• Quien teclea más o copia y pega más puede tener menos reflexión y comprensión, y como resultado pueden aumentar los errores y la carga para que otros programadores entiendan y modifiquen el código

Los procesos deben diseñarse para el pensamiento

• Si programar es 1/12 acción y 11/12 pensamiento, no se debe presionar a la gente para que pase 11/12 de su tiempo tecleando
• Lo necesario son materiales, entorno y procesos que mejoren la calidad del pensamiento
• Hacer lo contrario lleva a optimizar el sistema para efectos equivocados
• La productividad puede aumentar cuando se construyen deliberadamente sistemas que faciliten pensar juntos sobre el software y tomar decisiones con mayor facilidad
• Hace falta experimentar con el aprendizaje dentro del trabajo y pensar cómo construir sistemas en los que el pensamiento quede optimizado

[GN⁺]

Opiniones en Hacker News

• La frase del artículo “un desarrollador realmente sobresaliente termina más del 90% del trabajo antes de tocar el teclado” a veces es cierta, pero creo que pasa por alto el hecho de que las personas no pueden mantener muchas restricciones y conceptos en la cabeza al mismo tiempo.
  El rango en el que uno puede pensar puramente, sin escribir nada, es muy limitado, así que cuando se me ocurre aunque sea un enfoque posible, suelo ir casi de inmediato al teclado antes de refinarlo hasta convertirlo en un diseño completamente especificado.
  Al escribir código real y probar varios enfoques, muchas veces la solución que al principio parecía la mejor resultó ser mucho peor que otra que parecía menos prometedora, y nada revela mejor un problema que código concreto que se ejecuta.
  Al final, programar es el proceso de materializar ideas en código para verificarlas, y, igual que en la visión de prototipado de descartar la primera iteración, escribir código también debe verse como parte del proceso de pensamiento.

  • Leí esa frase y pensé lo mismo; probablemente tenían en mente casos como Linus Torvalds.
    Algo así como la leyenda de que pensó en Git durante más o menos un mes, luego lo terminó en 6 días y descansó el séptimo; pero para la gente común, en especial en mi caso, se parece más a una interacción de pensar qué escribir, escribirlo, probarlo, volver a pensar y corregir algunas partes.
    Al final, el proceso de llegar a la versión final funcional se parece en cierta medida al arte.
  • Normalmente tiendo a iterar.
    Una vez que tengo una idea general, empiezo a escribir código por la parte “pegajosa” que parece tener más probabilidades de causar problemas.
    No puedo anticipar todos los problemas de antemano, así que tengo que toparme con ellos en la práctica, y este método muchas veces hace que termine descartando mucho trabajo.
    Casi no escribo documentación hasta estar seguro de que voy por buen camino[0], porque así puedo reducir el estado que llamo Concrete Galoshes[1].
    [0] https://littlegreenviper.com/miscellany/evolutionary-design-...
    [1] https://littlegreenviper.com/miscellany/concrete-galoshes/
  • Para diseñar una aplicación completa en la cabeza, hay que estar muy familiarizado con las trampas de la plataforma y las tecnologías que se usan.
    La única forma de aprender eso es con mucha programación práctica y aprendizaje activo, y también implica usar repetidamente el mismo stack tecnológico.
    Prefiero quedarme en el mismo stack y concentrarme en el problema en sí, pero el “gran desarrollador” del que se habla aquí probablemente sea bastante unidimensional en cuanto a la elección de herramientas.
  • Primero pienso a nivel macro y organizo las conexiones y la estructura con mapas mentales y diagramas.
    Cuanto más envejezco, más evidente se vuelve que la arquitectura es más importante que las decisiones micro.
    Lo micro se puede optimizar, pero las decisiones macro suelen ser permanentes.
  • Siempre pensé que esta era la razón para usar TDD.
    Muchas veces diseño el código dentro de las pruebas y dejo que guíen en cierta medida la implementación.
    Imagino el resultado final en mi cabeza, luego escribo pruebas con la forma que considero una buena API para el sistema y parto desde ahí.
    Como resultado, el código queda básicamente testeable, y tras dar varias vueltas por Red → Green → Refactor, llego a un estado satisfactorio.
    Me da curiosidad saber si otras personas también trabajan así.

• La explicación que más me gustó es la del libro “The Secret Life of Programs” de Jonathan E. Steinhart.
  Dice que la programación de computadoras tiene dos pasos: 1. entender el universo 2. explicárselo a un niño de tres años.
  La idea es que no puedes escribir un programa que haga algo que no entiendes; no puedes crear un corrector ortográfico si no conoces las reglas de ortografía, y es difícil hacer un buen videojuego de acción si no sabes física.
  Para ser un buen programador, hay que aprender todo lo posible sobre todo lo demás, y como las soluciones a los problemas suelen venir de lugares inesperados, no conviene descartar algo solo porque no parezca relevante de inmediato.
  El segundo paso consiste en explicarle lo que sabes a una máquina que ve el mundo de manera muy estricta, como un niño de tres años.
  Si le preguntas a un niño “¿dónde están tus zapatos?”, puede responder “allá”; respondió la pregunta, pero en realidad no infirió la intención de ponerse los zapatos para salir.
  Los niños crecen y aprenden flexibilidad y capacidad de inferencia, pero las computadoras, como Peter Pan, nunca crecen.

  • Me pregunto si hay más recomendaciones de libros parecidos.
  • Programar es en gran parte pensar, pero hay muchas formas de pensar.
    A cada persona y a cada problema le conviene una forma distinta de razonamiento, y aprender a pensar y programar de varias maneras aumenta las herramientas disponibles.
    Por eso no me gustan las afirmaciones de que la programación necesariamente debe ocurrir de una única forma correcta.
    Tampoco es cierto que “no puedas programar algo que no entiendes”; muchas veces se usa software para entender cómo funciona algo realmente.
    El modelado físico muchas veces tampoco busca una fidelidad total a la realidad, sino explorar un equilibrio entre la experiencia de usuario y la dificultad del juego.
    La programación puede ser una herramienta cognitiva exploratoria, y eso no significa que la mayor parte del pensamiento siempre deba venir primero.
    Me gustan los generalistas y autodidactas, pero no son un primer paso indispensable para ser buen programador.
    Más que tener una “visión estricta del mundo”, los niños no siempre infieren las implicaciones sociales, y las computadoras también pueden programarse para derivar conclusiones lógicas a partir de hechos conocidos.
    He explicado cosas a niños de varias edades, incluso a niños de tres años, pero esa experiencia no se pareció en absoluto a programar computadoras.

• Estoy bastante seguro de que esta cifra es básicamente correcta, pero hasta ahora ninguna empresa ha aceptado borrar un día entero de trabajo para intentar comprobar o refutar este experimento.
  Hace tiempo, cuando yo era mucho más paciente, tuve un jefe que revisaba todos los cambios de código cada noche y borraba lo que no le gustaba.
  Ese jefe creía que el control de versiones era excesivamente complicado, así que intentó imponer como estándar de la empresa conectarse de forma remota a una unidad de red en su casa.
  Por eso, a veces al llegar al día siguiente el trabajo del día anterior había desaparecido, y terminé volviéndome muy bueno en reconstruirlo hasta que instalamos SVN a escondidas.
  Rara vez tomaba más de una hora, incluso incluyendo pruebas de casos límite.

  • La muestra es pequeña, pero en mis 2 primeros trabajos de embebidos, en 2 de 2 se versionaba el código con carpetas compartidas de red y copiar/pegar.
    En mi primer trabajo quedé algo traumado, así que en el segundo pregunté de inmediato si había un repositorio Git; mi jefe respondió que no quería hacer público el código, pensando que Git era lo mismo que Github.
    Más tarde nos adquirió una empresa más grande y obtuve acceso a la intranet; allí encontré una instancia de GitLab, versioné y documenté ahí el código en el que trabajaba casi solo, e incluso instalé GitLab Runner.
    También documenté paso a paso cómo ejecutar el código, y cuando me despidieron y me pidieron entregar el código, les mostré todo y les expliqué cómo reproducirlo; mi jefe quedó bastante impresionado y me dio las gracias.
    Puede que, en un trabajo pésimo, al insistir en hacerlo de la forma que yo creía correcta, haya dejado al menos un pequeño impacto positivo.
    Antes de encontrar ese GitLab, había creado un repositorio Git bare en una carpeta compartida de red y hacía push ahí.
  • Nunca sabré si era un mal jefe o un maestro zen.
  • El problema más grande es que un gerente se meta en el código.
    Aunque sea con buenas intenciones, cuando un gerente se involucra en el código o en las revisiones, casi siempre es una pérdida neta para el equipo.
  • Cualquiera que haya usado en serio productos de Microsoft Office en los 2000 y 2010 sabe que esto es cierto, o terminó presionando guardar por reflejo cada 5 a 10 minutos.
  • Me da curiosidad si el trabajo rehecho por segunda vez quedó mejor o peor.

• Es un buen texto para enviarle a gente que no programa.
  Así como los programadores necesitan conocimiento del dominio, quienes quieren obtener algo de los programadores también deberían entender un poco de programación.
  Incluso un diff muy pequeño puede tomar horas por debugging, diseño y aprendizaje.
  Es fácil no impresionarse al ver solo la cantidad de resultado, pero que alguien te lo explique no es lo mismo que pasarte horas golpeándote la cabeza contra la pared para descubrirlo por tu cuenta.

  • Los fragmentos de código más pequeños que he entregado suelen ser los que más tiempo tomaron, los que tuvieron mayor impacto y los más satisfactorios una vez que se entienden.
    Es el tipo de cosa en la que pasas días encontrando un commit de una sola línea que mejora el rendimiento 100 veces, mientras en la reunión de sincronización tienes que explicar por qué el ticket no se mueve.

• Por eso el conocimiento del dominio es clave.
  He trabajado en finanzas, sentado en mesas de trading mirando varias bolsas y escribiendo código para implementar distintas estrategias.
  Si no sabes qué debe hacer el negocio, tampoco puedes pensar qué debe hacer la computadora.
  Desde esta perspectiva, puede tener sentido formar a los coders como traductores.
  Un amigo traductor conoce bien la gramática y los modismos de varios idiomas, y aprende idiomas nuevos como nosotros aprendemos nuevos lenguajes de programación, pero también dedicó bastante tiempo a aprender sobre la industria farmacéutica y ahora traduce documentos médicos.
  Los abogados y contadores también tienen profesiones con barreras de lenguaje.
  Al volverte experto aprendes el lenguaje del derecho, la contabilidad o el software, pero un buen profesional no responde en el lenguaje especializado, sino en el lenguaje del negocio.
  Un abogado menos bueno te enumera en jerga legal todos los resultados posibles y te deja la decisión; uno bueno te dice que, aunque haya muchas posibilidades menores, en la práctica los clientes en una situación similar hacen X por este objetivo de negocio.
  En mi primer trabajo de trading, un trader había creado un módulo de Excel VBA para ejecutar un proceso que revisaba instrumentos y encontraba candidatos para operar.
  No había control de versiones, solo un archivo guardado en disco; alguien nuevo llegó y en cuestión de semanas guardó el archivo después de borrar todo el módulo VBA, sin backups ni ayuda de IT.
  El trader se puso rojo, luego se calmó, aceptó la realidad de que de todos modos debería haber tenido backup y de qué estaba haciendo en VBA, se sentó y volvió a tipearlo todo, como una pantalla de terminal de los 80 mostrando los caracteres uno por uno.

  • Hay una gran diferencia entre desarrollar en un dominio que conoces bien y en uno nuevo.
    Mi convicción es que para crear una buena solución primero hay que tener experiencia en ese dominio.
    Ahora paso la mayor parte del tiempo adquiriendo experiencia en un dominio nuevo, sentado junto a expertos del dominio para acumular rápido el conocimiento necesario.
  • Por mi experiencia como ingeniero de software y CPA, a las empresas en general no les importa mucho ese conocimiento del dominio.
    Prefieren a un ingeniero de software que haya hecho software contable durante 15 años antes que a alguien con mi perfil, y optan por ponerlo a conversar 30 minutos con un contador.
  • La programación es un campo tan amplio que es muy difícil hacer generalizaciones que apliquen a todo.
    Se repiten prescripciones de que la programación necesariamente debe funcionar de cierta manera, pero el tipo de trabajo varía muchísimo entre subcampos.
    En vez de intentar aprender o enseñar una única metodología perfecta que aplique a todos los ámbitos, creo que es mejor tener una caja de herramientas con varios enfoques y metodologías, y entender en qué situaciones encaja bien cada uno.
  • Es cierto, pero en todas las empresas de mi país hay cláusulas de no competencia, así que aunque aprendas conocimiento del dominio, si tu empleador actual te despide no puedes llevarlo a tu siguiente trabajo.
    Por eso uno termina enfocándose en habilidades generales de programación transferibles entre industrias.

• Algo parecido aparece al principio del libro PPP de Bjarne[0]
  La idea es: “Incluso los mejores programadores, en especial los mejores, pasan la mayor parte del tiempo entendiendo el problema, no escribiendo código. Entender el problema suele requerir mucho tiempo serio y un esfuerzo intelectual considerable. Ese es precisamente el desafío intelectual al que muchos programadores se refieren cuando dicen que la programación es interesante”
  También compré la nueva edición[1], que hace poco estuvo en la portada[2]
  [0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
  [1]: https://www.stroustrup.com/programming.html
  [2]: https://news.ycombinator.com/item?id=40086779

  • En general es cierto, pero siento que el mayor problema es que pasamos tiempo repitiendo los mismos debates una y otra vez
    Cosas como qué base de datos usar, qué lenguaje es el mejor, si permitir null en el código y en la base de datos, el formato de las API, el formato de los logs, etc.
    No son temas especialmente interesantes y a veces hay que revisarlos, pero en las últimas tres empresas donde estuve, la mayor parte de ese consumo de tiempo se sentía como problemas que ya deberían estar resueltos
    De hecho, si una empresa tiene una mentalidad firme, incluso si es cuestionable, puede ser mucho más productiva
    Si se hubiera establecido que usábamos Perl, MongoDB y CGI, creo que habría sido más productivo que últimamente, a pesar de ese stack
  • La parte más difícil es averiguar qué no codificar, ya sea en la etapa de diseño antes de escribir, o después de aprender de un prototipo o de iteraciones anteriores
  • *Bjarne

• “Programar es principalmente pensar” es una de esas frases que uno se dice a sí mismo como si fuera una verdad profunda, pero como observación no es muy productiva
  Que programar sea pensar es cierto exactamente en el mismo sentido en que todo trabajo del conocimiento es pensar
  El diseño también es principalmente pensar, la contabilidad también es principalmente pensar, y la gestión también es en gran medida pensar
  La diferencia significativa no es pensar en sí, sino en qué se piensa
  Los gerentes tienen que depurar problemas de personas, así que necesitan mucho tiempo con personas, es decir, reuniones
  Los desarrolladores depuran problemas de computadoras, así que necesitan mucho tiempo con computadoras
  Ahí hay una tensión clara, y ninguno de los extremos funciona, así que hay que encontrar un equilibrio para estorbar menos el trabajo de los demás

  • Este artículo no está dirigido a programadores, sino a no programadores, como gerentes que creen que programar es principalmente teclear, y explica qué ocurre cuando no estamos tecleando
  • Un antiguo profesor de doctorado hablaba sin parar de cuánto tiempo se pierde al día quitando las manos del teclado si uno trabaja sin memorizar atajos y macros; esta es una observación mucho más productiva que aquella
  • Una diferencia importante en programación es que a menudo es mejor hacer lo mismo con menos código
    No me refiero a código críptico estilo code golf, sino al hecho de que hay que mantener todo lo que se produce
    Eso es claramente distinto de un novelista, a quien quizá no le interese mucho el mantenimiento y le importen más las emociones que produce el texto

• La mejor optimización para “crear un sistema donde el pensamiento se optimice experimentando con aprendizaje en el trabajo” es reducir las interrupciones
  Según la investigación, las interrupciones tienen un efecto destructivo en la programación
  Después de una interrupción, retomar el trabajo toma entre 10 y 15 minutos; es probable que un programador solo tenga una sesión de 2 horas sin interrupciones al día; y el peor momento para interrumpir es cuando está editando, buscando o entendiendo
  Me pregunto si habrá una forma de rastrear y mostrar estas interrupciones
  [0] http://blog.ninlabs.com/2013/01/programmer-interrupted/

  • Si le propones a un gerente dividir una reunión de 1 hora en bloques de 10 minutos repartidos a lo largo de 6 horas, verás una expresión realmente rara
    Pero se espera que los desarrolladores terminen tareas de programación de varias horas entre reuniones interminables y pequeños pings y sincronizaciones de Slack/Zoom
    A veces, cuando tuve que trabajar desde casa durante el fin de semana, vi que la calidad del trabajo de un fin de semana sin interrupciones era mucho mejor que la de un día laboral caótico
  • Por eso trabajo el 80% de noche
    No sirve para todos ni para todos los casos, y el 20% restante es coordinación con la gente que trabaja de día, pero la productividad que sale de buenas sesiones sin interrupciones de varias horas no tiene comparación
    De nuevo, no es una forma que funcione para todos, probablemente ni siquiera para la mayoría
  • Por la alta demanda de tiempo y las interrupciones, cuando trabajo desde casa soy aproximadamente varias veces más productivo, en un orden de magnitud de un dígito
    En casa nadie me interrumpe y, si llega una interrupción, puedo decidir cuándo responder
    En especial cuando estoy tratando un problema difícil, si me interrumpen cada 10 o 20 minutos, es mejor dejarlo; de lo contrario, es muy probable que termine creando código desastroso que después me dará dolor de cabeza
  • Una vez lideré en una gran empresa un proyecto para desarrollar una herramienta que rastreara cómo usa la gente su tiempo
    La diseñamos para respetar la privacidad: registraba que se había usado un navegador web, pero no URLs concretas como si era la intranet interna o fb.com
    De vez en cuando mostraba un pop-up para que el usuario evaluara su propia productividad y dejara comentarios en texto libre, y no lo vinculamos con el ID de usuario para que la gente no mintiera intentando parecer superhumana
    Construimos un frontend para Windows y un backend en Scala, y lo distribuimos a un grupo de voluntarios que incluía desarrolladores, abogados y gente de finanzas; pero justo cuando se ponía interesante tras el primer análisis de datos, se nos acabaron el tiempo y el presupuesto, así que no llegamos a publicarlo como artículo
    También vimos herramientas existentes como Rescue Time ( https://www.rescuetime.com/
    ), pero concluimos que no era aceptable almacenar datos internos de productividad en una nube externa

• La buena programación a veces es principalmente pensar, pero es cierto eso de que “ningún plan sobrevive al primer contacto con el enemigo”
  La programación práctica es una combinación cuidadosa entre planificar y poner el código a correr en el IDE, y ese equilibrio debe cambiar según el caso de uso

  • Programar no es simplemente pensar, sino sobre todo reconocimiento
    Si pasas días sin escribir código, o conoces por completo la superficie del problema, o simplemente estás haciendo conjeturas
    Si es lo segundo, no hay tanto sobre lo cual pensar
  • Probar la primera ejecución en el IDE es parecido a superar un nivel de un juego por primera vez
    La segunda vez será más rápida
    Estoy de acuerdo en que se puede ampliar el concepto de pensar a “pensamiento asistido por herramientas”

• Es una reformulación de Programming as Theory Building, de Peter Naur, y fue decisiva para que yo entendiera la esencia de la programación
  Programar no consiste en crear el programa en sí, sino en formar una perspectiva particular sobre algo del mundo; el código que se produce al final es apenas una simple expresión de la teoría que uno construyó