Empezar a trabajar siempre es un gran desafío para cualquier persona. Puedes poseer las mejores destrezas técnicas como programador, pero eso no te convierte en el mejor programador en el ámbito profesional. Evidentemente ayuda, pero además de saber programar, hay que aprender muchas otras cosas para convertirse en un programador profesional.
Las empresas cuando contratan a un novato no pretenden obtener de él un retorno de la inversión desde el primer día. Saben que habrá un proceso de adaptación de meses o incluso años, así que lo mejor es hacerse a la idea y tomárselo como una nueva etapa que te ayudará a crecer profesionalmente a medio plazo.
Tampoco se trata de que no saques a relucir tu verdadera personalidad ni que te calles siempre. Este artículo no va de eso. Siempre hay momentos y contextos en los que podrás decir lo que piensas a cualquier jefe o compañero.
Lo que expondremos aquí son conductas que suelen reproducirse en programadores con poca experiencia y que las empresas preferirían que se minimizasen, por el bien de la empresa y también por tu propio crecimiento profesional.
Lo normal es tener estos hábitos, pero también lo habitual es corregirlos a medida que se va adquiriendo experiencia.
Tras años muchos de experiencia trabajando con programadores noveles, he decidido recopilar aquellas conductas que más se repiten y que no ayudan ni a la rentabilidad de la empresa, ni al propio desarrollo de un programador inexperto que busca crecer profesionalmente. Además, he completado el listado con otras opiniones vertidas en foros sobre el tema.
De la A a la Z: Hábitos que se deben mejorar (si los tienes)
A) Ir de sabelotodo. No te aferres al sentimiento de inseguridad de que tienes que saberlo todo. No lo sabes todo. Y eso está bien, es lo esperable.
B) No saber decir que no cuando sea lo razonable. Como programador tienes que aprender a decir que no. "No puedo ir a la reunión", "no puedo hacer eso en ese plazo", "esa funcionalidad no sé hacerla"... Decir que no puede suponer un pequeño inconveniente a corto plazo, pero a la larga ganarás fiabilidad y tus compañeros confiarán más en ti.
C) Actuar a la defensiva cuando alguien critica tu código. Los mejores y más expertos desarrolladores están dispuestos a tener una conversación abierta y franca sobre el código que han desarrollado y cómo puede ser mejorado.
D) Rendirse demasiado pronto. Hay demasiados programadores que se acercan mucho a una solución, para luego darse por vencidos justo antes de que estén a punto de resolver el problema. No rendirse nunca es una aptitud fundamental para un programador.
E) Negarse a pedir ayuda. El simple hecho de exponer tu problema de programación a otra persona, a menudo te ayudará a descubrir la solución, incluso por tu cuenta.
F) Echar la culpa a los demás. El desarrollador más valioso es el que toma la iniciativa y la responsabilidad del código que escribe.
G) Optimización prematura, o sea, escribir código que optimice otro código antes de ser necesario. En muchos casos, la ventaja de rendimiento que se obtiene al optimizar tanto el código no compensa porque se vuelve difícil de entender por los demás compañeros, complicando su mantenimiento en el futuro.
H) Hacer caso omiso de las opiniones de otros desarrolladores. Una de las mejores maneras de aprender y crecer como desarrollador es revisar a pares el software con desarrolladores que tengan más experiencia que tú. Busca las opiniones de otras personas con más experiencia.
I) No saber cómo optimizar código. Hay algunas situaciones en las que el rendimiento es un gran problema, como por ejemplo problemas del tipo:
- Complejidad algorítmica
- Operaciones ineficientes de la base de datos
- APIs de terceros
- Consultas N+1
Cuando surgen problemas de rendimiento, es necesario saber cómo analizarlos, entender qué es lo que está consumiendo tiempo y cómo solucionar los problemas. Y esto requiere experiencia, y saber hacerlo en el momento oportuno (ver letra G :wink:).
J) Infravalorar las relaciones con los demás miembros del equipo. Se te contrata para escribir código. Pero también necesitas ser capaz de interactuar con otros miembros del equipo. El saber desarrollar en equipo es muy importante y la comunicación tanto o más.
K) Hacer la guerra dentro de la empresa contra otros departamentos. En ocasiones, otros equipos de desarrollo tomarán decisiones que tú crees que son equivocadas. Pero mientras puedas lograr los objetivos de tu equipo, es mejor trabajar simplemente en torno a las "caprichos" de otros equipos, en lugar de luchar contra ellos con demasiada fuerza.
Recuerda que muchas veces la respuesta a "¿Qué clase de idiota ha hecho esto?" es "Un tipo inteligente y con la mejor intención, teniendo que llegar a compromisos que ni siquiera se me habían ocurrido".
L) Paralizarse bajo presión. Cuando se opera en un escenario en el que los usuarios finales no pueden utilizar el software, se produce un montón de presión. Es necesario que uno sea capaz de seguir programando con calma y terminar el trabajo.
M) Ser incapaz de escribir código malo. En el mundo real, hay veces en los que compensa que no todo vaya perfecto en situaciones como:
- Fechas límite.
- Experimentos.
- Errores urgentes que deben ser arreglados inmediatamente.
Se necesita poseer la mentalidad de que está bien escribir un código malo para cumplir con las exigencias impuestas.
Recuerda: lo perfecto es lo enemigo de lo bueno.
N) No tener en cuenta la opinión del usuario. Si despreciar la opinión de tus colegas es malo, desoír los comentarios de los usuarios cuando estás haciendo una aplicación para usuario final es un grave error. Nunca deberías tomar decisiones de forma unilateral.
Ñ) Escribir demasiados o no suficientes comentarios en el código. Los comentarios son notas esenciales para los desarrolladores. Pero como todo, se deben usar con moderación.
O) Usar herramientas equivocadas para los proyectos. No tomes decisiones basadas en "es lo que yo sé". Es necesario estar abiertos a utilizar diferentes tecnologías, lenguajes y entornos de desarrollo.
P) No mantener un buen dominio sobre tus herramientas de programación. Dado que pasarás muchas horas usando cosas como editores de texto, línea de comandos y otras herramientas para escribir código, es esencial dominarlas. Al igual que el sistema operativo, claro. Tómate el tiempo necesario para aprender los trucos y consejos que te hacen más eficiente y para estar actualizado. Te sorprendería saber cuántos programadores no dominan ni sus herramientas ni siquiera el sistema operativo.
Q) Obviar los mensajes de error. Los errores de código ocurren con frecuencia. También suelen incluir información muy valiosa sobre lo que ha fallado, por qué ha sucedido y qué líneas han desencadenado los problemas. Se deben investigar los mensajes de error, en lugar de tratar de eludirlos.
R) Contar las horas. Los mejores desarrolladores disfrutan del tiempo que pasan programando y se sumergen en él. Si no sientes una especie de evasión placentera programando, algo no funciona, aunque lleves años programando.
S) Negarse a aprender de los errores. Esto es contraproducente. Cuando ocurren errores, simplemente aléjate del contexto y piensa en estas tres cosas:
- ¿Cuál fue la causa última del error?
- ¿Podrían ponerse en práctica procesos o comportamientos para evitar que este tipo de errores ocurra en el futuro?
- ¿Se podría detectar el error antes y tener menos impacto?
Negarse a aprender de tus errores hará que los repitas.
T) Tener miedo de desechar código. Ten en cuenta que pasar tres días programando una solución incorrecta te enseñará más que si caes víctima de la parálisis por análisis.
U) Idealizar tu juego de herramientas de desarrollo. A algunos desarrolladores les encanta el editor de texto "vim". Otros lo odian y aman el editor de texto "emacs", o Atom, o Visual Studio Code... Pero habrá escenarios en los que tenga sentido usar unos en vez de los otros. El caso es no cerrarse en banda.
V) No compartir con la comunidad. Deberías unirte a la comunidad de programación en lugares como Github o Stackoverflow tan pronto como sea posible, aparte de en tus comunidades locales si el tiempo te lo permite. Si lo haces, te darás cuenta de lo útil y amigable que es.
W) Pedir disculpas constantemente por mal código. Si descubres que te estás disculpando continuamente por un código lleno de errores, podría significar que necesitas volver a evaluar tus plazos (o tus conocimientos).
X) No invertir la energía suficiente en pruebas de código. El equipo de desarrollo está en esto junto y es responsabilidad de cada miembro del equipo asegurarse de que el código con el que todos los demás miembros contribuyen está a la altura del nivel del equipo.
Y) Diferenciar entre buenas prácticas y estilos de programación. A los programadores sin experiencia les cuesta distinguir si su mentor le está enseñando buenas prácticas o lo está convirtiendo en un "miniyo".
Z) Aferrarse a un plan bien pensado que claramente no está funcionando. La única cosa peor que abandonar un plan en el último minuto es negarse a dejar de ejecutar una mala idea.
Conclusión
La clave para mejorar como desarrollador o como cualquier otro tipo de profesional es seguir estos tres pasos:
- Reconocer que tienes malos hábitos.
- Encontrar la motivación para cambiarlos.
- Poner en práctica esa motivación eliminando los malos hábitos y practicando los buenos.
¡Es fácil decirlo pero no hacerlo!
Si se te ocurren otros hábitos que es preferible evitar cuando empiezas a trabajar como programador, o quieres compartir tu propia experiencia, te invito a que lo hagas en los comentarios.
Además te recomendamos:
Fecha de publicación: