4 consejos para codificar mientras superamos nuestros propios defectos psicológicos

Dada la posibilidad de elegir entre un pedazo de pastel en este momento o un pastel entero dentro de un mes, probablemente elegiríamos el primero. Este sesgo psicológico se conoce como "preferencia de tiempo" o "descuento por retraso".

Todos hemos visto este excelente ejemplo de niños que intentan aguantar sin comer un malvavisco, con la esperanza de obtener una recompensa mayor:

Al escribir código, a menudo nos enfrentamos al mismo problema, teniendo que elegir entre las ventajas a corto plazo de las malas prácticas y los costes a largo plazo que genera.

Ver también: IoT y codificación:¿cuáles son los lenguajes de programación más populares?

Para ayudar a superar los atracones de malvaviscos ineficientes, aquí hay 4 ejemplos de cuándo y cómo podemos vencer nuestro sesgo para ganar a largo plazo.

1. Escriba la prueba unitaria, para su propio beneficio

Todos lo hemos leído, aprendido y oído hablar. Las pruebas son un buen ejemplo de algo que sé que debería hacer para obtener un beneficio a largo plazo, pero se interpone en mi camino cuando trato de hacer el trabajo en este momento.

Aquí hay algunas ideas que pueden ayudar a equilibrar esta ecuación:

• Las pruebas aseguran que nada se rompa cuando cambias cosas . Eso significa que puede realizar cambios en su código y saber en el acto si todo funciona. Esto le permite trabajar con mayor libertad, incluso ahora mismo.
• Las pruebas ayudan a decidir cuándo algo es "suficientemente bueno". Las pruebas definen lo que significa que un fragmento de código "funcione". De hecho, esto puede permitirle gastar menos tiempo optimizando cosas que realmente no necesita optimizar.
• Las pruebas ayudan a escribir código reutilizable . Puede componer cosas más grandes a partir de piezas modulares más pequeñas. Lentamente, está construyendo un impresionante arsenal de bloques de construcción reutilizables listos para ser utilizados a su disposición.

Además, siéntete orgulloso de las pruebas que escribes. Vea todos los indicadores verdes que cuelgan sobre su código. Sepa que su práctica y ética son excelentes. No hay vergüenza en eso.

2. Haga que el código sea reutilizable mientras trabaja

Escribir código reutilizable tiene muchas ventajas a largo plazo, así como algunas inmediatas. Siempre que sea posible, diseñe su código para ser reutilizado. Luego, publíquelo / expórtelo al código abierto.

No tiene que pasar horas publicando paquetes. En su lugar, puede exportar estos pequeños componentes a Bit. Aquí hay una publicación de blog de Ran Mizrahi que explica por qué y cómo puede exportar componentes pequeños en segundos.

Muy rápidamente puede crear un arsenal de componentes React o Angular reutilizables o un buen Alcance de funciones de utilidad.

El esfuerzo es bajo y la vista web del Centro de la comunidad de Bit otorga una vista rápida de los documentos, pruebas, descargas y más de su componente, lo que brinda una satisfacción inmediata con su trabajo ahora disponible para el mundo. También puede compartirlo con su equipo o la comunidad.

3. No copie y pegue. Simplemente no lo hagas.

Un ejemplo clásico. Copiar y pegar hace que el trabajo se haga mucho más rápido en este momento, pero las duplicaciones hacen que nuestro código base sea más difícil de mantener mañana creando una deuda tecnológica cada vez mayor.

Cada pequeño cambio tendrá que realizarse en varios lugares y, a menudo, los problemas solo se encontrarán al pasar a producción.

¿Qué podemos hacer? bueno, ¡no copie y pegue el código! Simplemente no lo hagas. En su lugar, busque / cree / comparta componentes reutilizables. Sindre Sorhus lanzó más de 1.000 paquetes diminutos. Los paquetes son difíciles y 1000 es mucho.

Podemos usar Bit para facilitar este proceso (exportar componentes en segundos) y establecer una meta alcanzable como hacer 100 componentes reutilizables. Descubrirá que 100 o más podrían ser suficientes para reducir drásticamente la cantidad de duplicaciones, y muy pronto verá que la reutilización es mucho más rápida que la duplicación.

4. Documente su código, cuente una historia

Una buena documentación significa que si mañana me devoran los coyotes salvajes, alguien más podrá reemplazarme. Importante sin duda, pero no es mi principal preocupación en este momento. Prefiero hacer el trabajo que preocuparme por el "futuro yo" o por aquellos que me seguirán. Me preocuparé por ellos más tarde si llego a tiempo. Este tipo de priorización (muy humana) conduce a lagunas y descuidos en la documentación.

Sin embargo, hay otro punto de vista que puedo adoptar para asegurarme de no descuidar mi documentación.

Tanto el código en sí como su documentación son representaciones de la historia lógica que estoy contando. Al escribir lo que hacen todas y cada una de las partes de mi código, agregar los argumentos que recibe, sus retornos, agregar algunos ejemplos, etc., también obtengo una buena vista de la historia del código que estoy escribiendo. Entiendo cómo funciona como parte del panorama general.

Los buenos documentos demuestran que comprende completamente lo que está haciendo y cómo lo está haciendo. Si la historia no tiene sentido, es mejor averiguarlo a través de los documentos que a través del código mismo.

Al final del día, nuestra fuerza de voluntad es un recurso limitado. Obligarnos a luchar contra nuestra propia psicología cada hora de cada día es una batalla difícil de ganar. Sin embargo, adoptar las buenas prácticas es una rutina y darnos recompensas inmediatas por hacerlo puede ayudarnos a ganar mucho más al final del día.

Después de todo, un malvavisco a la vez no es suficiente.