El dilema de dónde estudiar informática, algunas cuestiones a considerar

El dilema de dónde estudiar informática, algunas cuestiones a considerar

En la época en que inicié mis estudios universitarios todavía estaba vigente la creencia de que un estudio universitario “aseguraba un futuro”. Con lo cual si uno tenia la posibilidad económica y las ganas de hacerlo, solo había que decir qué estudiar. Al mismo tiempo en aquella época (fines de los ’90) internet no era lo que hoy y el acceso a la información era mucho más acotado. Hoy en día las cosas han cambiado mucho, comenzando por el hecho de que ya es claro qué hacer una carrera universitaria no asegura un futuro.

En en el caso particular de la informática hoy en día existen muchas opciones de estudio tanto dentro como fuera de la universidad. Intentaré resumir algunas de las opciones en forma simplificada.

Dentro de la educación universitaria hay un conjunto interesante de opciones que no existían cuando yo comencé a estudiar. En este punto me refiero concretamente a carreras universitarias cortas: diplomaturas y tecnicaturas como las que ofrece la Universidad Nacional de Quilmes. Son carreras cortas de 2 o 3 años que representan una opción rápida (en comparación con las carreras tradicionales) para la inserción laboral.

Fuera de la educación universitaria hay dos subgrupos: la educación no universitaria formal y la informal. Con educación no universitaria formal me refiero a carreras terciarias que tienen el aval/regulación del estado. Un caso de esto son las tecnicaturas superiores que ofrecen los Institutos Superiores de Formación Docente y Técnica.

En cuanto a la educación informal tenemos una variada oferta que incluye cursos presenciales, como los que ofrecen IT College, Digital House y Educación IT y cursos online, como los disponibles en Acamica y Coursera. Algunas de estas instituciones ofrecen incluso algunos cursos en modalidad mixta de clases online y encuentros presenciales. Estos tupo

Para cerrar esta enumeración vuelvo al comienzo: las carreras universitarias tradicionales de informática. Ingenierías y licenciaturas, carreras largas, de 4 o 5 años en los papeles pero más cerca de los 7 u 8 años en la práctica. Incluso dentro de esta opción hay varios caminos, uno típico de polémica es universidad pública o universidad privada.

Personalmente no creo que haya una opción mejor que otra, es simplemente una cuestión de expectativas y necesidades. Lo que me parece interesante e importante es que hay muchas opciones y la profesión está en ascenso. Al mismo tiempo es importante tener presente que el estudio es un primer paso que no está necesariamente relacionado al desempeño profesional. He trabajado con excelentes profesionales de diversa formación, algunos de ellos nunca completaron un estudio formal.

Insisto en que es una cuestión de expectativas, lo cual no es un tema menor. Si lo que pretendemos es hacer apps para iPhone, no me parece que sea imprescindible hacer una carrera universitaria larga. Pero si lo que buscamos es hacer aplicaciones de tiempo real tal vez sea distinto.

Cada una de las opciones de estudio habilita un conjunto de potenciales oportunidades. Un ejemplo concreto: conozco de empresas que para determinados puestos solo contratan personas con título de ingeniero y solo de determinas universidades. Tal vez este tipo de políticas cambie a futuro, pero no estoy tan seguro. De todas formas, si a uno no le interesa trabajar en empresas con esas políticas, no tiene de qué preocuparse. Ojo, con esto no estoy diciendo que sea mejor estudiar ingeniería, sino que lo importante es tener en claro las expectativas de cada uno y elegir en base a eso.

El curioso incidente del Scrum Master y el merge a master

El curioso incidente del Scrum Master y el merge a master

Estábamos arrancando con el setup del proyecto y nos enteramos que el área arquitectura definió que el único que puede aprobar los merge-requests a master es el Maintainer. Curiosamente arquitectura asignó el rol de Maintainer en nuestro proyecto al Scrum Master, el único miembro del equipo (junto con el PO) que no codea, ¡ooops!

Ayer comenté esto en twitter y generó varias reacciones.

Lo que me incomoda de esta situación no es el hecho de quién puede aprobar los merge-request sino el hecho de que alguien externo al equipo defina cómo debe trabajar el equipo. Entiendo que haya ciertos lineamientos generales en cuestiones que puedan tener impacto fuera del equipo, pero cuestiones como el esquema de branching creo que no es una de esas cuestiones.

Al mismo tiempo quiero destacar que si bien recién estamos comenzando con el proyecto, la persona en el rol de Scrum Master me cae muy bien, creo que está haciendo un buen trabajo y si bien actualmente no codea lo hizo en el pasado.

Otra curiosidad es que en los lineamientos de arquitectura se asume en cierto modo que el equipo utilizará branches y merge-request, cuando en realidad la intención de nuestro equipo es hacer trunk-based development trabajando de pares para todo código productivo.

En fin, como conozco a uno de los referentes de arquitectura y me parece una persona bastante criteriosa y accesible lo llamé por teléfono para comentarle esta situación. Me explicó algo razonable: solo una persona por equipo tiene el permiso Maintainer y cuando se creo el proyecto el único miembro del equipo de desarrollo que estaba confirmado era el Scrum Master. Adicionalmente me explicó que lo que hizo arquitectura no fue establecer “reglas de piedra” sino lineamientos generales que surgieron del diálogo con diversos referentes de la organización y que pueden revisarse en cada caso particular. Esto también me resultó muy razonable. Más aún me parece muy sano cuando uno comienza un proyecto no se encuentre con la nada misma, está bueno tener algunos lineamientos que luego uno pueda debatir y eventualmente ajustar.

Cerrando la historia pinta que el equipo trabajará sobre un branch develop y luego en la salida a producción haremos el trámite de merge-master.

Nuevo proyecto, nuevos desafíos

Nuevo proyecto, nuevos desafíos

Esta semana estoy arrancando formalmente un nuevo proyecto. La semana pasada hicimos el descubrimiento de producto y como parte del mismo identificamos objetivos de negocio y métricas para medir el éxito. También definimos algunas cuestiones de estrategia tanto técnica como de negocio.

Entre los desafíos del proyecto hay algunas cuestiones que me parece relevante mencionar:

  1. Un equipo de desarrollo distribuido en 2 ciudades y conformado por personas de 4 organizaciones distintas.
  2. El uso de un conjunto de tecnologías de desarrollo (.net core y angular) en las que la mayoría del equipo no tiene experiencia.
  3. El uso de una infraestructura de ejecución (docker y kubernetes) en la que la mayoría del equipo no tiene experiencia.
  4. La necesidad de generar un entregable de valor en un tiempo máximo de 6 semanas.
  5. La integración con una aplicación legacy.
  6. Requerimientos concretos de accesibilidad.
  7. El uso de ciertas prácticas de desarrollo de cara a intentar asegurar la calidad del entregable (continuous delivery, test-automation, infra as code, etc)

Mi participación en el proyecto tiene que ver principalmente con ayudar en los puntos 2, 3 y 7.

Como parte del trabajo de discovery (que duró 3 días) generamos también algunos acuerdos de trabajo:

  • Trabajaremos en iteraciones de 2 semanas
  • El jueves será el día de las ceremonias de planning/review/retro
  • La daily standup será 9.30
  • El trabajo lo organizaremos en Jira
  • Para la comunicación diaria utilizaremos Microsoft Teams
  • Para el código utilizaremos GitLab
  • Jenkins será nuestro Build Server

Me gusta mucho que la daily sea tempranito pero no me gustan tanto las iteraciones de 2 semanas, sinceramente prefiero iteraciones de 1 semana, pero en bueno, es algo con lo que puedo vivir.

A medida que el proyecto vaya avanzando iré compartiendo novedades en este espacio.