La hora de JavaScript, a tomarlo en serio

Para muchos de mi generación, los que empezamos a programar en la web 1.0 allá por fines de los ’90 comienzos de 2000, Javascript nunca fue «algo serio». En general uno no aspiraba a ser programador JavaScript. Uno podía definirse como programador de un lenguaje en particular: Java, Php, Visual Basic, C++, etc. y en todo caso si era necesario tiraba algunas líneas de JavaScript.

Claramente los tiempos han cambiando y también JavaScript. Y en un punto las cosas se han pasado de rosca, ahora tenemos gente que directamente se define como «programadores de un framework basado en JavaScript» (react developer, angular developer, etc.) y lamento decir que he visto algunos de estos programadores que apenas si dominan JavaScript y no tienen ni idea de la diferencia en JavaScript y ECMAScript. Ojo, no pretendo hacer un juicio de valor sobre esto, tal vez pueda resultar conveniente saber de React sin tener demasiada idea de JavaScript con el fin de manejar un mayor nivel de abstracción y bajar la carga cognitiva.

En fin, hoy en día JavaScript como lenguaje está en un estado, a mi parecer, bastante maduro. Sin embargo creo que el ecosistema JavaScript aún está medio inestable. Todo el tiempo están saliendo nuevas librerías/frameworks/componentes para resolver cuestiones recurrentes. Es así que a la hora de resolver una problemática hay varias opciones de componentes/frameworks. Esto puede parecer positivo pero es también un arma de doble filo. Cuando un programador experimentado se enfrenta a varias opciones es precisamente su experiencia una cuestión central para elegir la opción a utilizar. Pero ocurre que en el mundo JavaScript hay mucho programador sin demasiada experiencia y en esos casos el tener varias opciones puede resultar más riesgoso. Cuando digo «mucho programador sin experiencia», lo digo en términos comparativos con otros lenguajes. Cuando vemos la oferta de bootcamps y cursos de programación para gente que se está iniciando en esta disciplina, vemos que la gran mayoría en la actualidad están relacionados a JavaScript y tecnologías de frontend en general.

Al margen de todo lo anterior, hoy en día tenemos herramientas JavaScript para construir interfaces de usuario web (angular, react, vue), aplicaciones móbiles (react native, flutter), y aplicaciones/servicios server-side (nodejs). Esto hace que empiece a sonar muy atractivo tener JavaScript como lenguaje de cabecera, ya que parece esta por todos lados. Sin embargo no hay que tomar esto a la ligera porque si bien estamos hablando del mismo lenguaje de programación, cada escenario implica un stack de frameworks y herramientas distintos. Personalmente, por mucho tiempo no le di mayor importancia a JavaScript y siempre que me lo cruzaba, veía puntualmente de resolver la cuestión inmediata que tenía entre manos sin profundizar demasiado. Pero ya desde hace un tiempo he comenzado a tomarlo más seriamente, estudiándolo más en profundidad.

El Equipo Quirúrgico

(en idioma original «The Surgical Team«) Este es el título de uno de los artículos del clásico libro de Fred Brooks The Mythical Man-Month. A diferencia de otros artículos de ese libro, como The Mythical Man-Month y No Silver Bullet, este artículo no ha cobrado tanta fama pero eso no significa que sea menos genial.

En este artículo Fred Brooks desarrolla una idea previamente esbozada por Harlan Mills: resulta conveniente que los proyectos de software sean desarrollados por equipos pequeños de no más de 10 personas. Al mismo tiempo esos equipos deberían estar organizados como un equipo quirúrgico, eso es: opera una sola persona, el cirujano, que es asistido por un conjunto de especialistas (anestesista, instrumentista, etc, etc). Llevado esto al desarrollo de software, se propone que todo el diseño, desarrollo e implementación lo haga una única persona: el programador jefe (cirujano). Este programador es asistido por un conjunto de especialistas (tester, admin, toolsmith, etc).

Una versión actualizada de esta propuesta (tengamos presente que la propuesta inicial es de los ’70), podría tener un Senior Developer / Architect en el lugar del cirujano, asistido por un tester, un especialista en frontend, un especialista en backend, un dba, un sysadmin, un especialista UX, etc.

En muchos contextos esta idea puede resultar muy polémica pero al mismo tiempo en algunos otros contextos puede tener mucho sentido. Más aún, si a esta idea de cómo organizar un equipo la extrapolamos a nivel organización terminaremos con una propuesta del estilo de Team Topologies donde los equipos de producto (stream-aligned teams) toman todas las decisiones asistidos por otros equipos de especialistas (platform & enabling teams).

No deja de resultar curioso como algunas de ideas del siglo pasado vuelven a tomar vigencia luego de ser olvidadas por generaciones.

Experimento: universidad abierta 2021

El año pasado hicimos el experimento de permitir que gente externa a la universidad curse nuestra materia Ingeniería de Software en UNTreF. Quedamos muy satisfecho con el resultado y por eso este año hemos decidido repetir la experiencia. Entonces la cuestión es así:

¿Te interesa aprender un enfoque adaptativo, moderno y práctico de Ingeniería de Software?

Si la respuesta es sí, entonces considera las siguientes cuestiones:

  • La materia tiene una duración calendario de 16 semanas, comenzando en Agosto
  • Las clases se dictan los días miércoles de 18 a 22 hs (obviamente de forma online)
  • Adicionalmente a la clases se requiere una dedicación continua de alrededor de 6 horas semanales
  • Hay teoría (videos, lecturas) y también mucha práctica de programación
  • Trabajamos con tecnologías actuales como Ruby, Docker, Heroku, GitLab, etc.
  • Este artículo describe formalmente la dinámica de la materia
  • Aquí puedes encontrar varios artículos sobre el dictado de la materia en cuatrimestres anteriores

Quienes serían buenos candidatxs para participar:

  • Gente está actualmente trabajando en desarrollo de software y tiene al menos 3 años de experiencia, ya que en la materia hay una parte importante de programación pero no enseñamos a programar
  • Gente que tiene conocimiento y experiencia en desarrollo web, patrones de diseño y diseño de software en general
  • Gente que estudio algo de informática a nivel universitario pero no completó la carrera
  • Gente que completó sus estudios universitarios de informática hace un par de años pero que estudió un enfoque «tradicional» de ingeniería de software, muy teórico, posiblemente «cascadoso» y distante de la práctica de industria

Si bien no es absolutamente necesario haber tenido un paso por la universidad para participar de esta iniciativa, creemos que es un punto importante dado el nivel de exigencia. O sea, esto es un materia del último año de la carrera de Ingeniería en Computación y no hacemos distinción entre quienes cursan como parte de la carrera y la gente externa a la universidad que viene solo a tomar este curso. Un detalle no menor, esto es completamente gratuito, los participantes no deben abonar abonar absolutamente nada (en cierto modo el costo del curso ya lo está pagando el estado Argentino)

Bien, si luego de haber considerado todo lo mencionado en las líneas anteriores aún estás interesado en participar te invito a que completes este formulario contando un poco sobre ti y porque te interesaría cursar la materia, nos estaremos comunicando contigo en los próximos días.

Cambio de rumbo: de proyecto a producto

Luego de 20 años trabajando en la industria de servicios de software he decidido un cambio de rumbo a mi carrera. Prácticamente toda mi carrera he estado trabajando construyendo software o brindando consultoría/capacitación para terceros. Aproximadamente la mitad de mi carrera lo hice lo trabajando en software factories y la otra mitad trabajando de forma independiente. Si bien tuve un breve paso por Microsoft (que es una empresa de producto) mi tareas allí estaban mas relacionadas a cuestiones de asesoramiento técnico y no tenía casi ningún contacto con los equipos que desarrollaban los productos.

Desde hace unos años empezó a resultarme atractiva la idea de trabajar en una empresa de producto. Personalmente creo que trabajar en un producto tiene ciertas particularidades/implicancias en lo que refiere a ingeniería de software. Al mismo tiempo me resulta muy atractiva la idea de poder proponer cambios en el producto, poder implementarlos y ver en el corto plazo los impactos de esos cambios en el negocio.

Cuando digo empresa de producto me refiero a una empresa cuyo negocio pasa por ofrecer un producto de software o un servicio basado en producto en un producto de software. Es una definición muy amplia en la que pueden entrar organizaciones financieras (como Paypal, Mercado Pagos, Banco Nación, etc), empresas de video juegos (como EA Sport y Blizzard) y redes sociales (como LinkedIn y Facebook). Básicamente lo que no entra en esta categoría «de empresa de producto» son las empresas de consultoría y/o desarrollo( como Globant y Accenture).

A comienzos de este año empecé a explorar oportunidades en empresas de producto a las cuales sumarme en un esquema part-time. El hecho de buscar una posición part-time tiene que ver principalmente con el hecho de que tengo la intención de continuar trabajando en la universidad. Empecé por ver las búsquedas activas de ciertas empresas que me resultaban interesantes tanto por su producto como por su cultura. Si bien encontré varias posiciones posibles, todas ellas eran full-time.

Finalmente, hace poco más de un mes vi pasar un publicación en LinkedIn de una empresa que conocía, cuyo producto yo había usado un par de veces y que gente de su equipo había participado de alguno de mis cursos. No tenía idea de la cultura de la empresa, pero sabía que el producto estaba sólidamente establecido y a mi parecer con un gran potencial de crecimiento. Así que decidí postularme.

Desde entonces venimos teniendo conversaciones para definir cómo darle forma a mi incorporación. Tengo sensaciones encontradas, por un lado estoy entusiasmado con poder trabajar en este producto pero al mismo tiempo me cuesta acostumbrarme a la idea de «abandonar mi kiosquito». O sea, en cierto modo yo tengo mi propio negocio que viene funcionando completamente a mi gusto desde hace años y eso no es algo fácil de dejar.

En fin, las conversaciones van avanzando y seguramente en las próximas semanas tendré novedades para compartir.