¿Cómo puedo desarrollar más rápido?

Cuando empiezas a programar y desarrollar, es usual que no vayas a un ritmo tan rápido como imaginaste. Normalmente, nos preguntamos cómo podemos acelerar nuestro ritmo para entregar productos de calidad en el menor tiempo posible. En este artículo presentamos varios consejos para poder desarrollar más rápido, luego de tener una cantidad de experiencia decente programando.

Obtén retroalimentación sobre lo que haces lo antes posible

Si eres principiante, es seguro que habrá muchas formas de mejorar tu código. Si la aplicación funciona como se esperaba, tal vez tu solución era un poco complicada. Si el enfoque está bien, tal vez se olvidó de aplicar un estilo de código antes de comprometerse. O tal vez cometiste uno de los muchos pequeños errores al usar Git, que podría ser tan sutil como usar el tiempo incorrecto en tu mensaje de confirmación.

Desde el punto de vista de tu colega más veterano o de tu mentor, es imposible predecir lo que puede salir mal. Tienes que llevar tu producción a una revisión, y ahí es posible corregir la dirección en la que te estás moviendo. Cuanto antes solicites el feedback, más rápido será todo el proceso. Por ejemplo:

• Escribe cómo crees que se puede resolver el problema antes de empezar a cambiar el código.
• Dibuja esquemas de la interfaz antes de empezar a construirla.
• Crea una solicitud de fusión para la implementación antes de actualizar todas las pruebas unitarias.

No es necesario que una tarea esté totalmente terminada antes de pedir una revisión. Revisar las cosas es rápido y, si tienes suerte, tus compañeros podrán revisar antes de que tú pases demasiado tiempo siguiendo el camino equivocado. Es una diferencia entre escribir y leer: yo paso unas 3 o 4 horas escribiendo artículos, y para ti probablemente sean 10 minutos de lectura.

¿Realmente necesitas escribir rápido?

¿Mejor dicho, necesitas escribir poco? Tu trabajo consiste en resolver problemas, no en escribir código. Si puedes resolver problemas rápidamente (o más rápido de lo que creas nuevos), entonces estás haciendo bien tu trabajo. El código que produces es parte del problema: necesitará ser revisado, probado y mantenido durante mucho tiempo.

Los recursos de aprendizaje se centran en exponerte a los conceptos que intentan enseñarte. En el caso de la programación, te mostrarán algún proyecto o tarea de ejercicio y te harán programar para resolverlo sin cuestionar si tiene sentido. Un buen rendimiento en tu trabajo requiere que escribas código sólo si no hay una solución mejor disponible.

Cuestiona cada uno de los features a realizar

Primer paso: asegurarse de que "lo que se necesita" es realmente necesario. A veces recibirás una solicitud para añadir una función que no debería formar parte del sistema. O ya existe algo que el usuario o el colega que escribió el ticket no conoce. O la solicitud es para una cosa "agradable de tener", en lugar de algo realmente importante.

En resumen, trata de entender los requisitos lo suficientemente bien como para poder evaluar si son realmente necesarios.

¿Cómo utilizar proveedores externos de código?

Al final del día, no hay forma de evitar añadir funciones al sistema. La siguiente mejor solución es encontrar un proveedor externo que haga el trabajo pesado por ti. Por ejemplo:

• Un proveedor en la nube que obtiene direcciones a partir de texto en un mapa.
• Una solución completa para realizar pagos en una aplicación (física o en línea).
• Un servicio de correos que permite enviar correos sin preocuparte del filtro de spam.

Las integraciones suelen ser un quebradero de cabeza, pero si encuentras un proveedor con una buena API, te puede ahorrar mucho tiempo en escribir y mantener tu propio código.

Uso de librerías de terceros

Algunas tareas son demasiado pequeñas para abstraerlas de tu aplicación y obtenerlas de una herramienta externa. Para muchas necesidades típicas y menos típicas, puedes encontrar una librería de terceros que te proporcione cierta ayuda con ellas. Las bibliotecas vienen con una compensación:

• Proveen soluciones a muchos problemas.
• Requieren que aprendas a utilizar su API.
• A veces, esas APIs tienen sus propios problemas.

Si eliges la biblioteca equivocada, puede causarte mucho dolor. Hay algunas cosas sobre una biblioteca que puedes evaluar antes de decidirte a usarla: la documentación; cómo se ve el proyecto en GitHub; comparaciones con otras opciones en línea. Otras cosas sobre la biblioteca, no tanto: qué futuro va a tener la biblioteca y si se mantendrá mientras tu proyecto la necesite.

Qué tipo de cosas nos proporcionan las bibliotecas:

• Métodos para operar entre fechas.
• Features relacionados a dinero y pagos.
• Generación de gráficas y tablas.

Reutiliza tu propio código

Poco a poco te vas quedando sin opciones. Pero antes de escribir algo nuevo, asegúrate de que no se ha implementado ya en tu proyecto. También determina si algún caso muy similar que ya tenga código puede ser reutilizado aquí.

La reutilización de código es complicada: te ahorra tiempo cuando utilizas el mismo código en casos de uso relacionados, pero creará problemas si reutilizas código para casos no relacionados. Por ejemplo, sumar y restar funciona igual para la temperatura y el dinero; hasta que alguien introduzca soporte para el cero absoluto. No te gustaría que tu aplicación se bloqueara en cuanto la cuenta bajara de -273,15.

Escribe código legible y organizado.

Cuando todo eso falle, escriba lo mínimo necesario para satisfacer la necesidad, pero escríbalo tan bien como pueda. Nombra las clases, los métodos, los argumentos y las variables de forma significativa. Documenta el código. Escribe pruebas unitarias y también algunas pruebas de integración. Añade un mensaje de confirmación que explique lo que ocurre en el código y por qué.

En resumen: codifica siempre como si el tipo que acaba manteniendo tu código fuera a ser un psicópata violento que sabe dónde vives.

No te preocupes demasiado por la velocidad

Nadie programa rápido. ¿Has oído el mito del desarrollador 10x? Supuestamente, algunos desarrolladores son 10 veces más rápidos que sus compañeros; puede que haya algunos genios por ahí, pero me temo que en la mayoría de los casos la gente se mueve rápido tomando atajos. Tomar atajos puede ser necesario a corto plazo, pero al hacerlo se crea una deuda técnica que es necesario abordar para la salud del proyecto a largo plazo. De ahí la respuesta a este mito: los devs 10x son los que necesitan 10 devs para limpiar después de ellos.

¿Cómo es programar en la vida real?

El día a día está lleno de situaciones que pueden provocar la sensación de lentitud. El otro día, me pasé 2 horas intentando conectar una impresora de red, y mi solución requería trasladarla a una sala de estar. De vez en cuando, me paso horas solucionando un problema que ha sido provocado por algún problema menor: un error tipográfico, perseguir el error en el lugar equivocado o cualquier otro error.

¿Soy duro conmigo mismo por esos "fallos"? No. ¿Por qué? Es parte del trabajo: a veces se ofrece una solución rápida, otras veces se necesita más tiempo.

Resumen

Como programador junior, tu trabajo es aprender cosas y encontrar formas de ayudar en el proyecto. Toda persona razonable entiende que el aprendizaje requiere tiempo. En un buen lugar de trabajo, recibirás el apoyo que necesitas para progresar y no se te presionará para que te desarrolles más rápido.

Para mí, los programadores junior rápidos me dan miedo. Prefiero tener un colega junior lento que acabe haciendo las cosas bien. Que aprenda rápido, que responda a los comentarios... eso suena muy bien. Pero uno que se limite a hacer cambios rápidamente, no tanto.

- Zant.