7 Habilidades de programadores altamente "Efectivos"
5 min read

7 Habilidades de programadores altamente "Efectivos"

7 Habilidades de programadores altamente "Efectivos"

Los ingenieros de software nos damos el tiempo para aprender habilidades para las entrevistas de trabajo, aprendiendo a resolver problemas complejos de programación y perfeccionando nuestros CVs. hasta finalmente obtenemos el trabajo deseado. Luego de un tiempo nos damos cuenta que estas habilidades no son necesariamente las más importantes en el trabajo del día a día.

A continuación te muestro las 7 habilidades que podrías no haber considerado tan importantes, pero créeme lo son y te aseguro que podrán hacerte más efectivo:

1. Aprender a leer el código de otras personas.

hooriblecode

Aprender a leer código de otras personas trae muchas ventajas, por ejemplo puedes aprender a distinguir si un condigo esta mal diseñado o mal pensado (especialmente si lees tu propio código de hace unos años) o mejor aún si lees código de proyectos open source puedes aprender muchísimo acerca de patrones de diseño o arquitectura y de la forma en que ciertos problemas son o fueron abordados por otras personas.

Recuerda que el código bien escrito por lo general no necesita documentación y en general es muy educativo y agradable de leer.

2. Sentido común para los proyectos

Hay mucha tela que cortar aquí, cuando una compañía crece y llega a tener muchos proyectos, suele pasar que tratan de resolver  cualquier problema por más pequeño que, con programación, en serio esto pasa.

No todos los problemas se resuelven necesariamente con programación

Tratar de resolver todo con programación puede llevarte a crear soluciones que al final nadie usará o que tenían sentido en un contexto pero ya que fué desarrollado ya no tienen sentido.

Por otro lado si no puedes explicar qué hará exactamente el el programa o proyecto que hiciste o estas haciendo, el problema que soluciona y cuan recurrente es este, entonces quizá no vale la pena hacerlo.

También esta el hecho de que como desarrolladores / Ingenieros,  tendemos a hacer sobre ingeniería con mucha facilidad.

El sentido común realmente no  se puede aprender tan solo leyendo, requerirá de hacer muchos proyectos, muchos experimentos y fallar en muchos de ellos, ya con el tiempo te aseguro que en un punto de tu carrera desarrollaras como "El colmillo" necesario para tener un buen sentido común para determinar cuando vale o no la pena hacer algo con programación.

3. Evitar la reunionitis

Las reuniones no son necesariamente malas, de hecho las reuniones entre producto, data e ingeniería son muy importantes porque sobre todo nos ayudan a sincronizarnos y asegurarnos de que todos estamos en la misma página.

Sin embargo esta la tendencia de hacer reuniones para todo y para nada, y ya cuando menos te lo esperas te das cuenta que todo tu día se pasa en solo reuniones.

El hecho es que mientras más reuniones tengamos, más difícil es tener un tiempo productivo y efectivo. Además es difícil retomar el hilo de las cosas que estabas haciendo antes de una reunión.

Las reuniones importantes generalmente son las que tienen que ver con tomar decisiones importantes o liberar bloqueos para que el equipo avance. El resto de las reuniones se deberían poder minimizar.

Una forma fácil de evitar esto es apartar un par horas del día específicas para reuniones y tratar de que todas las reuniones necesarias quepan en este tiempo.

Otro consejo es hablar con las personas que están involucradas antes de que empiece el día por otros medios por ejemplo chat para agilizar las cosas antes de una reunión. Además porque por las mañanas al inicio del día todo suele ser menos ajetreado.

4. No reinventar la rueda, a menos que tu plan sea aprender sobre ruedas

wheel2


No estas solo, no eres el único que ha tenido o va a tener ese problema,

seguramente la solución que estás pensando hacer alguien más en alguna parte del mundo ya lo hizo, y es muy probable que esta solución tenga mejores prácticas y ya haya sido probada por otras de personas.

A lo que me refiero es que hay muchas librerías e implementaciones de terceros casi para cada problema, muchas veces esto te ahorrar horas de trabajo, pruebas y debugging. Ahora esta el otro extremo: Querer resolver hasta el detalle más ínfimo con librerías de terceros, lo que te puede llevar a construir proyectos con muchas dependencias que hacen que el tamaño de tu proyecto crezca innecesariamente y sea un poco menos actualizable.

5. Escribe código limpio y evita la sobre ingeniería

Screen-Shot-2020-05-23-at-14.19.12

Como desarrolladores de software tenemos un doble desafío cuando estamos escribiendo nuestras aplicaciones. Por un lado escribir un código que funcione y que resuelva los problemas que queremos resolver y por otro lado que este código sea legible y fácil de leer evitando la sobre ingeniería.

Hacer sobre ingeniería es de hecho hacer que el código sin necesidad sea mucho más complejo, solo para tratar de resolver problemas que no tenemos en el presente y es poco probable que tengamos en el futuro, un ejemplo:

Desarrollador resolviendo problemas de escalabilidad para una landing page que ni visitas tiene

El momento más fácil de detectar la sobre ingeniería es cuando estamos pensando en el diseño y cuando estamos escribiendo código. Porque ya en etapas más adelante la refactorización implica un esfuerzo adicional.

Pensar acerca del problema que estas tratando de solucionar y preguntarte constantemente ¿Cómo puedo hacerlo más simple? puedes minimizar la sobre ingeniería.

Otra cosa que puedes hacer es explicarle el problema y tu solución a un colega (o también a un pato de ule).

Recuerda que hay un balance entre los patrones de diseño, las abstracciones y el código simple, De hecho los patrones de diseño sirven para simplificar el código en el gran esquema de las cosas. También entre más abstracción, encapsulación haya, la depuración será torna más compleja.

6. Aprender a decir No y a priorizar

Decir que No y priorizar son dos habilidades que están muy relacionadas.

Priorizar quiere decir ejecutar las tareas que realmente tengan impacto para la compañía. Mientras que decir no solo quiere decir evitar el trabajo que quizá otros equipos deban hacer.

Esta habilidad puede ser difícil de adquirir, especialmente cuando se está empezando por que en ese entonces se quiere evitar los desacuerdos con cualquier miembro del equipo.

Recuerda que tu tiempo y tus energías son limitadas y saber gestionar estos recursos pueden evitarte problemas como el Burn Out

7. Ponerse en los zapatos de los usuarios

UX

A veces desconocemos el impacto real de las soluciones que construimos o quienes serán los usuarios y como estos utilizarán nuestras aplicaciones realmente.

Este desconocimiento nos lleva a construir software con un contexto quiza equivocado donde sobreentendemos conceptos que realidad necesitarían explicación.

Para evitar esto debemos obtener feedback constante de los usuario y observar como y cual es el uso de nuestro software en entornos normales y así detectar cuales serán las mejoras que podemos aplicar.