Tu guía para convertirte en un programador más rápido

Así que ya logró alcanzar sus primeros objetivos de programación, tal vez desarrolló una aplicación de ejemplo para dos. ¡Excelente! Sin embargo, era un poco lento, y un desarrollador profesional seguramente sería mucho más eficiente con él. Así que ahora tu pregunta es esta: ¿cómo ser más rápido programando?

Trate de obtener comentarios lo antes posible

Si es un principiante, es seguro asumir que habrá muchas formas de mejorar su código. Si la aplicación funciona como se esperaba, tal vez su solución fue un poco complicada. Si el enfoque está bien, tal vez olvidó aplicar un estilo de código antes de confirmar. 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 la perspectiva de su colega principal o mentor, es imposible predecir qué podría salir mal. Debe llevar su salida a una revisión, y luego allí, es posible corregir la dirección en la que se está moviendo. Cuanto antes solicite los comentarios, más rápido será todo el proceso. Por ejemplo:

• escriba cómo cree que se puede resolver el problema antes de comenzar a cambiar el código
• dibuje estructuras alámbricas de la interfaz antes de comenzar a construirla
• cree una solicitud de fusión para la implementación antes de actualizar todas las pruebas unitarias y e2e

No es necesario completar una tarea antes de solicitar una revisión. Revisar las cosas es rápido y, si tiene suerte, sus colegas podrán revisarlas antes de que pierda demasiado tiempo siguiendo el camino equivocado. Es una diferencia entre la escritura y la lectura: paso alrededor de 3 o 4 horas escribiendo artículos, y probablemente sean 10 minutos de lectura para ti.

escribir rápido?

¿O más bien escribir poco? Su trabajo es resolver problemas, no escribir código. Si puede resolver problemas rápidamente (o más rápido de lo que crea otros nuevos), entonces lo está haciendo bien en su trabajo. El resultado del código que produce es parte del problema: necesitará revisión, prueba y mantenimiento 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 desempeño en su trabajo requiere que escriba código solo si no hay una mejor solución disponible.

Cuestionar todas las solicitudes

Primer paso: asegurarse de que realmente se necesita 'lo que se necesita'. A veces, recibirá una solicitud para agregar una característica que no debería ser parte del sistema. O ya existe algo que el usuario o su colega que escribió el ticket no conocen. O la solicitud es por algo 'bueno de tener', en lugar de algo realmente importante.

En resumen, intente comprender los requisitos lo suficientemente bien como para poder evaluar si son realmente necesarios.

Proveedores externos

Al final, no hay forma de evitar agregar funciones al sistema. La siguiente mejor solución es encontrar un proveedor externo que haga el trabajo pesado por usted. Por ejemplo:

• un proveedor de nube para convertir la entrada de direcciones de texto libre a una ubicación en un mapa
• una solución de pago completa, para tiendas en línea o físicas
• un servicio de correo que le permite enviar correos electrónicos sin preocuparse por los filtros de spam

Las integraciones suelen ser un dolor de cabeza, pero si encuentra un proveedor con una buena API, puede ahorrarle mucho tiempo escribiendo y manteniendo su propio código.

Bibliotecas de terceros del usuario

Algunas tareas son demasiado pequeñas para abstraerlas de su aplicación y obtenerlas de una herramienta externa. Para muchas necesidades típicas y menos típicas, puede encontrar una biblioteca de terceros que brinde ayuda con estas. Las bibliotecas vienen con una compensación:

• proporcionan una solución para algunos problemas
• pero requieren que aprendas su API
• y a veces traen sus propios problemas

Si elige la biblioteca incorrecta, puede causarle mucho dolor. Hay algunas cosas sobre una biblioteca que puede evaluar antes de decidir 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 lo necesite.

Qué tipo de cosas nos proporcionan las bibliotecas:

• métodos para operar en fechas
• características relacionadas con el dinero, para que no tenga que preocuparse por el resultado de 0.1 + 0.2
• generar gráficos

Reutiliza tu propio código

Poco a poco te estás quedando sin opciones. Pero antes de escribir algo nuevo, asegúrese de que no se haya implementado en su proyecto. Determina también si aquí se puede reutilizar algún caso muy similar que ya tenga código.

Reutilizar el código es complicado: le ahorra tiempo cuando usa el mismo código en casos de uso relacionados, pero creará problemas si reutiliza el 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 le gustaría que su aplicación se bloquee tan pronto como la cuenta baje de −273.15.

Escribe buen código

Cuando todo eso falla, escriba lo menos necesario para satisfacer la necesidad, pero escríbalo lo mejor que pueda. Nombra clases, métodos, argumentos y variables de manera significativa. Documentar el código. Escriba pruebas unitarias y también algunas pruebas de integración. Agregue un mensaje de confirmación que explique qué sucede en el código y por qué.

En breve:

Codifica siempre como si el tipo que acabará manteniendo tu código fuera un psicópata violento que sabe dónde vives.

Repite todo el proceso

Una vez que haya terminado con la función en la que ha estado trabajando, estará listo para ir al primer punto y comenzar de nuevo.

no te apresures

No te preocupes, nadie programa rápido. ¿Has escuchado el mito del desarrollador 10x? Supuestamente, algunos desarrolladores son 10 veces más rápidos que sus pares; tal vez haya algunos genios, pero me temo que, en la mayoría de los casos, las personas se mueven rápido tomando atajos. Tomar atajos puede ser necesario a corto plazo, pero hacerlo crea una deuda técnica que debe abordarse para la salud a largo plazo del proyecto. De ahí la respuesta a este mito: los desarrolladores 10x son los que necesitan 10 desarrolladores para limpiar después de ellos.

Vida real

Los trabajos del día a día están repletos de situaciones que pueden desencadenar la sensación de lentitud . El otro día, pasé 2 horas tratando de conectar una impresora de red y mi solución requería moverla a una sala de estar. De vez en cuando, paso horas solucionando un problema que fue causado por un problema menor: un error tipográfico, perseguir el error en el lugar equivocado o cualquier otro error estúpido .

¿Soy duro conmigo mismo por esos 'fracasos'? ¿No porque? Es parte del trabajo: a veces entrega una solución rápidamente y, a veces, lleva más tiempo.

Resumen

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

Para mí, los programadores junior rápidos suenan aterradores. Preferiría tener un colega junior lento que eventualmente haga las cosas bien. Aprendices rápidos, receptivos a los comentarios, eso suena genial. Pero uno que simplemente bombea cambios rápidamente, no tanto.

También publicado aquí