You either die a startup, or live long enough to see yourself become a Java shop

¿Cuál es la tecnología más hot del momento? Pregúntaselo a una startup. Utilizar los lenguajes de programación de tendencia, bases de datos «no convencionales» y herramientas y metodologías que tratan de romper el status-quo no es solo parte natural de ser una nueva empresa con ideas frescas sino además estrategia para reclutamiento del mejor talento. Puede ser una bendición inicialmente y después… una maldición.

De como me he vuelto obsoleto cada 5 años

Cuando por primera vez tuve oportunidad de programar en una computadora en la secundaria con Turbo Pascal hace más de 20 años tuve sentimientos encontrados; por un lado la posibilidad de manipular la computadora me daba gran satisfacción pero por otra, el tener que entrar en «modo DOS» en un sistema operativo gráfico como era Windows 98 por aquel entonces me hacía sentir que algo andaba mal.

Cuando apenas tuve acceso a Internet desde mi propia computadora y trataba de entender estos otros lenguajes de los que sysadmins y hackers en IRC hablaban, como Perl y C, intenté aprenderlos, sin éxito. Un par de años después alguien me dijo que aprendiera esta cosa llamada «Python» porque era «muy fácil de aprender e iba a reemplazar algún día a Perl» y así lo hice; compré el libro de «Learning Python» de O’Reilly y puedo decir que fue mi primer acercamiento a la programación de verdad y las bases de mis conocimientos de orientación a objetos.

Curiosamente dejé de utilizar Python poco después puesto que fuera de algunas herramientas propias de Linux en ese tiempo, no había mucho uso del mismo, poco sabía que después sería uno de los lenguajes más importantes en la industria. Continué utilizando lo que en ese tiempo era lo que los demás utilizaban: Visual Basic. Si, a inicio de los 2000’s a pocas personas les interesaba desarrollar aplicaciones web, término que me atrevo a decir ni siquiera existía, la mayoría del desarrollo de software seguía centrado en aplicaciones gráficas de escritorio.

Pero en poco tiempo Visual Basic ya era cosa de los 90’s, lo de hoy era esta flamante tecnología de Microsoft llamada .NET y su nuevo lenguaje C# (o Java) que tuve que aprender por supuesto si deseaba integrarme al ámbito laboral. Cuando el desarrollo web me llegó por sorpresa naturalmente comencé a desarrollar cosas en ASP.Net con sus «webforms» ya obsoletas pues la espina dorsal de la web es HTTP que como sabemos es un concepto «stateless» que no hace sentido con dicha tecnología.

Para cuando comencé a estudiar ASP.Net MVC, Ruby on Rails ya era la tecnología web más cool del momento. Dado que tenía algo de experiencia anterior con PHP decidí enfocarme mejor en esta última, usando CodeIgniter que pronto se volvió obsoleto también hasta que me moví por necesidad, de nuevo, a Ruby On Rails el cual he disfrutado, sin embargo, y como cada 4-5 años me acabo de dar cuenta que esta es una tecnología ya en picada y que ahora los programadores cool desarrollan todo en JavaScript desde el backend, servicios, frontend y demás, de nuevo, me encuentro obsoleto. Y ni hablar de Rust, Elixir y amigos.

Motivaciones técnicas al inicio de un proyecto

La mayor parte de los startups de software son fundados por personas con bases técnicas, es decir, ingenieros y/o programadores, y como tales, utilizamos un criterio muy parcial hacia nuestra área donde decidimos utilizar la tecnología del momento porque claro, es la oportunidad perfecta para probar conceptos, metodologías y nuevas herramientas. Se suele dejar pues, el objetivo de negocio, en segundo plano o relegado a quien sea el CEO y los primeros inversionistas así que en realidad no hay nadie «supervisando» estas decisiones técnicas.

Más de una vez se decidirá usar algún lenguaje de moda, base de datos moderna o servicios «obscuros» que quizá no son realmente necesarios. Parte de ello puede ser una estrategia de atracción de talento. Como programadores, es normal aburrirse de la «vieja» tecnología y querer coquetear con las herramientas más nuevas, y si nos van a pagar por ello, mucho mejor.

Creo que es en pocos casos donde realmente el uso de lenguajes y stacks más modernos está justificado por alguna razón técnica. En algunos casos, algunas de estas tecnologías, incluso nacieron precisamente por la necesidad inherente de un proyecto o porque el enfoque de las herramientas actuales simplemente no da el ancho. Un buen ejemplo de ello son las bases de datos de cache como redis o memcached, pero, definitivamente, me atrevería a decir que más del 60% de los startups nuevos NO necesitan las herramientas más nuevas para solucionar el problema que desean solucionar o prestar el servicio que están intentando comercializar.

Fracaso o legado

Los startups son como los rockstars (los de la vieja escuela, hoy en día ya no existe tal cosa), es muy probable que mueran jóvenes, por razones ajenas a la tecnología. Pero en los casos donde estos logran superar digamos los primeros años de vida, es muy probable que se conviertan en un conjunto de problemas (técnicos) que nadie quiere resolver de los cuales nadie se quiere hacer cargo, «technical debt» le dicen.

Lo he visto en muchos de los proyectos en los que he estado involucrado. Cuando el producto ya tiene algunos años, lo primero que nuestros managers o technical leads nos dicen, con una especie de pena implícita, es «vas a encontrar cosas raras o mal hechas, pero las queremos arreglar eventualmente«.

Y ¿Por qué se repite el patrón antes mencionado? Muy simple, la mayoría de las veces, estos startups comenzaron con tecnología donde el expertise del equipo en ella era casi nulo, es decir, se utilizó un producto con objetivos claros de negocio como prototipo para aprender, un conejillo de indias, uno costoso y mal diseñado. Costoso porque probablemente al inicio de vida el equipo que lo desarrolló generaba un alto costo a la empresa pues eran programadores de esta cosa nueva que nadie conoce entonces la oferta es poca y la demanda alta. Y mal diseñado, si, porque quienes fueron precursores de este código tenían poca experiencia con esas herramientas, y, ¿Cómo culparlos?, ¿Cómo se puede ser experto y tener las mejores prácticas en una librería o framework que apenas tiene un par de años y que, como cualquier otro proyecto de software, comenzará poco maduro y probablemente con malas prácticas y errores? (hola AngularJS 1.x)

Para entonces, y cuando ya han transcurrido algunos años, el término que más asusta a VP’s de ingeniería, CTO’s y en general a quien tiene que pagar las cuentas, comienza a aparecerse como fantasma en cada junta técnica: Refactorizar.

Moverse a «pastos más verdes»

Para cuando deseáramos que nuestro equipo, que probablemente ya adquirió buena experiencia en estas herramientas, refactorice y mejore el código, es probable que más de la mitad de dicho equipo ya se haya largado de la empresa, dejando un costal de problemas y la deuda técnica de la que hemos hablado. ¿Documentación? No, eso no lo hacemos aquí, o bueno, no lo hacíamos. Así que hay que comenzar a echarse un clavado y tratar de entender el monstruo que creamos.

Por otra parte, y como sucedió anteriormente, nuestros programadores probablemente ya se aburrieron. ¿Recuerdan esa nueva tecnología emocionante y obscura? Bueno, pues ya no es tan obscura, es bastante clara, y por ende, aburrida. Este nuevo startup que ofrece utilizar esta otra nueva tecnología que es super-hot se ha llevado a nuestros programadores, y con un mejor salario, porque claro, recordemos que utilizar la nueva tecnología y la ley de la oferta y la demanda nos darán una ventaja como programadores.

Pero no todo es miel sobre hojuelas para el programador. Desafortunadamente muchas veces las habilidades desarrolladas no se venden tan bien como tener conocimiento en las nuevas tendencias y eso lo sabemos quienes nos dedicamos a esto, por ello, nuestra mejor apuesta es irnos moviendo, para no «quedarnos estancados», pero muchas veces eso significa casi comenzar de cero, lo cual es bastante agotador.

Producto VS Proyecto

Una vez que un startup deja de serlo y comienza a tener problemas más interesantes que decidirse por que framework de JavaScript utilizar para transpilar otro lenguaje obscuro, lo natural e inteligente sucede: quienes fueron probablemente los primeros ingenieros en la empresa o incluso hasta el CTO dejan de tener injerencia y relevancia en estas decisiones. Quienes se quedaron y decidieron no mudarse muy probablemente subieron en el escalafón y ahora su día a día consiste en interminables llamadas, juntas y hacerse experto en JIRA y el calendario y correo.

Pero esto de hecho no es algo negativo, por lo contrario, es signo de que las cosas van bien en el negocio y muy probablemente, después de tantos intentos fallidos de ese famoso refactor de código que realmente prometía solucionar todo menos cumplir con objetivos clave que beneficien al negocio (aumentar ventas, disminuir soporte, etc.), personas con más experiencia en la industria quizá tomen las riendas de las áreas de ingeniería; ahora la tecnología pasa a segundo plano, el objetivo principal es el negocio, la tecnología solo una herramienta más (entre una buena administración, finanzas sanas, procesos de RH etc.) para cumplir dichos objetivos.

Y dado que nuestra tecnología inicial solo sirvió como «playground» para ingenieros curiosos y la oferta de dichos programadores cada vez es menor, se decide lo inevitable: irse por lo seguro y comenzar a migrar a tecnologías más «tradicionales» (aburridas y de godínez), pero que tienen una alta oferta en el mercado y decenas de años de estabilidad y probadas por toda la industria. Esto naturalmente es muy atractivo para los stakeholders de nuestra empresa pues por fin podrán enfocar al equipo de ingeniería a resolver problemas reales. Ya no estamos en un «proyecto», sino somos parte de un producto.

¿Renovarse, morir o …emprender?

¿Es esto una queja personal? No, no lo es. ¿Me frustra esta tendencia? Por supuesto! Pero entiendo que es parte del mercado y de la industria. Las cosas en el mundo del software y en general de la tecnología se mueven bastante rápido. Que si dichas tendencias o cambios realmente mejoran o traen progreso a los productos finales es tema de otra conversación, pero ahí está, latente, el cambio.

Aunque a mi me encanta la tecnología y por supuesto también aprender nuevas cosas, se vuelve agotador tratar de estar al día con las tendencias pero sobre todo poder convertirse en un «experto» en algún área en particular pues para cuando lo hemos hecho, el valor de dicho conocimiento ya está depreciado. Es esa misma sensación de tener un auto nuevo; hay que disfrutarlo mucho los primeros meses porque cada día que pasa se vuelve más una carga que otra cosa.

¿Y que podemos hacer al respeto? Bueno, creo que eso depende de muchos factores. Por ejemplo, yo comencé mi carrera joven, y tengo casi 15 años trabajando en ello, pero ya tengo 35, y si bien mi curiosidad sigue latente, prefiero especializarme en algo y agregar valor a mi carrera que pueda seguir aplicando mientras pueda ser útil como trabajador. Honestamente no me visualizo re-aprendiendo herramientas nuevas por los siguientes 15 para solucionar exactamente los mismos problemas, me parece ya tedioso, pero sobre todo, una actividad sin propósito.

Por ello, creo que aquí lo que hay que definir es nuestro plan de carrera, que puedo dividir en 3 posibilidades:

• Escalar posiciones. Si, lo natural. Llegará un momento en que probablemente no vamos a tirar una sola línea de código sino que nuestras responsabilidades pasarán a ser, invariablemente, administrativas. Aun debemos mantenernos al día con los conceptos, pero alguien más hará la implementación. Si no nos molesta vivir entre juntas, correos y design sprints, esta es la mejor opción. Desarrollar habilidades sociales y humanas nos da más valor en estos puestos, y esas no cambian cada dos años.
• Especializarse en un nicho. Si bien es cierto que la idea es seguir progresando en conocimiento técnico, siempre existirán empresas con deuda técnica o proyectos interesantes que quizá no utilizan la tecnología más nueva pero que necesitan a alguien especializado en algún área donde nosotros ya tenemos mucha experiencia. Pasar de ser generalista a un consultor especializado. Todo el tiempo existen ofertas para gente con conocimiento profundo de Oracle, SAP, JAVA, seguridad y otras tecnologías muy específicas y quienes las usan están regularmente dispuestos a pagar bien y en forma.
• Emprender! Que probablemente sea mi favorita. Tratar de resolver un problema de manera diferente u ofrecer un servicio a un mercado de nicho aplicando tecnología, es decir, crear un producto. Vender nuestro conocimiento, que se vuelve obsoleto cada 5 años, es una labor de nunca acabar. Crear una empresa puede no ser para todos, pero el objetivo cambia completamente hacia uno con enfoque de negocio donde podemos aplicar tecnología como medio y no como el fin.

Enfocarnos en alguna estrategia que nos permita seguir siendo relevantes y sobre todo productivos es necesario conforme avanza nuestra carrera. Seguirán habiendo empresas dispuestas a arriesgar sus productos en base a decisiones tecnológicas y programadores de nuevas generaciones que continúen este juego del «gato y el ratón» entre dichas tendencias.

Para quienes ya tenemos más años en la industria, es más atractivo el desarrollo de habilidades que nos permitan administrar y diseñar mejores flujos de trabajo para estas nuevas generaciones. Al final, será una de las cosas más demandadas en el futuro, y estoy seguro, mejor valoradas y por ende pagadas.