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.

La clave está en cortar finito: Slicing

La clave está en cortar finito: Slicing

Uno de los desafíos de mi proyecto actual está en lograr un entregable de valor en pocas semanas y la clave para lograr eso es poder cortar las funcionalidades bien “finitas”, lo que en la jerga agile suele denominarse slicing.

El tema con el slicing es que no es fácil de hacerlo y en ocasiones se lleva a cabo de forma inapropiada por no involucrar a todos los perfiles necesarios. En este sentido, para poder hacer un buen slicing es necesario:

  • Gente de negocio que conozca perfectamente el negocio y particularmente el subdominio de la aplicación en desarrollo
  • Gente técnica que sea capaz de entender las funcionalidades y pueda dimensionarlas en términos de complejidad y costo de implementación.
  • Gente con poder de decisión

La falta de cualquiera de estos tres grupos resulta riesgoso ya que uno podría terminar generando un incremento funcionalmente pequeño pero técnicamente demasiado grande o un incremento técnicamente manejable pero sin valor de negocio o incluso un incremente pequeño, tanto funcional como técnicamente, pero sin apoyo “respaldo político” para su realización.

¿Cuál es el valor de la intermediación en servicios de TI?

El sujeto A requiere un servicio/producto.

El sujeto B lo ofrece.

El sujeto C hace de intermediario, básicamente contacta A conB. Este sujeto C está intermediando, en cierto modo el negocio se produce gracias a él. Entonces ¿cuál es el valor de su servicio?

Estas situaciones son cada vez más frecuentes. Un ícono es Mercado Libre, pero hoy en día hay N ejemplos análogos: AirBnb, Uber, Globo, entre otros. El costo de intermediación como también el alcance del servicio que brinda el intermediario varía de un caso a otro.

Pero esta situación también ocurre fuera de la plataformas y es muy común en la provisión de servicios de TI. A mi personalmente me pasa muy seguido con mi actividad profesional. Una empresa A contacta a una empresa B para la provisión de un servicio. La empresa B no tiene la capacidad de brindar el servicio entonces me contacta a mi. En general yo termino haciendo el trabajo en forma solitaria, prácticamente sin apoyo ni intervención de la empresa B.

La empresa A abona un valor X por el servicio que yo brindo y la empresa B se lleva una tajada por haber traído el cliente y por algún costo de operación ¿Cuánto debería ser esa tajada de la empresa B?

Yo me he encontrado con distintas situaciones pero en términos simplificados hay dos extremos:

  • La empresa B (llamemosla tipo 1) que pretende asegurar una rentabilidad R en todo lo que factura. En este caso toma mi presupuesto y le aplica un % extra para cumplir con su expectativa de rentabilidad sin mayor cuestionamiento.
  • La empresa B (llamemosla tipo 2) que tiene su negocio propio negocio que no pasa por la intermediación y no le interesa asegurar una rentabilidad de un trabajo en el que no participa. En este caso la empresa sale del medio dejando a las partes transaccionar en forma directa o bien permanece dentro de la transacción pero aplicando un % que representa los costos operativos sin ninguna expectativa de rentabilidad adicional.

A todo esto se agrega un situación interesante. Luego de haber hecho un delivery exitoso, la empresa A me contacta en forma directa para otro proyecto. O sea: la empresa A no llama a la empresa B sino que me llama a mi, NicoPaez. Yo por una cuestión de “lealtad comercial”, hago participe a la empresa B de la nueva propuesta. Y aquí se dan dos situaciones:

  • Si la empresa B es de tipo 2, en general me dice: “te llamaron a vos, es tuyo
  • Si la empresa B es de tipo 1, toma el proyecto en sus manos y acciona de su forma habitual: me pregunta cuánto quiero y le agrega un porcentaje para asegurar su rentabilidad. Luego deja que yo me encargue por completo del delivery del proyecto.

Hasta el momento yo siempre he pasado mi presupuesto y dejado que la empresa B aplique el markup que guste, pero es algo que ya hace un tiempo me estoy replanteando porque al dejar que la empresa B establezca el libremente su % de rentabilidad se corre el riesgo de perder el proyecto por ser muy caro. Al mismo tiempo dado que estamos hablando de negocios entre empresas, si la empresa A está dispuesta a pagar X, yo que hago el delivery y asumo los riesgos quiero llevarme la mayor parte posible de ese X (e incluso sacar del medio a la empresa B si no está agregando valor).

Me gustaría leer opiniones, ya sea que se hayan encontrado con situaciones así o no.

Notas sobre los IDEs para .Net Core

Notas sobre los IDEs para .Net Core

En breve estoy empezando a trabajar en un nuevo proyecto con .Net. Es mi vuelta a tecnología .Net luego de casi 3 años. Pero una diferencia relevante respecto de mi último proyecto es que en este caso utilizaremos .Net Core. En mi proyecto anterior utilicé .Net Framework 4.6 y dado que yo “vivo en MacOS” utilicé una máquina virtual con Windows 7 y Visual Studio 2017, lo cual anduvo muy bien. En este caso, dado que .Net Core corre nativamente en MacOS estoy apostando a esa posibilidad. Para esto instalé .Net Core y estuve probando distintas alternativas de IDE.

Precisamente el tema del IDE es una de las novedades más importante del mundo .Net. Tradicionalmente trabajar con .Net implicaba casi irremediablemente utilizar Visual Studio, porque si bien había algunas otras alternativas, ninguna estaba lo suficientemente estable o contaba con las funcionalidades necesarias para el desarrollo profesional. Con la salida de .Net Core y la iniciativa de Omnisharp, hoy en día es posible elegir entre varias alternativas.

Lo primero que probé fue utilizar Visual Studio Code que tiene un plugin para .Net/C#. La experiencia está bastante lograda, es posible correr los tests y debuggearlos desde dentro VSCode. También ofrece soporte para algunos refactors. Con el agregado de algunos otros plugins y la combinación con el dotnet-cli es una alternativamente perfectamente válida. Pero no quise quedarme ahí así que continúe probando.

Lo segundo que probé fue Visual Studio para Mac, la prueba fue corta pues me resultó muy incómodo ya que es distinto al tradicional Visual Studio de Windows y me sentí desorientado. Da la sensación que quisieron adaptar el Visual Studio a ciertas cuestiones de UI/UX de MacOS y el resultado para mi no fue bueno.

Mi tercera prueba fue con Rider, el IDE de JetBrains. Desde hace bastante tiempo cuando trabajo con Java uso el IDE de JetBrains (IntelliJ) con lo cual tenía que probar Rider. Y no me defraudó, la experiencia me resultó muy buena ya que a nivel IDE es casi como trabajar con IntelliJ y la integración con las herramientas .Net está muy bien lograda.

Aún tengo que hacer algunas pruebas para ver el soporte y la integración con algunos frameworks/herramientas de desarrollo (specflow por ejemplo) pero en principio estaré entre Rider y VSCode.

Conferencias & Convocatorias 2020 – Primer semestre

Conferencias & Convocatorias 2020 – Primer semestre

Ya están abiertas las convocatorias para presentaciones/artículos para varias conferencias tanto industriales como académicas y varias tienen deadlines en breve.

Dentro del ámbito de industria está abierto el CFP de Agile 2020, la conferencia anual de la Agile Alliance en USA. Este año la conferencia será en Orlando del 20 al 24 de julio. Un punto interesante de este CFP es que si uno envía su propuesta antes del 5 de Febrero uno puede obtener feedback formal para mejorar su propuesta antes del envió final cuya fecha límite es el 9 de febrero. Este mecanismo ya está vigente desde hace un par de años y a mi personalmente me resultó muy valioso.

También dentro del ámbito industrial está abierto el CFP de NDC Oslo, la nueva versión de la original Norway Developer Conference, una conferencia dedicada principalmente a programadores de la industria. Hace ya un par de años y dada su popularidad, la Norway Developer Conference (NDC) fue renombrada a New Developer Conference y pasó de hacer exclusivamente en Noruega (Oslo) a hacerse en diversas partes del mundo. Es así que hoy en día hay NDC en diversas ciudades del mundo (Oslo, Londres, Sydney, etc). La fecha límite para envío de propuestas para Oslo es el 15 de febrero.

A mitad de camino entre industria y academia está la XP que tiene varios CFP, algunos académicos y otros de industria. Este año la XP se realiza en Copenhagen, Dinamarca del 8 al 12 de Junio. La fecha límite para el envío de trabajos de investigación es el 29 de febrero, mientras que la correspondiente para sesiones de industria & practica es el 5 de febrero.

Dentro de ámbito académico abrió hace unos días el CFP de ARGENCON, la conferencia bianual de IEEE Argentina . Esta edición 2020 se realizará en UTN Resistencia, Chaco del 24 al 26 de junio. La fecha límite para el envió de trabajos es el 15 de marzo.