Hace mucho que no escribo y en esta ocasión sentí ganas de plasmar algunas cuestiones que he aprendido durante el ejercicio de mi carrera profesional, con el fin de ayudar a aquellos que se están iniciando en el mundo de la ingeniería de software y, por qué no, a quienes quieren pulir algunos aspectos de su perfil profesional. Si bien el título indica que el artículo está orientado programadores, algunos puntos son igualmente aplicables para otros trabajadores del sector IT y en general dentro del mundo corporativo. Consideren también esta lectura como un trabajo en progreso, por lo que la iré actualizando a lo largo del tiempo.

Para que la lectura sea más amena y organizada, voy a desarrollar el tema en diferentes temas, desde los más básicos hasta los más específicos.

❌ No sé inglés/no me interesa aprender inglés/no me gusta programar en inglés

Deberías aprender. Debería interesarte. Está bien que no te guste pero deberías aceptarlo. El inglés es la lingua franca en el mundo de los negocios, no sólo en el sector tecnológico. Gran parte de la mejor documentación de cualquier disciplina está escrita en inglés, lo cual no implica que haya sido escrita por nativos ingleses. Es muy probable que la empresa que te contrate tenga clientes norteamericanos, europeos, australianos, asiáticos, etc. Si bien suena obvio, el punto importante que quiero destacar es que también es altamente probable que el idioma que elijan para comunicarse sea el inglés. Si tu objetivo es desarrollar un plan de carrera adentro de esa ú otra empresa en un futuro, vas a necesitar contar con un grado aceptable de fluidez en inglés hablado y escrito; quizá no si tu techo es ser senior developer, pero con total seguridad si tu sueño es ocupar un cargo de manager. Desde luego que no es algo que se pueda lograr en un par de días o años, sino que requiere tiempo considerable de aprendizaje y práctica, ya que es todo un idioma nuevo el que debemos aprender, y vamos a necesitar lograr cierto dominio para poder comunicar nuestras ideas con la mayor claridad y fluidez posible.

Sumado a lo anterior, programar utilizando el idioma inglés para los definir todo aquello que no es un constructo del lenguaje, como variables y nombres de clases entre otros, no sólo que facilita la lectura del código debido a que estamos interpretando todo el conjunto en un único idioma, sino que además dota de profesionalismo e interés manifiesto a tu código. Deberías trabajar siempre con la idea de que algún día la empresa en cuestión comenzará a contratar programadores de otras regiones, si es que aún no ha sucedido, quienes como hemos descrito antes, muy probablemente se comuniquen y trabajen en inglés. Y desde un punto de vista estrictamente técnico, utilizar el mismo lenguaje en tu código es un aspecto clave para lograr un grado de ubicuidad aceptable en el mismo.

❌ Nunca usé GIT / uso GIT pero tengo conflictos todo el tiempo

GIT es una herramienta muy poderosa. Sin embargo puede resultar difícil comprender su funcionamiento durante el primer tiempo de uso: para algunos serán meses, para otros serán años. Su dificultad radica en que GIT es, en esencia, un sistema distribuido y descentralizado, y es común que sistemas de este tipo parezcan demasiado complejos para el usuario promedio, más aún si a eso le sumamos su propósito elemental, que es controlar versiones. Sin embargo, son muy pocas las empresas que hoy en día no usan GIT para versionar su código (y otras tareas). En la mayoría de los casos también el único que se verá perjudicado por no contar con un dominio mínimo de la herramienta serás tú, debido a que casi todas las empesas cuentan con esquemas de integración y despliegue configurados para impedir que un error se propague hasta la versión de producción, incluyendo configuración para forzar sus buenas prácticas como feature branching (o trunk-based development), code reviews, procesos de análisis estatico y ejecución de tests.

Lo importante es que entiendas que GIT es tu amigo, y cuando aprendas a utilizarlo te va a traer más soluciones que problemas. GIT es como una máquina del tiempo para tu código, con acceso a múltiples dimensiones y todo. Algo que me ha servido a dar un gran salto cognitivo fue indagar cómo funciona GIT por dentro, y qué es lo que cambia cada vez que se crea un branch y un commit. Por ejemplo, esta charla de Edward Thomson me ha ayudado a organizar un poco mejor las ideas.

Y como nota personal te digo que cuando tengas la oportunidad de trabajar en un repositorio enlazado con un esquema de integración y despliegue continuos (CI/CD), te vas a sentir muy, muy poderoso. Desde luego, ese poder trae consigo una gran responsabilidad.

✅ Saber indagar

Antes de preguntar, puedes (y debes) recurrir a las herramientas que están a tu disposición. ¿Hay documentación? Léela. ¿El proyecto está en control de versiones? Revisa el historial de versiones para entender quién, cuándo y cómo aplicó una solución. ¿Tienes internet? Googlea. Demuestra tu capacidad de resolución; sin embargo si el problema es específico del dominio de negocio y no has encontrado precedentes, pregunta.

❌ Si tengo una duda, no pregunto

Haces mal, ya que las personas que tienen más experiencia que tú, seguramente hayan pasado por lo que estás pasando en este momento, por lo que un problema que te lleve una semana resolverlo, con la ayuda de tus compañeros tal vez lo podrías resolver en una tarde o en un par de horas. Esto no significa que todos tus compañeros estén a vuestra merced para hacer el trabajo por tí, sino que tendrás que tener criterio suficiente para saber y aprender a quién preguntarle un aspecto puntual y en qué momento hacerlo.

❌ Siempre pregunto todo

No, ¡no hagas eso! Así como no preguntar nada resulta impráctico para los objetivos del proyecto, preguntar todo es una muy, muy mala costumbre. Pone de manifiesto que no tienes el seniority necesario para el puesto que estás ocupando. Hoy en día la gran mayoría de empresas buscan profesionales que sepan y quieran adueñarse del proyecto en el que trabajen (ownership). Esto implica, entre otras cosas, que logres alistarte dentro del tiempo esperado (el proceso de onboarding) para poder comenzar a mejorar el producto, así como demostrar interés en conocerlo lo mejor posible, y compartir este conocimiento cuando es necesario.

Algunos métodos que me han sido utilidad (y que no son para nada revolucionarios) son anotar toda información considero relevante, y si esta información no tiene carácter confidencial y puede ser compartida con el resto del equipo, crear una página en la base de conocimiento de la empresa (wiki) con dicha información. De esta forma estaré ayudando a mis actuales y futuros compañeros y miembros del proyecto, así como a mi yo del futuro.

✅ Saber preguntar

Cuando tengas un problema, asegúrate de saber a quién preguntarle, y sé breve y conciso, no envíes 20 mensajes para desarrollar tu tema, ya que estarás forzando a la otra persona a permanecer a la espera de tu idea completa, o en un peor caso, te ignorará por un par de horas. Envía un único mensaje que incluya tu saludo, el motivo de tu contacto, explica tu problema, los enfoques que has intentado y los errores que has obtenido (el error, no el stack trace completo, tómate el trabajo de leer los logs, estimad@…).

✅ Saber reportar

Es parte de tu día a día. Deberás reportar a tus jefes y compañeros. En el mundo de los negocios el tiempo es dinero y se valorará tu capacidad de sinopsis. Al igual que en el punto anterior, se breve: saluda, comenta en lo que estás trabajando, cuándo crees que lo tendrás listo y si tuviste algún inconveniente, en qué consiste el mismo y nuevamente las soluciones que has probado y a quiénes recurriste para avanzar en el tema.

❌ No sé qué son los patrones de diseño

Deberías. Te ayudarán a resolver muchos problemas comunes que ya han sido estudiados. De hecho en eso consiste la noción de patrón de diseño: un método (probado) para resolver un problema recurrente. En ocasiones uno tiene que lidiar con problemas medianamente o altamente complejos y cae en la desgracia de reinventar la rueda, no por voluntad propia sino por desconocimiento. Échale una leída al catálogo de Martin Fowler, y consulta otros de los miles de recursos disponibles en la web.

No es necesario que los conozcas de memoria pero sí que tengas una noción de que existen y que allí estarán, esperándote, para cuando los necesites.

❌ No sé qué son los antipatrones de diseño

Es importante saber que así como existen patrones también existen los antipatrones. Al igual que en el punto anterior, es bueno conocerlos, al menos saber de su existencia, de modo que si en algún momento te topas con una implementación claramente inviable o incluso con algún problema en la gestión del proyecto, puedas recurrir a ellos para comprender mejor qué está sucediendo y cómo remediarlo. Aquí una sinopsis de algunos antipatrones de desarrollo, aunque también recomiendo le eches un vistazo a los arquitectónicos y a los de gestión de proyectos.

✅ Buscar nuevos conocimientos cada día

La ingeniería de software es una disciplina compleja y competitiva. Y no sólo eso, sino que en muchas ocasiones puede resultar avasallante el gran volumen de metodologías, lenguajes y herramientas nuevas. A veces uno puede sentir que nunca va a terminar de incorporar los conocimientos necesarios para estar al nivel del mercado.

Resulta difícil poder abarcar la totalidad de plataformas, lenguajes y prácticas existentes. Es por ello que lo más común es encontrar profesionales con experiencia en uno o unos pocos stacks tecnológicos. De esta forma la meta de volverse senior, al menos en una galaxia dentro del universo tecnológico, se vuelve alcanzable.

• Desarrollador
• Programador
• Profesional
• Experiencia