5 hábitos a evitar si eres desarrollador de software

Los desarrolladores de software podemos caer en malos hábitos exactamente igual que cualquier otro profesional. Los malos hábitos, como en otras áreas, pueden venir de atrás -aprendimos erróneamente- o se pueden adquirir con el paso del tiempo, por falta de atención y motivación, redundancia, etcétera.

Queremos compartir con vosotros cinco malos hábitos que todo programador de software deberíamos evitar para no caer en la mediocridad.

5 hábitos a evitar si eres desarrollador de software

Mi código es el mejor

El perfil que cualquier equipo necesita es el de personas humildes, con ganas, inteligentes y con un ego pequeño. Humildes y con un ego pequeño, para que se centren tanto en sus compañeros, como en sí mismos. Que tengan ganas implica que poseen una fuerte ética de trabajo y que están decididos a contribuir en cualquier forma que puedan. Inteligentes, pero no solo de manera intelectual, si no también de manera social.

No critiques el código de los demás, pues podría ser el tuyo el que estuviera en el punto de mira. Procura realizar observaciones objetivas y profesionales, pero siempre sin juzgar. Sé humilde e intenta aprender de todos los que te rodean.

Recuerda siempre que tu ego es un obstáculo para tu trabajo. Si comienzas a creer en tu grandeza, es la muerte de tu creatividad. Tu aprendizaje se acabará el día que empieces a creer que no hay nada más que aprender.

Esto lo arreglo en un momento

Tomar atajos es muy tentador, todos lo hemos hecho alguna vez, sin embargo, tomar atajos no significa solucionar el problema. O al menos no hacerlo de la manera correcta. Tomar atajos en el mundo del desarrollo de aplicaciones es peligroso y debe evitarse, pues un atajo puede ahorrar un buen puñado de horas de trabajo, pero en el otro lado, puede causar innumerables errores, problemas y pérdidas cuantiosas de dinero y reputación.

Me acuerdo de todo. No necesito documentar el código

“La documentación es como el sexo; cuando es bueno, es muy, muy bueno, y cuando es malo, es mejor que nada”

Cita de Dick Brandon.

La documentación es el aceite de ricino de la programación. Los administradores piensan que es bueno para los programadores, pero los programadores mediocres ¡lo odian!. Precisamente un gran desarrollador integra la documentación de su código como parte del desarrollo del mismo.

De la misma manera que ocurre con un equipo comercial, los equipos de desarrollo de software siempre están en constante cambio y evolución. Los programadores puede cambiar de trabajo, de departamento o incluso jubilarse. En el peor de los casos, enfermedades, lesiones o el fallecimiento pueden dejar a un equipo huérfano. Pero el código también envejece: un programador puede olvidar fácilmente el funcionamiento de su código si no lo ha tocado durante un año o más tiempo.

En cualquier de estos escenarios, disponer de acceso a la definición de la estructura, documentos de diseño, especificaciones de API, páginas de manual y comentarios en el propio código puede significar la diferencia entre cumplir fechas de entrega o no hacerlo. O de buscar un atajo para solucionar un problema, frente a una solución estable, sólida e integral.

Y esta actitud es la que nos convierte en un activo valioso para el equipo. Erróneamente se suele pensar, que si no documentas intencionalmente un código, te vuelves “irremplazable” para el equipo, pero realmente todo lo que estás generando se convierte en una responsabilidad “irreparable” para tu equipo. La diferencia es sustancial.

¡No es culpa mía!

Como dijo Bruce Lee “Los errores siempre son perdonables, si uno tiene el coraje de admitirlos”. Admitir errores es una de las características que hacen de un desarrollar un gran desarrollador.

Los malos programadores culpan a los clientes por no usar el producto “correctamente”. Un buen desarrollador debe responsabilizarse de todo el producto completo y de sus errores.

Tener una actitud humilde con la que podamos decir algo así como “sí, tiene usted razón, aquí hemos cometido un error y ahora debemos buscar una solución” te ayudará a construir una buena reputación entre tus compañeros y tus clientes, que te tendrán en más alta estima. Cuanto antes admitas tus errores, más tiempo dispondrás para aprender, rectificar y mejorar.

Decir que está “hecho” cuando no lo está

Si la programación fuera sexo, habría muchos ordenadores insatisfechos jejeje. No puedes entrar, hacer las cosas a la mitad y luego quedarte dormido. Uno de los conceptos con los que luchamos casi todos los días es con el concepto de “Hecho”.

Debemos recordar que hacer algo significa: programarlo y documentarlo por un lado y que sea probado y aprobado por el usuario que lo va a utilizar.

Un buen desarrollador está deseoso de aprender nuevas cosas. Nos esforzamos por comprender cómo funcionan, en qué estado están y cómo trabajan juntas todas las piezas de la arquitectura. Cuestionan el diseño y las ideas detrás de las características para resolverlas: ensalzan la importancia de la experiencia de usuario.

Un mal desarrollador, en cambio, está conectado a su tecnología, lenguaje, entorno y/o plataforma favorita. Cree su método o proceso es el ideal y que la experiencia de usuario nunca debería conducir a la toma de decisiones. Incluyen dependencias innecesarias en los proyectos, solo para que se adapten a sus preferencias.

Los proyectos exitosos son aquellos que son aceptados y validados por los usuarios finales y que acaban formando parte irremplazable del flujo de trabajo de estos usuarios.

Resumiendo

Si tuviéramos que resumir todo lo anterior con una única palabra, esa sería: actitud. Solo el trabajo no es suficiente, debes tener una correcta actitud en el trabajo. Tener una gran actitud es mejor que cualquier cantidad de años de experiencia.

Este artículo 5 hábitos a evitar si eres desarrollador de software es original de Velneo.