/ insights

Ser experto no te salva la vida

Las empresas cuentan con un aprecio por los tan llamados expertos, aquellas personas que dedican años de su vida a trabajar con una sola cosa o un set de trabajo limitado, en su mayoría, no por elección, si no porque deben trabajar con ellos

No me gustaría decir que son malos, hay mucha gente talentosa que se encuentra en este grupo de desarrolladores, sin embargo, creo que no es parte de la naturaleza de una persona que se dedica a la tecnología

Aprender otras tecnologías, nuevos frameworks, distinas arquitecturas, son muchas veces vistas como algo innecesario y una pérdida de tiempo para las empresas, usualmente piensan lo siguiente:

  • No nos dedicamos a eso
  • Si las integramos a algún proyecto, no tendremos quién brinde el mantenimiento

Siendo justos, desde el punto de vista de negocio.. Hace sentido, pero aún así, deberíamos considerar el factor de ganancia, ya sea, un desarrollo más rápido, mejora en el performance, etc.

De cualquier forma, aprender no debe tener un objetivo de retorno de ganancia como motivo principal, el interés que existe en un desarrollador, debería ser el motor que impulse la necesidad por buscar nuevas soluciones y enfrentarse a nuevos retos

Considero que tener proyectos personales, incluso sin finalizar, o como algunos dicen reinventando la rueda, si tiene un valor profesional, porque al final, aprender un nuevo patrón, lo uses o no directamente en tu trabajo, traerá ventajas para resolver algún problema que parezca difícil dentro del universo de conocimiento en ese campo

Algunos ejemplos personales (que son en función de mi empleo actual):

  • En la empresa en la que trabajo, no utilizamos python para nada, sin embargo, he utilizado esta tecnología para crear scripts que modifican tamaños de imágenes, mandar requests a través de HTTP como prueba de integración, inyección de requests para load test en un servidor
  • Por mandato del framework que utilizamos, debo usar jQuery en el frontend, esto no quiere decir que no haga JS orientado a objetos con JS puro, de hecho, lo aprendí precisamente para mejorar el desarrollo, también aprendí Polymer para entender el concepto de Web Components y component based development, aprendí Angular (para entender que personalmente no me agrada), de ahí experimenté VueJS y se me hizo familiar a Polymer, encontré sus bondades muy ventajosas, pero al final (y después de haberme negado demasiado) entré al mundo de React y entendí porqué es el framework de preferencia de muchos en la comunidad de JS. Créanlo o no, el manejo del state con redux, me ayudó a estructurar una solución de backend sumamente limpia para el caso de negocio que teníamos en ese momento
  • Aprendí NodeJS, aquí aprendí la arquitectura de OAuth, la estrategia de JWT (JSON Web Token), el valor de stateless y como este facilitaba las pruebas unitarias en componentes como servicios, DAOs y otros conceptos que pertenecen al desarrollo que realizo con Java

Esto quiere decir que, si, efectivamente experimentar con otras tecnologías no me ha dado ninguna mejora en mi desarrollo con Java directamente, sin embargo, me ha enseñado el porque a veces ciertas tecnologías o frameworks están diseñados de esa forma y un uso real en base a los problemas que he enfrentado en mi empleo, saliendo de la solución cocinada por el framework con el que trabajo por cualquier inconveniente que este tenga (performance, mantenibilidad, escalabiliad)