Escribir código como programador senior

Escribir código donde la gente pueda leerlo fácilmente es algo que los desarrolladores de tu equipo realmente apreciarán y esa es a menudo la diferencia entre que te vean a ti como un desarrollador junior y un programador senior. Otra cosa por la que es importante escribir un buen código es que reduce el tiempo que llevará brindar soporte y explicárselo a otra persona. Es muy bueno aprender a escribir código como programador verdaderamente senior, porque reduce la posibilidad de que alguien reescriba tu código, creo que una de las cosas más frustrantes como desarrollador es cuando trabajas muy duro para implementar una característica y en un período muy corto después aparece alguien  y no les gusta algún aspecto o no lo entienden y lo reescriben todo. Creo que una de las mayores pérdidas de tiempo en muchos proyectos de software es reescribir código que ya funciona solo para adaptarse a las preferencias de alguien cuando en realidad no existe una razón de refactorización que realmente agregue valor al proyecto. Entonces, qué debemos hacer para escribir código como un verdadero programador senior… Lo primero es completar tu trabajo antes de continuar, es inmensa la  presión en muchos proyectos, eso aveces provoca que digas ya terminé, pero queda un poco de código a optimizar y simplemente lo dejaré, en el futuro volveré y lo arreglaré… pero al menos en mi experiencia, después de muchos proyectos en los que he estado, cuando lo haces básicamente estás acumulando deuda técnica para el proyecto, ahora nadie más puede verlo, puedo ser la única persona en el equipo que es consciente de ello, pero en última instancia, está ahí…. y si informas a los jefes de proyecto sobre el estado en el que estoy trabajando, tengo que ser muy honesto si voy a ser verdaderamente profesional y decir que no… no se ha terminado con esta tarea y si el resto del equipo o la gerencia están frustrados, preferible que se sientan frustrados y que sepan el estado real del proyecto, eso es básico. 

Siempre es bueno también en mirar tu código y pensar que cada vez que escribimos código alguien más lo verá en el futuro y básicamente van a medir lo que piensan de nosotros basándose en ese código, por lo que tener un poco de orgullo y asegurarse de terminarlo antes de seguir adelante es honestamente una de las primeras cosas que se puede hacer si realmente quieres que te tomen en serio como un programador senior. 

Otro tema que veo que hacen los programadores verdaderamente experimentados es que, afortunadamente, hoy en día imponen estándares de codificación y no teníamos esto antes. Es mejor usar herramientas como Visual Studio por ejemplo … porque es realmente frustrante tener que leer diferentes estilos de código cuando, honestamente, hoy tenemos la tecnología para hacerlo. 

Sigo pensando que tiene sentido escribir un wiki o un archivo readme o algo así en alguna parte, eso es muy fácil de entender para el equipo y dice que estos son nuestros estándares de codificación y si simplemente usas un estándar estándar como el que ha sido establecido por una comunidad de código abierto o algo asi. Otra cosa que puedes hacer y que realmente te ayudará a escribir código de nivel verdaderamente superior es ser mucho más disciplinado a la hora de documentar patrones. En muchos equipos que comenzarán un nuevo proyecto de software, que discutirán entre ellos, elegirán un conjunto de patrones, algunos de ellos son solo patrones de código abierto muy conocidos y otros no, y hay diferentes patrones que puedes elegir,por lo tanto desde tener al menos un tema wiki o un archivo de readme o algo que diga aquí están todos los patrones que hemos acordado que vamos a usar en el proyecto, creo que es realmente valioso porque de esa manera también, si estás haciendo revisiones de código o algo así y descubres que el desarrollador de tu equipo está usando algún otro patrón, es importante saberlo. Otra cosa que puedes hacer que realmente te ayudará a escribir código como programadores verdaderamente senior es nunca crear una historia de usuario o un ticket o, si estás usando Jira, algo así, una tarea que representa la refactorización, lo que se deberias hacer es, discutirlo con el resto de los desarrolladores y elaborar un plan sobre cómo distribuir ese esfuerzo en todo el equipo para que podamos refactorizar incrementalmente. Ahora la refactorización incremental es una habilidad realmente valiosa y conozco muchos desarrolladores que no saben cómo hacer esto, es momento de empezar si sucede esto… Otro factor importante también es que si me piden que estime el trabajo, deba agregar tiempo adicional para reuniones de diseño inesperadas y documentación que quizás tenga que escribir. Es muy común cuando estoy en proyectos, que sigo escribiendo código para comenzar a implementar una función y descubro que hay algo de incertidumbre aquí y para cumplir con los requisitos ahora tengo que agregar documentación nueva y lo peor es tener que volver con un gerente de proyecto o un scrum master y decirle: "Oye, necesito agregar una nueva historia de usuario para este nuevo documento", date tiempo extra no solo para las reuniones y la incertidumbre y todo eso, sino también para escribir documentación del código y mantener al equipo lo más enterado posible.