Larry Wall, el autor del lenguaje de programación Perl, dijo una vez que los grandes desarrolladores tienen tres virtudes: pereza, impaciencia y arrogancia.
Pereza porque los lleva a escribir programas que ahorran trabajo y a documentarlos bien para que no tengan que responder preguntas sobre ellos. Impaciencia porque los motiva a escribir programas que se anticipan a sus necesidades. Y arrogancia porque les hace querer escribir un código estricto que otras personas no criticarán.
Dicho esto, los programadores exitosos no son necesariamente los mejores programadores.
Un programador que hace bien su trabajo diario es mucho más efectivo que el que ocasionalmente alcanza alturas de codificación vertiginosas. Y para la mayorÃa de las empresas, lo que cuenta es el área bajo la curva, no el punto más alto que alcanza.
Y el éxito que buscas viene de cómo te ves a ti mismo, al mundo y a los hábitos que tienes para enfrentarte a los desafÃos de la vida. De hecho, según los investigadores de la Universidad de Duke, hasta un 40% de nuestro éxito (o fracaso) ocurre automáticamente como resultado de nuestros hábitos.
Y aquà hay algunos hábitos poderosos que pueden sobrealimentar su éxito como desarrollador.
Sea profesional
Steve Maraboli estaba en lo cierto cuando dijo: "Lo correcto y lo difÃcil suelen ser lo mismo. Y ambos requieren profesionalidad".
La profesionalidad es como la espada de Damocles. Por un lado, es una insignia de honor y orgullo, pero por el otro, también es un marcador de responsabilidad y rendición de cuentas. Los dos siempre van de la mano. No puedes enorgullecerte y honrar algo de lo que no puedes ser responsable.
Imagina que has escrito un código y lo has implementado en producción. Debido a tu código ocurre un problema serio y el sistema de producción se interrumpió durante un dÃa. Huelga decir que el cliente incurrió en una gran cantidad de pérdidas financieras. Reviertes el código pero cualquier daño que haya ocurrido no se puede deshacer.
El no profesional se encogerÃa de hombros y dirÃa "las cosas pasan" y empezarÃa a escribir el siguiente módulo. El profesional sudarÃa y se preocuparÃa por el desliz y se asegurarÃa de que algo tan chapucero no se repita de nuevo.
Siempre recuerda que la profesionalidad se basa en la responsabilidad. No puedes tener razón todo el tiempo. Pero tienes que admitir las cosas que has hecho mal.
No repetir el mismo error
Amit Kalantri dio en el clavo cuando dijo: "Si una disculpa va seguida de una excusa o una razón, significa que van a cometer el mismo error de nuevo por el que se han disculpado."
Claramente, queremos que nuestro software funcione. Pero no somos los únicos que queremos que el software funcione. Nuestras empresas y sus clientes también quieren que funcione. De hecho, nos están pagando para crear software que funciona tal y como ellos quieren.
Hasta ahora todo bien. Pero el software no es perfecto. Todo software tendrá errores.
La clave aquà no es aspirar a escribir un código perfecto. Esa es una fantasÃa utópica y nunca ocurrirá. El mensaje aquà es tomar la responsabilidad completa de todas las imperfecciones en tu software. Crea nuevos errores. Comete nuevos errores. Pero no repitas el mismo error una y otra vez.
A medida que maduras en tu profesión, tu tasa de error deberÃa disminuir rápidamente hacia cero. Nunca llegará a cero, pero es tu responsabilidad acercarte lo máximo posible.
No dejes nada al azar. Nunca funciona.
Jim Jenkins dijo con razón: "La amargura de la mala calidad se mantiene mucho después de que se haya olvidado la dulzura de cumplir con el horario."
La regla general es que si algo puede salir mal, saldrá mal y ninguna cantidad de suerte puede evitar que suceda.
Es por eso que las pruebas son tan importantes. ¿Cómo puedes saber que tu código funciona? Eso es fácil. Pruébalo. Pruébalo de nuevo. Pruébalo. Pruébalo. Pruébalo los 7 dÃas de la semana, hasta el domingo!
Incluso si los plazos son rÃgidos y la presión es inmensa para reducir gastos, automatiza los casos de prueba, entra en el modo de programación de pares o incluso estudia la posibilidad de reutilizar los casos de prueba existentes. Pero no hagas nada que limite este paso.
Toda tu reputación depende de lo bien que hayas probado el código antes de desplegarlo en producción. Debes probar cada pieza de código que hayas escribo. Punto.
¿Y si el código es "no comprobable"? El código está escrito de tal manera que es difÃcil de probar.
La respuesta corta es hacer que el código sea fácil de probar. Y la mejor manera de hacerlo es escribir tus pruebas antes de escribir el código que las aprueba.
Siempre recuerda que el propósito de tu código es conseguir que se ejecute para resolver un problema de negocio.
Tú como programador debes saber si tu código funciona. No hay nada más importante que este hecho fundamental.
Crear siempre un código flexible
Siri Hustvedt dijo: "La creatividad siempre ha dependido de la apertura y la flexibilidad, asà que esperemos más de ambos en el futuro."
Es la estructura de su código la que le permite ser flexible. Si comprometes la estructura, comprometes el futuro.
La suposición fundamental que subyace en todos los proyectos de software es que el software sea fácil de cambiar. Si te encuentras con que esto no es posible, entonces algo en alguna parte está seriamente mal.
Demasiados proyectos quedan atrapados en el pantano del código inflexible. Los desarrolladores van y vienen y añaden más al laberinto de código inflexible y finalmente terminamos creando un monstruo que no se puede reescribir ni mantener fácilmente.
La clave aquà es identificar aquellas partes del código que lo hacen inflexible. Una vez que encontramos esas partes, invertimos tiempo y esfuerzo y reescribimos esas partes en lugar de añadir más al lÃo ya creado. Este esfuerzo se hará en contra de los plazos. Pero que asà sea. Consigue la aceptación y haz lo correcto.
Sigue siempre el principio de "Refactorización despiadada". Deja el código limpio cuando lo dejes y si eso significa hacer algo "extra" de lo que te han dicho que hagas, hazlo.
Y por último, sé un estudiante siempre.
Anthony J. D'Angelo "Desarrolla una pasión por el aprendizaje. Si lo haces, nunca dejarás de crecer."
"Quiero hacer el curso de S4 HANA. Pero la empresa no lo paga"
"QuerÃa aprender los formularios de Webdynpro. Peo no puedo encontrar tiempo en mi apretada agenda"
"Quiero asistir a ese Codeathon. Pero se acerca el fin de semana".
Todas estas son excusas para no aprender. Tu carrera es tu responsabilidad. No es responsabilidad de tu empresa asegurarse de que tú seas comercializable. No es responsabilidad de tu empresa capacitarte, ni enviarte a conferencias, ni comprarte libros. Estas cosas son tu responsabilidad.
Como regla general, sigue la regla de las 40-20 horas cada semana. Las 40 horas de tiempo pertenecen a la empresa. Las 20 horas restantes te pertenecen, para tu propio aprendizaje. Haz tu semana en un mÃnimo de 60 horas por semana para imbuirte de una cultura de aprendizaje continuo dentro de ti.
Y 20 horas a la semana no es difÃcil. Si usas tu tiempo sabiamente; tiempo de viaje, hora de almuerzo, fines de semana, etc., encuentras mucho más tiempo disponible a tu disposición para ser utilizado solo para ti.
Recuerda siempre que el campo del software está en constante cambio y que es muy fácil convertirse en un dinosaurio obsoleto. Por lo tanto, si deseas mantenerte a la vanguardia de los tiempos y seguir siendo valioso, invierte en ti mismo y sigue aprendiendo.
Como Seema Openers dijo: "La auto-educación está abierta a todos, pero sólo la toman aquellos que se niegan a vivir una vida pequeña y sin sentido."
Adaptación del artÃculo original de Ravi Rajan en Medium: 5 Powerful Habits of Successful Developers.