Cinco errores cometidos por desarrolladores principiantes

Cinco errores cometidos por desarrolladores principiantes
Seamos sinceros: los desarrolladores cometen errores.

Un montón. Durante los últimos 5 años estuve codificando, 3 de ellos comercialmente, y en ese tiempo he podido identificar (por las buenas y por las malas) algunos problemas que impiden que los desarrolladores avancen en su carrera. Personalmente, siempre intento escribir mi código de forma consciente, busco formas de mejorarlo constantemente y me gusta compartir mis pensamientos con los demás. Es por eso que resumiré aquí mis observaciones y propondré un par de sugerencias que pueden ayudar a prevenir las equivocaciones más comunes, especialmente para quienes están comenzando su camino profesional.

  1. No hacer preguntas

    Uno de los principales errores cometidos por los desarrolladores más novatos es que -en cuanto se les asigna una nueva tarea- desean comenzar a codificar de inmediato y presumir de su eficiencia. Muchos pasan por este período al comienzo de su carrera, incluyéndome a mí. Nadie niega que el impulso y la motivación son útiles, pero trabajar sin un plan o sin comprender del todo la tarea resulta ser una pérdida de tiempo y energía.

    Muchas veces, debido al temor de estropear la primera impresión, tienden a abstenerse de hacer preguntas y, cuando se encuentran con un problema, quieren resolverlo por su cuenta lo cual termina resultando un desastre: una tarea que se supone que debía resolverse en dos días, sigue pendiente después de una semana y es difícil estimar cuánto tiempo llevará concluirla.

    Por lo tanto, es bueno hacer tantas preguntas como sea necesario. Y cuanto antes se hagan, mejor.

  2. Ignorar el panorama general

    No es extraño que -al concentrarse tanto en la implementación o la estructura del código- se pierda de vista el panorama general del trabajo que se está realizando. Los desarrolladores a menudo evitan buscar documentación técnica, lo cual puede dar lugar a decisiones subóptimas o simplemente erróneas en el nivel de diseño e implementación.

    Esto es porque la documentación es esencial para disipar posibles dudas: un conocimiento básico del dominio de un proyecto es crucial para comprender completamente los requisitos del negocio; cualquier desarrollador profesional sabe que debe profundizar en esto para ser eficaz y tomar buenas decisiones.

    Cuando se está involucrado en un proyecto relacionado con las finanzas, es esencial comprender conceptos como el libro mayor o la cuenta de desembolso, así como en el comercio electrónico se debe saber qué es el itinerario y el cumplimiento.

  3. Hacer demasiadas suposiciones

    En el modelado de dominios, es esencial hacer algunas suposiciones. Pero si éstas llegan a ser equivocadas, pueden conducir a problemas que son difíciles de detectar y resolver, y a terminar reescribiendo partes sustanciales de la aplicación. Esto, obviamente, implica una pérdida innecesaria de tiempo y dinero. La siguiente lista contiene solo una parte de supuestos erróneos más comunes:

    • el sistema no se usará en diferentes zonas horarias;
    • el sitio web no se mostrará en menor o mayor resolución;
    • el usuario siempre tendrá acceso a Internet;
    • 2 usuarios no editarán simultáneamente los mismos datos;
    • 21 bits serán suficientes para ahorrar el precio de los boletos de tren;
    • el usuario no utilizará Adblock.

    Se pueden encontrar más de estos simplemente googleando la frase "falsedades que los programadores creen".

    Hacer suposiciones es algo natural y los errores en la mayoría de los casos son inevitables. Pero es bueno tener esto siempre presente y revisar el proyecto de un sistema a fondo antes de su implementación.

  4. No justificar las decisiones

    En su día a día, los desarrolladores utilizan varias fuentes de información. Mientras buscan una solución a un problema en particular, pueden encontrar una respuesta o un código de trabajo en GitHub o StackOverflow. La forma más sencilla es pegarlo en el propio código y estar feliz de que funcione. Sin embargo, no es suficiente. Siempre se debe poder explicar por qué funciona.

    Copiar el código a ciegas puede ahorrar tiempo, pero solo aparentemente. En la práctica, pone a un desarrollador en una mala situación cuando alguien les pide que expliquen por qué está escrito de una manera específica. He sido testigo de numerosas situaciones de este tipo.

    La capacidad de justificar cada decisión que se toma mientras se trabaja con el código es un excelente indicador del nivel de profesionalismo de un desarrollador. Significa que toman decisiones conscientes y dedican tiempo a comprender el código y la arquitectura de la aplicación.

  5. Ser irresponsable

    Asumir la responsabilidad de las acciones que uno mismo realiza es un signo de madurez. Desafortunadamente, esto es algo de lo que carecen muchos desarrolladores, lo que puede manifestarse en, por ejemplo, exceder los plazos sin ninguna información adicional o sin probar su código. Es difícil para un desarrollador irresponsable ascender y casi nadie le asignará una tarea seria (lo que con frecuencia significa "más interesante" también). Por eso vale la pena cuidar su imagen profesional y, para hacer eso, ser siempre fiel a su palabra. Si nota que no podrá finalizar su tarea a tiempo, informe a todas las partes interesadas al respecto y establezca un nuevo plazo. Siempre esté listo para ayudar a otros a comprender su código, sin importar la antigüedad que tenga. Asuma tareas difíciles, que resaltarán su profesionalismo y responsabilidad de una manera brillante.