Lo que el código dice del programador

Con este título no intento estereotipar a los programadores en general, sino más bien expresar, en unos pocos párrafos, mi opinión sobre la realidad con la que me topé en mi primer proyecto a nivel profesional en .NET.

Lo que el código dice

Mi primera experiencia codeando fue en la facultad. No empecé desde chico como muchos de mis compañeros, es más, me sentí como un genio en la universidad cuando mi primera función retornó un resultado correcto por pantalla. Ahí descubrí que tal vez la programación iba a ser lo mío, aunque haya reprobado mi primer examen.

El resto es historia, practicar me hizo un programador efectivo, pero no eficiente. Hacer código que sólo yo podía entender, era tal vez de las cosas que me gustaban, un hábito que con dolor tuve que dejar atrás cuando entré a mi primer proyecto profesional, donde aprendí que no sabía nada de lo que es “programar”.

Encontrar funciones y métodos de más de 50 líneas, para mí ya era algo digno de una película de hackers, así que tomaba a mis compañeros como profesionales del tema y me enfocaba en aprender lo más posible de su trabajo, cuando ellos sometían sus tareas a “Peer Review”. Pero con el paso del tiempo, encontré cierto patrón de trabajo. Todos aportaban ideas separadas que se unían con un mismo fin: generar código de calidad, funcional y comprensible por todo el equipo.

Noté que, dependiendo de la tarea, primero se debía buscar en qué parte del proyecto se estaba aplicando algo parecido actualmente, no con el fin de “robar” código, sino de mantener un patrón a la hora de implementar funcionalidades y ser coherentes con la solución técnica en general.

Por eso, más allá de los estándares, cada persona tiene su estilo, y si es bueno, se va contagiando al resto del equipo. Por otro lado, si uno ve cosas positivas en los demás, tarde o temprano, termina adoptándolas. Y es ahí donde se ve el aporte de cada uno al objetivo común de tener un sistema funcionando, de calidad, y que el código no sea un spaghetti ininteligible.

Entiendo que cada programador deja una marca distintiva en cada línea que aporta, aunque sea mínima. A partir de esto, podemos conocer qué tipo de trabajador es, novato o experto, perfeccionista o efectivo, si sigue el manual de las buenas prácticas dejando código de calidad y legible para que otras personas puedan construir a partir de él; o si simplemente crea códigos que funcionan, pero que pueden quedar obsoletos rápidamente.

Conocer mi entorno me hizo entender más a fondo el proyecto en el que me encuentro, y lo más importante, me dio diferentes puntos de vista de lo que se necesita para ser un buen desarrollador, sin perder la esencia de lo que me impulsó a seguir con esta maravillosa carrera.

Autor:

Bernardo Ortiz.

.NET Developer at Baufest.

 

Contacto

info@baufest.com