Por qué (y cómo) escribo código con lápiz y papel

Si la idea de escribir código a mano parece una tontería, puede que le sorprenda saber que es inevitable. Si no está seguro, piense en la última entrevista de trabajo que hizo y recuerde que no había ninguna computadora en la sala de entrevistas, solo sus entrevistadores, una hoja de papel en blanco y un bolígrafo azul.

Para los estudiantes entre ustedes, es aún más importante ya que sus calificaciones dependen de las líneas de código que había colocado estratégicamente en el espacio disponible en su hoja de respuestas.

Y no solo eso, los programadores experimentados pueden indicarle el paquete de hojas A4 que sacaron de la fotocopiadora de la oficina para escribir un algoritmo particularmente complejo en el que habían estado trabajando.

Entonces, ya sea que sea un estudiante de examen, un posible entrevistado de trabajo o alguien que quiera resolver sus callejones sin salida de programación, espero que este artículo lo ayude cuando ponga su pluma en el papel para codificar.

Aunque me centraré en el aspecto analógico de la escritura de código, puede aplicar estos pasos a la codificación en cualquier forma o idioma. Considere esto también como una guía de codificación genérica que funciona específicamente para mí, pero que también puede ser muy útil para usted en su trabajo.

¿Por qué escribirlo?

Antes de comenzar, es esencial comprender que nadie espera que anote el código listo para la producción en un cuaderno. No es como si pudiera colocar eso en un editor de código y compilarlo sin un error. Si el objetivo fuera producir un código perfecto, estaría sentado frente a una computadora en las salas de entrevistas y exámenes.

El propósito del código escrito a mano es trabajar a través de la lógica por adelantado. Existe el deseo de "entrar en el navegador" lo antes posible en el diseño, pero existe la sabiduría convencional en dibujar diseños a mano. Un medio de baja fidelidad fomenta la experimentación rápida y los errores económicos.

Lo mismo puede decirse del código, principalmente cuando se trabaja en la sintaxis y la semántica. Dicho esto, obtener la sintaxis y la semántica correctas es hacerlo un punto a favor, aunque no el único enfoque de todo el ejercicio de escritura a mano.

Veamos por dónde podemos empezar cuando se trata de escribir código a mano.

Conoce tu pregunta

Durante mi último año en la universidad, no pude hacer una pasantía ni siquiera asistir a entrevistas en el campus por motivos de salud. Como resultado, mi primera entrevista de trabajo fue bastante literal con mucho en juego.

Cuando miro hacia atrás ahora, la entrevista fue bastante fácil. Pero como nunca antes había asistido a uno, estaba ansioso más allá de lo razonable. Lo primero que preguntaron los entrevistadores sobre la programación fue si podía generar un triángulo invertido hecho de asteriscos. Como dije, fue fácil, nada for bucle no puede manejar, ¿verdad? Pero como dije, mi ansiedad también estaba por las nubes.

Respiré hondo, presioné la palma de mi mano contra la hoja de papel en blanco que me habían dejado, la deslicé lo más lento posible hacia mí sobre la mesa (ganando tiempo, por supuesto), chasqueé el bolígrafo y luego hice algo. Correcto.

Primero dibujé un triángulo invertido hecho de asteriscos. Fue así como puse los pies en el suelo para empezar a responder a su pregunta.

He visto a desarrolladores brillantes que se equivocan en algo simplemente porque nunca comprenden completamente qué es lo que están resolviendo.

Las preguntas con las que trabajamos no son como las que resuelven los físicos o los matemáticos. Obtienen un conjunto de parámetros y encuentran los que faltan; nuestras preguntas son también nuestros resultados. Ya se nos dice cuáles son nuestros resultados: tenemos que descubrir cómo alcanzarlos. Por eso es imprescindible conocer bien la pregunta porque verás el resultado.

Escribir o dibujar lo que desea generar es una de las mejores formas de comenzar a codificar. Entiendo que en nuestra industria acelerada, la expectativa es que tenemos que pasar directamente a la programación ejecutando una demostración de "hola mundo". Y eso es genial para familiarizarse con una sintaxis desconocida y quitarse la ansiedad de probar algo nuevo.

Pero cuando alguien te hace una pregunta y te da un resultado para trabajar, ¿no sería mejor dejar eso primero? Esa pregunta/resultado no es solo su punto de partida sino también su punto de referencia. En cualquier paso de su codificación, puede mirarlo para asegurarse de que está trabajando para lograrlo y que está en el camino correcto.

Entonces, ya sea en sus hojas de respuestas o en ese papel A4 en blanco que está a punto de escribir, comience tomándose un segundo y escribiendo lo que está tratando de generar. Puede ponerlo en los márgenes o en una esquina si no quiere que sea parte de su respuesta. Solo asegúrese de que esté en algún lugar donde pueda seguir haciendo referencia a él.

Delinea tu código

Este paso es como una espada de doble filo. Puede proporcionarle una hoja de ruta para su programa o hacerle perder el tiempo. Mi trabajo es asegurarme de que sea lo primero.

Así que, ante todo, me gusta decir: delinear el código es innecesario si el alcance de su problema o pregunta es pequeño. Una vez más, esta práctica no es prescriptiva ni universal para todos los proyectos o situaciones. Imagina que soy tu entrevistador y te pido que escribas cómo centrar un elemento en una página web usando CSS de tantas maneras como sea posible. No necesitarás exactamente un esquema para esto. Los fragmentos de código son relativamente pequeños para cada método.

Pero ahora, supongamos que le asigno que escriba una aplicación web que capture las firmas de los usuarios a través de una interfaz de pantalla táctil y luego guarde la firma en el servidor. No es tan sencillo, ¿verdad? Tienes más de una cosa que resolver. Tal vez, un pequeño esquema puede ayudar.

1. Interfaz de usuario para capturar la firma: ¿Lienzo HTML? ¿WebGL?
2. Deshabilitar eventos de puntero en el resto de la página web cuando el usuario está firmando
3. Convierta y guarde la imagen capturada en un archivo PNG: JS
4. Luego conviértalo en blob (tal vez) y guárdelo en la tabla de datos de registro del visitante.

He escrito una secuencia aproximada de acciones que creo que podría tener que codificar. Podría haber sido más corto o más largo, dependiendo de lo que quería de él.

Recomiendo encarecidamente delinear el código para los proyectos de los clientes. Escriba el esquema junto con los requisitos de usuario o en la parte posterior de los esquemas que haya impreso.

Su instantánea rápida de viñetas le brinda un mapa, una lista de tareas pendientes y una lista de verificación para verificar cuando llegue al final del proyecto, prácticamente el resumen de todo su proyecto en una lista de baja fidelidad. También puede convertirse en una plantilla para comenzar su próximo proyecto similar.

Pero como dije antes, este paso es como una espada de doble filo. Tendrá que ser breve para los examinados y entrevistados cuando haya limitaciones de tiempo.

Si no sabe por dónde empezar, escriba solo tres funciones esenciales que tendrá que codificar en su aplicación y, si tiene tiempo, que sean cinco.

Pero eso es todo. Dedica el menor tiempo posible a esto y no te preocupes por los detalles. El esquema no te dará puntos extra. Está allí solo para ayudarlo a asegurarse de que tiene todo cubierto. Captura su reacción visceral inicial y lo mantiene honesto a lo largo de la vida del proyecto.

Mano larga vs taquigrafía

Es hora de empezar a codificar. Entonces, ¿qué escribes? “Bdrs” o “border-radius"; "div -> p"O"<div><p></div></p>"; "pl()"O"println()"; "q()"O"querySelector()"?

Si alguien más está calificando su código, entonces no hay otra opción. Omita las abreviaturas, los pseudocódigos, los atajos de Emmet y cualquier otra forma de escritura abreviada. De lo contrario, no hay razón para suponer que cualquiera que lea esto sepa lo que significan sus abreviaturas.

Realmente depende de ti.

Si se ha perdido el contacto con la escritura a mano, y muchos de nosotros lo hemos hecho, es mejor no exagerar con las anotaciones a mano, ya que se vuelven tediosas. Al mismo tiempo, no existe tal cosa como ser demasiado frugal con tu escritura. No si quieres poder mirar hacia atrás algún día y entender lo que has escrito.

Tengo un archivo abierto en mi aplicación para tomar notas y un bloc de notas rayado en mi escritorio donde escribo fragmentos de código que quiero guardar para consultarlos más adelante. No están organizados, solo son un largo flujo de fragmentos. Es por eso que cuando hojeo notas antiguas, no sabría lo que quería escribir si no las hubiera escrito claramente.

Me olvido de sintaxis todo el tiempo. Por ejemplo, he estado usando la notación de flecha para las funciones de JavaScript desde que se introdujo (porque es más corta), y estoy bastante seguro de que si alguien me pide de repente que defina una función usando el function palabra clave, podría incluso perder los paréntesis o el nombre de la función, incitando a un error de sintaxis.

No es raro que olvidemos sintaxis que no hemos usado en mucho tiempo. Es por eso que es mejor escribir sus notas claramente cuando sepa que las necesita para futuras referencias.

El flujo de código no secuencial

A diferencia del último paso, que no se aplica a los entrevistados y examinados, este está especialmente diseñado para usted.

La mayoría de los lenguajes de programación se interpretan, compilan y ejecutan, de modo que, a veces, el código preescrito en el código fuente se ejecuta más tarde cuando se lo llama. Lo hacemos en JavaScript, por ejemplo, con llamadas a funciones: las funciones se pueden definir inicialmente y luego ejecutarse más tarde. Los examinados y entrevistados pueden usar esto para comenzar a trabajar primero en el punto crítico de su respuesta.

Como dije desde el principio, el propósito de escribir código a mano es trabajar o probar la lógica de lo que sea que programes. Es mejor cuando te enfocas en resolver eso primero.

Tomemos un ejemplo clásico de libro de texto: un programa para encontrar el enésimo Número de Fibonacci. Si tuviera que escribir un esquema simple para ello, sería algo como esto:

1. Obtenga la entrada.
2. Calcular el número de Fibonacci.
3. Resuma la salida.
4. Imprime la salida.

Todos los pasos de ese esquema son esenciales; sin embargo, 1, 3 y 4 son más obligatorios. Son necesarios pero no lo suficientemente importantes como para centrarse en ellos de inmediato.

Es mejor comenzar a escribir el código para calcular el número de Fibonacci en lugar de buscar la entrada. Envuélvalo en una función, luego continúe y escriba el código secuencialmente y escriba una línea para llamar a esa función cuando corresponda.

Dedique su tiempo a escribir código que se centre en el corazón del problema.

Los verdaderos profesionales pueden adelantarse. Digamos que tengo un proyecto de cliente y tengo que trabajar con geometría de triángulo: tengo dos lados, ángulos opuestos y tengo que encontrar la longitud del tercer lado. Y he decidido garabatear en un papel para empezar en lugar de abrir mi IDE.

Primero, dibujaría el triángulo, por supuesto (eso es algo con lo que tengo mucha experiencia, como puedes ver). Escribiría algunas longitudes y ángulos de muestra. Luego escribiría la fórmula (gracias a la búsqueda en línea, seguro), y luego saltaría directamente al código de la función.

No tiene sentido que escriba los pasos obligatorios aunque los necesite en código listo para producción. Pero sería diferente si tuviera que escribir eso en una hoja de respuestas en un examen. No puedo saltarme los otros pasos; sin embargo, aún puedo comenzar con el código de la fórmula.

Pseudocódigo

Chris ya ha escrito un artículo útil sobre pseudocódigo que le recomiendo encarecidamente que dé una lectura sólida.

Para todos aquellos profesionales que sienten que todo el código de escritura a mano no parece su taza de té, pero que aún pueden sentir curiosidad por si puede ayudarlos, entonces pseudocódigo podría ser el equilibrio que estás buscando.

Es similar a delinear el código, como mencioné en uno de los pasos anteriores. Sin embargo, es más breve y se siente más como una codificación abreviada. A veces también se le conoce como "código esqueleto".

Aquí hay un pseudocódigo rápido para un diseño de cuadrícula CSS:

Grid
5 60px rows
6 100px columns

¡No hay mucho que escribir! Entonces, aunque poner un lápiz sobre papel es excelente para este tipo de cosas, es igual de efectivo, rápido y económico anotar un pseudocódigo en cualquier programa que esté usando.

Espacio y comentarios

Creo que el código es 90% palabras clave y 10% pestañas. Sin espacios, la legibilidad de las palabras disminuye. Las sangrías también son necesarias para el código escrito a mano. Sin embargo, no lo use para todos los niveles porque el ancho del papel lo limitará. Usa los espacios con criterio, pero úsalos.

Si está escribiendo código para su uso, también creo que si ha seguido todo lo que he mencionado hasta ahora y ya ha escrito su salida y un esquema en la página, es posible que ni siquiera necesite incluir comentarios. Los comentarios le dicen rápidamente qué hace el siguiente conjunto de código. Si ya ha escrito y leído un esquema del código, los comentarios son notas redundantes.

Sin embargo, si su juicio dice que deje uno, entonces hágalo. Agréguelo al lado derecho del código (ya que no podrá insertarlo entre las líneas ya escritas de la forma en que podría, por ejemplo, VS Code). Use barras diagonales, corchetes o flechas para indicar que son comentarios.

Para los examinados que no se sientan seguros con cierta sintaxis, escriba los comentarios. De esta manera, al menos, le está haciendo saber a la persona que califica su trabajo su intención con ese código con formato incorrecto. Y use solo los delimitadores correctos para indicar comentarios; por ejemplo, serían las barras inclinadas para JavaScript.

Analógico vs. digital

Como mencioné anteriormente, todo lo que proporciono aquí puede ser un consejo de codificación genérico. Si no quieres probar esto con papel físico, cualquier aplicación para tomar notas también funciona.

Pero si vas a probar la ruta digital, mi recomendación es que intentes usar algo que no sea una aplicación para tomar notas. Trabaje con herramientas digitales más visuales: diagramas de flujo, mapas mentales, estructuras alámbricas, etc. Pueden ayudarlo a visualizar su resultado, los esquemas y el código en sí.

No soy un ciudadano digital (excepto por trabajar en la web y recientemente convertirme a la lectura de libros electrónicos), por lo que me limito a los cuadernos físicos.

Mis herramientas favoritas para escribir código a mano

¡Cualquier lápiz y papel servirán! Pero hay muchas opciones, y estas son algunas de las herramientas que uso:

No hay una forma de "escribir" para codificar

Espero, al menos, que mi pequeña forma de escribir código a mano con lápiz y papel te haga evaluar la forma en que ya planificas y escribes el código. Me gusta saber cómo abordan su trabajo otros desarrolladores, y esta es mi manera de darte una idea de cómo hago las cosas.

Nuevamente, nada aquí es científico o un arte exacto. Pero si desea probar la planificación del código escrito a mano, aquí está todo lo que hemos cubierto en una buena lista ordenada:

1. Comience escribiendo (con datos de muestra, si es necesario) la salida de su código.
2. Escribe un esquema para el código. Manténgalo en tres pasos para proyectos pequeños o menos complejos.
3. Usa notaciones manuales. Los desarrolladores que escriben para sí mismos pueden usar notaciones abreviadas siempre que la escritura sea legible y tenga sentido para usted cuando la consulte más adelante.
4. Cuando tenga limitaciones de tiempo, considere escribir primero el código que aborde el corazón del problema. Más tarde, anote una llamada a ese código en el lugar correcto de su código secuencial.
5. Si se siente seguro, intente escribir un pseudocódigo que aborde la idea principal.
6. Use sangrías y espacios adecuados, y tenga en cuenta el ancho del papel.

¡Eso es todo! Cuando esté listo para intentar escribir código a mano, espero que este artículo le facilite el comienzo. Y si está sentado para un examen o una entrevista, espero que esto lo ayude a concentrarse en responder correctamente las preguntas.