Table of Contents
Seguimos con nuestra serie de entrevistas ( anteriormente habíamos entrevistado a Diego Ojeda – Android Lead en Apiumhub y Serhii Zabolennyi – QA Automation engineer en Apiumhub ) y hoy tenemos una entrevista de Backend con Javier Gomez – backend developer en Apiumhub.
En esta entrevista Javier da consejos para los desarrolladores junior que esperan crecer profesionalmente como desarrollador backend y comparte su estilo de programación, sus libros favoritos y cómo se enfrenta a los imprevistos como desarrollador backend.
Entrevista con Javier Gomez – Desarrollador Backend en Apiumhub
¿Qué consejo le darías a los desarrolladores junior que esperan crecer profesionalmente como desarrolladores backend?
La vida profesional poco tiene que ver con lo que te enseñan en la universidad.
En sus primeros años, yo le recomendaría que no tuviera aspiraciones salariales. El mercado actual está al alza, y ves chicos que recién salidos de la carrera, empiezan con un buen contrato, un buen salario a final de mes. El problema de algunos de estos contratos, es que es para algo muy específico, monótono a veces, y con poco desarrollo o crecimiento profesional, pero el atractivo salario a final de mes te retiene y acaba por cortar tu crecimiento.
Yo recomiendo que en los primeros años de carrera profesional, sus aspiraciones sean rodearse de los mejores profesionales posibles, se ponga a su lado y se empape de su conocimiento.
Es tentador encontrar de primeras un contrato muy alto, porque el mercado está en contínua inflación, pero le recomendaría no centrarse en eso, por ahora. Si encuentra un buen lugar donde apuesten por su crecimiento profesional aunque gane menos que en otra empresa, le invitaría a considerar y apostar por esa alternativa. Ese dinero que estaría dejando de ganar, lo estaría invirtiendo en su crecimiento profesional. Y eso, al final, es una inversión que le ayudará a llegar más lejos el día de mañana, tanto profesional como económicamente.
Otra recomendación sería que no se acomode en el primer trabajo que encuentre, que pruebe cosas diferentes, para poder decidir qué es lo que realmente le guste y le apasione.
Y al final de todo, que no pierda la ambición de crecimiento, que no tenga miedo a salir de la zona de confort, que viva allí tanto tiempo como sea posible, hasta que forme parte de su día a día profesional. Esto te da una agilidad y una capacidad de pivotar en cualquier momento, ya sea de lenguaje, paradigma o arquitectura, por el bien de la solución que necesita el cliente. Y esto, es un valor añadido en un desarrollador.
Vivir dentro de la zona de confort es un indicador de que no estás haciendo bien las cosas, que no estás progresando. Por eso le recomiendo que viva fuera de ella, al principio es duro, pero cuanto antes empiece, antes formará parte de su día a día, y aprenderá a gestionarlo, sacándole todo el valor posible a esa situación.
En definitiva, Never Stop Growing.
¿Cómo tratas con lo inesperado como desarrollador backend?
Forma parte del día a día, tienes que asumirlo. Tanto el producto como el mercado al que está destinado es algo en contínua evolución, hay que ser conscientes de ello. No se puede partir de la premisa que los requerimientos son inamovibles, y no es así. Nuestro código tiene que ser lo suficientemente flexible como para poder evolucionar de manera rápida y sin riesgo. Para ello, intento basarme en las técnicas de clean code y los principios SOLID. No es una garantía de que un cambio de requerimiento no te implique rehacer completamente una porción del código, pero te ayuda a minimizar el impacto de esas variaciones de producto.
¿Cómo describirías tu estilo de programación?
Pragmático, pero basándome en las buenas prácticas siempre. Siempre hay que adaptarse a las necesidades del problema, y el purismo nos limita mucho. Eso sí, hay líneas innegociables, escoger las técnicas adecuadas de testing basándonos en la pirámide, aplicar los principios del clean code, para que nuestro código tenga la mejor calidad posible. E intentar siempre llevar el lenguaje de negocio a nuestro código, basándome en el Domain Driven Design.
Al final el rigor purista te quita flexibilidad, capacidad de adaptación a los problemas del mundo real. A lo que nos dedicamos es a proporcionar soluciones a problemas reales de nuestros clientes, el estilo de programación es la técnica que utilizamos, y las buenas prácticas nuestras herramientas, se requiere de conocimiento para tener capacidad de decisión sobre cuales usar y cuándo.
Por eso me gusta pensar que tengo un estilo pragmático y aplico las técnicas necesarias en cada momento, sin añadir boilerplate.
¿Tienes algunos libros o autores favoritos?
Sí, he leído algunos libros, no es algo que me apasione, pero lo hago por mi formación personal. Y de entre todos ellos, he encontrado algunos que me han sido muy fáciles de seguir y me han aportado mucho valor. Me gustaría destacar:
- Clean Code y Clean Architecture (Robert C. Martin): Respecto al clean code, sienta unas bases de buenas prácticas elementales para el día a día de cualquier programador. Te ayudará a cuestionar cómo haces las cosas y si puedes hacerlas mejor, enseñándote muchas técnicas y en qué contexto conviene aplicarlas. El clean architecture, es una iteración del primero, donde lleva las buenas prácticas al nivel de arquitectura del software. Es muy similar al primero, pero la iteración que plantea, es muy interesante para ir un paso más allá en la calidad de nuestro software, puesto que no se basa simplemente en el diseño de nuestro código, si no también de toda nuestra aplicación.
- DDD Distilled (Vaughn Vernon): Como su nombre indica, es una versión destilada de su otro libro (Implementing Domain Driven Design) y es una puerta de entrada ideal al propio DDD. Acercar nuestro código al negocio, tiene muchísimas ventajas, además de hablar el mismo lenguaje de negocio (Ubiquitous Language), nos ayuda a estructurar nuestro repositorio de la misma manera que se estructura el producto que estamos modelando. Este libro es perfecto para entender que és, y nos aporta muchísimas técnicas para llevarlo a cabo. Teniendo siempre la posibilidad de recurrir al libro original en caso de querer profundizar en algunos de los temas que podemos ver en esta versión destilada.
- TDD By Example (Kent Beck): El testing es una herramienta fundamental para el desarrollo de software. El TDD es una de las técnicas de desarrollo de software más conocidas que te permite elaborar el mínimo código necesario con calidad mediante test, que a su vez nos aporta información sobre lo que debe y lo que no debe hacer nuestro código productivo. Al principio puede parecernos una pérdida de tiempo, o que aporta poco valor respecto al esfuerzo que supone aplicar esta técnica. Con este libro podemos ver las bondades del TDD, donde iremos de menos a más de una manera fácil de comprender, con muchísimos ejemplos y pudiendo poner en práctica lo que nos habla el libro desde un primer momento. Yo recomiendo encarecidamente darle una oportunidad a este libro, cambiará la manera de pensar de muchos acerca de la importancia del testing y de esta técnica de desarrollo en concreto, el TDD.
