Top 7: Malos hábitos del programador.

Te presentamos algunos malos hábitos (no necesariamente técnicos) con los que puedes coincidir como Desarrollador de Software y qué medidas puedes tomar para evitarlos.

1.- Actitud “todo el código es basura, excepto el mío”.

No importa cuánto empeño le pongas a un código, siempre habrá una mayoría de programadores que van a pensar que tu código apesta y que ellos lo habrían hecho 10 veces mejor. Aunque siempre es importante mantener tu código.

Como arreglarlo: Trata de no criticar el código de otras personas, podrías ser tu al que esten enjuiciando. En lugar de eso, trata de hacer observaciones objetivas y profesionales. Sé humilde y trata de aprender de los demás.

2.- La catástrofe de “yo arreglo esto en un segundo”.

Tomar atajos es muy tentador, todo mundo lo hace. Incluso hay situaciones en las que son necesarios pero, en general, son peligrosos y deben ser evitados. Un atajo que lleva a otro lugar puede ahorrarte un par de horas, pero puede causarte meses de dolor (y no queremos estar corrigiendo código que pensabamos que ya funcionaba).

Como arreglarlo: No te confíes cuando se trate de actividades delicadas. Pídele a alguien mas que haga una revisión de lo que tienes que hacer. Asegurate de que si vas a tomar un atajo, las partes interesadas sepan cuales son los riesgos y las razones. Trata de asegurarte de que tu jefe/team leader/project manager sepa cuando vas a tomar un atajo. En otras palabras, “cubre tu trasero”.
3.- El concepto erroneo “eso solo va a llevar un minuto”.

Ten cuidado con las estimaciones. Piensa en esto: “La Sagrada Familia, en Barcelona, es conocida por su belleza y por el tiempo que Gaudí estimó que le tomaría terminarla”. La construcción comenzó en 1882. Si hubieran puesto a un Ingeniero de Software seguramente hubiera dicho 2 semanas.

Como arreglarlo: Es importante entender que las estimaciones precisas en desarrollo de software para soluciones no triviales son imposibles, sólo podemos adivinar. Asimismo, recuerda que es muy probable que encontrarás muchas cosas que no previeron cuando se inició el desarrollo, por lo que vale la pena multiplicar la estimación por 1,5 ó 2, para conseguir cubrirlas.
4.- La espiral del ego.

Muchas discusiones entre desarrolladores parecen mas peleas de gallos que discusiones entre personas. Suele pasar en las juntas de arquitectura y diseño (Y cuando a Gerardo y a mi se nos pasan las copas). Es fácil evitar estas espirales, solamente tienes que reemplazar casi todo lo que dicen con ¡QUI-QUI-QUI-QUIIIII! o algo asi.

Como arreglarlo: Deja el ego en casa. El ego es uno de los problemas (no técnicos) mas grandes de lo programadores. Es importante ignorarlo cuando se estan tomando decisiones.

5.- “Yo no fuí”.

Por lo general siempre tenemos una excusa para no asumir la responsabilidad de nuestros errores. Es como si pretendieramos que, en condiciones normales, no cometeríamos ningún error, lo cual es dificil de creer.

Como arreglarlo: Nuevamente, un poco de humildad y una actitud sana de: “Yeap, yo la cagué. Quizá podamos corregirlo de esta manera”. Ser propositivo siempre es una actitud profesional.

6.- El genio desmotivado.

Tareas simples y repetitivas no representan nigún reto, por lo tanto, no son motivantes. Sin embargo, tienen que hacerse y los programadores tienden a hacerse improductivos y flojos y hasta displicente.

Como arreglarlo: Disciplina. Pura y simple disciplina. =(

7.- Programador prematuro.

Si la programación fuera sexo, habría muchísimas computadoras insatisfechas. No se trata de llegar, dejar las cosas a la mitad y quedarse dormido. Uno de los conceptos con los que la mayoría de los programadores difieren es el concepto de “Terminado”. Recuerda que hay un proceso en el que, para poder decir que está terminado, previamente debió haber sido probado (Unit Test y User Acceptance Test), documentado, dar commit en el repositorio, etc…

Como arreglarlo: Disciplina, entrenamiento y, usualmente, establecer estándares para determinar una entrega. Quizás las dos formas mas fáciles para ayudar a entender a un programador que su código está terminado son las peer reviews y los demos.

Fuente original: Making Good Software

About the author  ⁄ atcervantes

Me gusta leer libros junto a la chimenea y las caminatas largas por la playa.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam Protection by WP-SpamFree

  • RSS
  • Newsletter
  • Facebook
  • Google+
  • Twitter