Consejos y el camino del desarrollador de software

Esta es una grabación de la charla denominada «Consejos y el camino del desarrollador de software» en el cual intento explicar lo más imparcialmente posible como funciona la carrera típica de desarrollador de software, tipos de desarrollador por función, niveles -i.e junior, mid, senior, architect- asi como algunas consideraciones de lo que he visto en estos 10 años.

Como de costumbre los slides se encuentran en Slideshare:

Me contagié de COVID y esto aprendí mientras me recuperaba

Un pingüino enfermo

Si tuviera que describir lo que pasé en una frase seria «el COVID se siente como correr una maratón con mascarilla luego de que Mike Tyson te golpeara durante 10 días seguidos«.

Diferente de lo que muchas personas piensan, la enfermedad es muy real, y el sentimiento de asfixia te hace pensar que esa podría ser tu última noche y en mi caso moriría solo. Mi caso fue catalogado como moderado en la escala de 1-asintomático, 2-leve, 3-moderado y 4-severo.

Mi objetivo con este post es escribir mi experiencia para recordar en unos años como sobreviví, lo que sufrí, las cosas que aprendí y como gracias a Dios y al seguimiento del doctor Pedro Artero, salí adelante.

¿Que pienso de los que niegan la enfermedad o la minimizan?

Doña chonita

Están bien imbéciles.

El COVID es una enfermedad que mal tratada te puede matar en 14 días. Nadie es imprescindible en un trabajo, si no cuidas tu salud y mueres ten por seguro que tu jefe simplemente te reemplazara, no hay trabajo que valga el riesgo de morir sin despedirte de los tuyos.

No es una gripona y tampoco es una enfermedad inventada, es una enfermedad que en casos moderados-severos te va a llevar a una neumonía en menos de una semana.

Un caso moderado en realidad no significa que no vas a sentir nada, más bien significa que no necesitaste oxigeno de forma artificial, pero no por esto dejan de ser malos. La clave según lo que viví es tratarse lo más rápido posible.

¿Mi perfil y como me contagié?

Tux

A pesar de que no tengo un perfil «atlético» me considero alguien saludable. Realizaba al menos 12 viajes por año (muchos como mochilero), sin diabetes, hipertensión, obesidad, me ejercitaba regularmente antes de la pandemía, no comía mucha comida chatarra y trabajo desde casa. Logré llegar hasta los 100 días de encierro sin mayores sobresaltos pero cometí un único error: Salir por alimentos.

Dado que salia una vez a cada 15 días tengo bastante claro en mi línea de tiempo que me contagié en uno de estos dos lugares:

El supermercado o en la salida a la tienda de mi cuadra por un helado.

Debo decir que siempre salí con mascarilla pero como sugiere la evidencia nueva en Nature, el COVID seguramente también se transmite por aire y en estas dos ocasiones no usé un respirador N95 porque se me habían acabado.

¿Que cosas aprendí de este proceso?

  • La gente con diabetes e hipertensión es especialmente sensible a la enfermedad y el motivo es básicamente que tu corazón y pulmones trabajan bajo muchísima más presión de lo que comúnmente lo hacen mientras tu cuerpo lucha contra el COVID. No es una sentencia de muerte pero no debe tomarse a la ligera.
  • La toma de temperatura en la entrada a locales será básicamente una perdida de tiempo. Los días que tuve fiebre alta fueron pocos en comparación a los días de la enfermedad, incluso enfermo pasaba sin inconvenientes esos controles cuando iba a hacerme exámenes.
  • Ninguna medida es extrema, hasta este momento no se como me contagié pero si se que ademas de la mascarilla pude haber ido con careta y tal vez no estuviera escribiendo este post.
  • Que un caso sea moderado no es que uno se dedique a ver Netflix y descansar tranqui con un libro. Solo significa que no te pusieron oxigeno y la linea es delgada hacia un caso severo.
  • La clave es recibir tratamiento y seguimiento rápido. Por eso Guatemala fracasará contra el COVID, la cobertura en salud es inexistente.
  • La mayoría de pruebas que se anuncian en la tele son probablemente de centros privados, ni para eso sirve el gobierno. El día que me hice la prueba el centro donde la realicé hizo casi 100 pruebas.
  • En un caso moderado de COVID el tratamiento (termometro, oximetro, anti inflamatorios, antibiótico, vitaminas, rayos X, prueba de sangre, ferritina, prueba de COVID) alcanza fácil los Q 3000 ($ 400). Es «poco» frente a otras enfermedades, pero para algunas personas sera la diferencia entre vivir o morir ante la ausencia del estado. Es bueno contar con una linea de crédito mínima o ahorros si te da COVID.

Síntomas y línea de tiempo de los 15 días de crisis

La caída de Tux

Poco menos de una semana después de ir al super, mi línea de tiempo fue la siguiente:

Día 1

Empecé con un dolor de cabeza extraño, soy una persona que no padece migrañas y de la nada sentí dolor de cabeza y un poco de debilidad. Una aspirina y a dormir.

Día 2

El dolor de cabeza continuaba, pero pasado el medio día me empecé a sentir muy mal y débil. Arranca la fiebre (37.9) que esa noche-madrugada llego a (38.6), con nauseas, dolor en todo el cuerpo. Diferente de una gripe normal, la fiebre llegó inmediatamente y fue aquí que supe que esto podía ser COVID.

Día 3

Luego de consultar con el doctor, me sugirió iniciar tratamiento preventivo con antiinflamatorios y antivirales, así como tratar de bajar mi fiebre. El doctor también me sugirió hacerme una prueba de sangre para buscar indicios o descartar COVID y tuve que ir por ella en moto ya que en Guatemala hay restricciones de circulación de vehículos, mis resultados demorarían dos días por la alta demanda en Guatemala. Nunca había manejado moto en este estado y debo decir que fue en lo mínimo, interesante.

Día 4

No fue un día muy diferente, febricula todo el día, falta de apetito y los antiinflamatorios empezaban a ayudarme junto con medicina para bajar la fiebre. Este día perdí el sentido del olfato.

Día 5 y 6

Empezaba a sentirme «mejor» pero me seguía poniendo cada vez más débil, luego de llamar como 10 veces a la linea del gobierno de Guatemala para el COVID y no obtener ninguna respuesta sabia que tenia que salir de esto por mi cuenta, la verdad no se ni porqué llame, el gobierno en mi país solo existe para robar.

Este día y siguiendo indicaciones médicas, cerré todas mis redes sociales, salir del COVID también es un proceso mental y no me ayudaba en nada leer noticias que si me llegaba a agravar tenia dos opciones: 1-Morir porque ya no hay hospitales públicos disponibles o 2- endeudarme por poco más de un cuarto millón de quetzales ($30,000) en un hospital privado.

Luego de ver mis exámenes de sangre el doctor me sugirió hacerme una prueba de COVID que no pude conseguir por medios públicos (porque simplemente no hay) y tuve que acudir a un centro privado pagando poco menos de $50 y hacer fila todo el día porque la crisis es real.

Acá descubrí que probablemente 50% o más de los resultados que el gobierno anuncia por sus medios son en realidad análisis en centros privados, todos están saturados.

Día 7

Este fue el peor día. Terminé el tratamiento preventivo de antiinflamatorios y llegó el resultado positivo para COVID-19.

El doctor me indicó que afortunadamente ya había iniciado el tratamiento y me indicó que debía monitorear constantemente mis signos vitales, especialmente oxigenación y temperatura.

Poco antes de intentar dormir la presión en el pecho empezó a aumentar y sentía una asfixia horrible, el aire me empezó a faltar y ya solo podía pensar que si necesitaban hospitalizarme no sabia que hacer, vivo solo y no sabia como pedir ayuda. Mi novia estuvo pendiente de mi toda la madrugada y la orden del doctor fue hacerme más exámenes inmediatamente.

Día 8

La falta de aire y presión en el pecho ya es constante y aumenta, en los rayos X efectivamente se empieza a ver la inflamación en los pulmones y empieza una neumonía por COVID por lo que es momento de iniciar un segundo tratamiento más agresivo basado en antibióticos y esperar que mi cuerpo reaccione.

Acá es importante señalar que es conveniente tener un oximetro ya que la sensación de asfixia se siente aunque no bajes de 90% de oxigenación, el número clave para decidir si te deben internar.

El «tratamiento» del COVID es ayudar al cuerpo contra los síntomas y esperar lo mejor.

Día 9, 10 y 11

De estos días sinceramente no recuerdo mucho, básicamente me concentraba en no morir. Cualquier esfuerzo mínimo me dejaba sin aire, cualquier posición para dormir era incomoda y tenia mucho sueño. Trataba de dormir, ver TV y pensar en cosas positivas. Las constantes fueron dolor de cabeza, diarrea, dolor de cuerpo, debilidad. Nunca me había enfermado así.

Estos son los días claves para saber si alguien necesitara ser hospitalizado y muchas personas buscan ayuda hasta este punto.

Día 12

Este día fue más o menos igual que los anteriores, solo que por fin empece a sentir que podía respirar un poco más, estas son buenas noticias.

Día 13, 14 y 15

Continué recuperando la respiración de a poquitos, cada día me siento un poco mejor y debo extremar medidas para cuidar mi salud. Finalmente paso de tratamiento con antibiótico a tratamiento con vitaminas.

La debilidad continua y perdí poco más de 10 libras, pero voy a vivir para contarlo.

Recomendaciones si te da COVID

A partir de esta experiencia mis recomendaciones serian las siguientes:

  • Mantener la calma: El angustiarse con el proceso agrava el sentimiento de asfixia y la mente es poderosa, especialmente en sentirse mal. Yo suelo ser una persona muy «realista» pero el distraerme ayudó en mi proceso para no caer en un hospital.
  • Comprar a tiempo un termometró y un oximetro: Serán los instrumentos vitales para un tratamiento en casa.
  • Definir una red de soporte y «cut the bullshit«: Lo que menos necesitas es gente cuestionandote, burlandose e incomodandote con sus preguntas o porqué no tomaste precauciones. Necesitaras una red de soporte para la alimentación, búsqueda de medicinas, especialmente porque las mismas están escasas (Guatemala tu nombre inmortal).
  • Apoyarte en la telemedicina: Ya sea que tengas un médico de cabecera o no, un paso previo es definir quien te dará seguimiento. Todos los tratamientos son experimentales en este punto y solo tratan la sintomatologia. Es vital contar con el seguimiento de un médico y no bancarse la enfermedad como una gripe normal. Un dato curioso es que el centro donde uno se realiza la prueba (CIAM en mi caso) te da una llamada gratis de seguimiento y también te hace SPAM para que puedas «adquirir» las teleconsultas con ellos.
  • Come frutas y verduras: Tu cuerpo va a necesitar mucha «gasolina» para salir de esto, nunca había comido tanta fruta en mi vida en tan poco tiempo pero fue necesario para salir.

Mi #MovedbyJava con fotos hasta 2020

En 2020 Java cumple 25 años, para celebrar el equipo de Oracle promovió el hashtag #MovedbyJava, mediante el cual las personas puedan compartir como Java ha impactado sus carreras e incluso sus vidas.

Mi jornada va más o menos así:

2006 – ¿Como aprendí Java?

Como estudiante de la Universidad de San Carlos llegué a la universidad en un periodo de cambio, donde el Ingeniero Armin Mazariegos reformó el pensum y cambió los lenguajes con los que se enseñaba en los cursos, promoviendo Java y .net como plataformas.

Los labs de la India, en su forma actual y con las compus de cuando aprendi Java 😅

Aunque la decisión le valió muchas criticas, lo cierto es que también consiguió un acuerdo con la embajada de India en Guatemala, específicamente para instalar el India-Guatemala IT Centre of Excellence conocidos como los laboratorios de la India.

En estos laboratorios tuve la oportunidad de recibir aproximadamente un año de capacitación con Java 5 y J2EE, las capacitaciones fueron exigentes a nivel de certificación. Con 18 años no sabia para que me serviría todo eso pero era divertido.

Hasta la fecha opino que el proyecto a nivel de números fue un fracaso, ya que a pesar de que la universidad es la más grande del país, los cursos originales (con instructores de India) los llevábamos en grupos pequeños de no más de 15 personas porque eran en ingles y fuera de horarios de clases. Una pena.

2006-2009 La comunidad de software libre

Mi tiempo libre durante la universidad lo invertía en comunidades de software libre, específicamente de Linux, en esta época Sun Microsystems era vista como una empresa benévola, y amiga del software libre, por lo que todos nos alegramos cuando liberaron el código de Java bajo GPL.

Entre otras cosas, varias personas iniciamos el Open Source University Meetup, una especie de grupo donde se promovían tecnologías abiertas como Java, Open Solaris y MySQL, todas en ese entonces bajo el brazo de Sun MicroSystems.

En esa época nos enviaban freebies:

2009-2011 – Mis primeros trabajos en Java

Aunque en la universidad experimenté muchos más lenguajes y plataformas (especialmente QT, Python y Ruby) lo cierto es que difícilmente hubiera encontrado trabajo con herramientas libres de no ser por Java.

El mundo de TI hoy en día no es el mismo que hace algunos años. Antes de la revolución de lenguajes y la apertura de transnacionales, en Guatemala era raro encontrar trabajo en algún lenguaje que no fuera parte de .net, de hecho solo conocí a una persona en la universidad que trabajaba en Java, mis tres primeros trabajos en Java fueron

  • Desarrollador freelance: Para la procuradoria de derechos humanos en Guatemala, acá tenían un sistema que era una mezcla de JSP, Struts y Faces
  • Desarrollador freelance: Para OpenTraining. Aca hice mucho desarrollo usando Struts, Faces y Linux :).
  • Desarrollador (y posteriormente Arquitecto) Java en Mobilges: En su tiempo la empresa se llamaba Soluciones Estrategicas, fue acá donde conocí Java en todas sus variantes ya que realizamos proyectos con J2ME (sobre BlackBerry), Java EE 5, Java SE 6 y 7. Hasta la fecha recuerdo con mucha estima este trabajo porque me permitió desarrollar mi potencial y NO ME OBLIGARON JAMAS A USAR TRAJE o camisa formal.
Frente del Case
Teletran 1, mi primer PC comprada con Java

2010 – GuateJUG

El grupo de usuarios Java de Guatemala -GuateJUG- es probablemente uno de los más antiguos en Centro América que aun siguen vigentes, a pesar de que inició en el 2007 en 2010 tuvo su «reinicio» al cual me uní para colaborar. Originalmente colaboraba solo como administración de sistemas, paginas y repositorios, pero el involucrarme en sus actividades cambió el rumbo de mi carrera:

Logo hecho por informaticos en 2010

2012-2014 – Mi beca en Brasil

El involucrarme en Open Source y difusión de conocimiento me abrió las puertas para vivir en Brasil. En este periodo de tiempo me dediqué a la investigación pura en ciencias de la computación y me aleje de Java para caer en . . . Scala, realmente nunca salí de la JVM.

Entre otras cosas pude presentar y asistir al Forum Internacional de Software Livre que en ese entonces era la segunda mayor conferencia de Software Libre en America Latina, acá entendí cual era el valor del networking y de las comunidades de software:

También acá conocí personas importantes de la comunidad Java que me ayudarían en los años venideros.

2014-2020 La comunidad Java Global

Luego de regresar a Guatemala y conocer a la comunidad global Java, poco antes del mundial de Brasil inicie a trabajar en Nabenik, originalmente nació como una empresa para brindar consultorías puntuales y ha ido creciendo a su propio ritmo.

Acá, también tuve la oportunidad de ir a mi primer Java One en Estados Unidos 2015. Recibí sponsorship de Oracle para el ingreso al evento en un programa de apoyo a los Java User Groups.

Lo más importante de conferencias como Java One no son las charlas (que de igual forma son de alto nivel) sino la calidad de networking que uno puede hacer en estos eventos. Por mi parte recibí apoyo de Nabenik para los costos del viaje y yo pagué algunos costos adicionales, la mejor inversión que he hecho en mi carrera hasta este momento.

En este punto conocí también a los integrantes de jespañol, con los cuales hemos hecho varias actividades en conjunto para promover Java en América Latina.

Luego de muchas actividades, certificaciones, viajes, clientes y un proyecto junto a GuateJUG con el cual recorrimos Guatemala enseñando Java, el vino a casa:

Mr, Duke, el mejor porta audifonos

Y eventualmente también esto pasó:

¿Fue mala idea aprender Java?, ni por un instante.

Le debo mucho a la comunidad Java por lo que ¡Vamos por los proximos 25 años!

Protegiendo aplicaciones con Payara Fish, MicroProfile JWT y OWASP Top 10

Esta es la grabación de una charla cuyo titulo original es «Seguridad en aplicaciones Java 101» aunque su enfoque (al menos en demo) es como proteger aplicaciones utilizando el OWASP Top 10

Durante la charla se explora la fundamentación teórica de la seguridad en Java y nos enfocamos en el OWASP Top Ten para Jakarta EE

Posteriormente hacemos una demostración de MicroProfile JWT con Payara Application Server

Por último explicamos como funciona un generador de Tokens JWT con acceso a los realms de usuarios en Payara Application Server

Como de costumbre, los slides se encuentran disponibles en Slideshare

El código fuente se encuentra disponible en GitHub

Introducción a Kotlin para Desarrolladores Java

El siguiente vídeo es la grabación en vivo de parte del workshop denominado «Introducción a Kotlin para Desarrolladores Java» como parte de los meetups del grupo de usuarios Java de Nicaragua

Durante la charla se explora Kotlin como un lenguaje de programación desde el punto de vista del desarrollador Java, ventajas, desventajas asi como bloques y expresiones propias del lenguaje.

Como de costumbre, la presentación se encuentra disponible en slideshare.

De Java 8 para Java 14 PT-BR

PT-BR: O vídeo é uma gravação raw da palestra apresentada no meetup online do SouJava. Na conversa a gente percorre algumas das mudanças mais importantes na linguagem Java desde Java 8 ate Java 14. Fazendo uma discussão de como diversos aplicativos Java podem ser atualizados e as vantagens da atualização.

Java 14 en acción

ES: Este video es el resultado de una presentación en SouJava acerca de las actualizaciones en el lenguaje de programación Java desde Java 8 hasta Java 14, el vídeo como tal está en portugues pero no tengo blog en portugues para compartirlos :). De cualquier forma esta charla cuenta con una versión en español.

OpenSolaris 2008.11, como era programar/aprender Java poco antes de la muerte de Sun MicroSystems

Como probablemente han notado en otros post, tengo una pequeña colección de computadoras antiguas que mantengo como hobbie, dándole uso ocasional a alguna de ellas y otras que solo las mantengo como reto.

Mi laptop más antigua es una computadora single core Celeron M de 32 bits con 1GB de RAM y 60 GB de disco duro. Para la época que mi papá me la regaló era una computadora de mediano porte (ya que las laptops no eran tan ubicuas), pero complementaba bien mi computadora Pentium 4 de 32 bits single core. Con estas dos computadoras inicié y finalicé la universidad.

Continue reading →

Desarrollando aplicaciones empresariales y web con ECMA 6 y TypeScript

El siguiente vídeo es la grabación en vivo de parte del workshop denominado «Desarrollando aplicaciones empresariales con ECMA 6 y TypeScript» como parte de las jornadas de actualización CEDUCA del colegio de ingenieros de Guatemala.

Durante la charla se explora el funcionamiento de JavaScript, ECMAScript 6 y TypeScript

Como de costumbre, la presentación se encuentra disponible en slideshare.

Una auditoria rápida al app Alerta Guate

El día de hoy noté en redes sociales que varias personas le tenían miedo al app de Alerta Guate, la cual el Gobierno de Guatemala designó como la app oficial de comunicaciones con la población de Guatemala en tiempo de COVID-19, argumentando que era un app Israelí y tuvo apoyo de Google.

Al inicio creí que muchas de estas afirmaciones tenían demasiado tinte político, sin embargo lo que puedo hacer «de mi lado» es analizar los factores tecnológicos.

Mi objetivo bajo ningún motivo es demeritar o apoyar el trabajo del gobierno, ni unirme a alguna corriente ideológica. Creo firmemente que la tecnología es un medio que hay que utilizar cuando sea necesario, especialmente en crisis como las que estamos atravesando. Pero también creo que una aplicación de tipo gubernamental debe tener siempre la auditoria social mínima.

Permisos

La aplicación está diseñada para requerir los siguientes permisos:

Por si mismos la cantidad de permisos no es algo preocupante, ya que Android ha tenido la tendencia en los últimos años a volver los permisos más granulares. Lo único que me parece molesto en la aplicación es la insistencia para garantizar el permiso de «Do not disturb» lo cual en otras palabras significa que aunque coloquemos nuestro teléfono en modo no molestar, esta aplicación en particular nos dará las notificaciones. Similar a como se comporta Android Auto.

Como relata el screenshot de twitter el app efectivamente tiene acceso a:

  • Obtener ubicación
  • Grabar audio
  • Utilizar las apps de telefono
  • Acceder al almacenamiento

La única que me parece realmente preocupante es el acceso que tiene al almacenamiento ya que desconozco el objetivo para el cual tiene este permiso, de hecho en las nuevas versiones de Android ustedes mismos pueden denegar individualmente esos permisos, LO CUAL RECOMIENDO ENCARECIDAMENTE como en cualquier otra App de Android, por ejemplo en Android 9:

Comunicaciones

Al parecer la aplicación permitirá llamar directamente a servicios de emergencia y recibir comunicaciones mediante distintas vías, para esto utiliza como biblioteca de comunicaciones Twilio.

El gobierno anunció que la aplicación estará lista hoy por la noche (24 de marzo) por lo que aun no tiene backend, si monitoreamos los intentos de comunicación que realiza la aplicación, los mismos van hacia la API:

https://api.in-telligent.com

API a la cual se comunica Alerta Guate

La cual efectivamente coincide con el fabricante anunciado en Google Play:

La empresa que hizo el app

Si vemos los datos del fabricante, al parecer es una empresa dedicada a crear aplicaciones de alerta, pero de todos los países solo la app de Guatemala tiene un logo «diferente y oficial»:

Creería que el modelo de negocio de la empresa es brindar soluciones de uso gratuito, esperando a recibir soporte del gobierno y dar alertas con publicidad. Lo cual no es necesariamente malo, alguien tiene que pagar la infraestructura.

Creería que el único gobierno que lo ha hecho oficial es el gobierno de Guatemala. Como referencia, así se ve la aplicación en versión México, donde el banner en la parte inferior es un banner típico de apps de publicidad.

Acerca de la empresa

Luego de confirmar la empresa, traté de indagar un poco más al respecto, tanto en Crunchbase como en Twitter se presentan como una empresa estadounidense:

Si buscamos la empresa en LinkedIn, la mayoria de sus empleados están en Estados Unidos:

No encontré mayores referencias a una empresa Israelí como relatado por el presidente, tal vez fue un error de comunicación y el mensaje era «un contacto Israelí nos facilitó el uso de esta app con la empresa X».

Términos de uso (edit)

Al utilizar las apps de In-telligent, los usuarios se comprometen entre otras cosas a lo siguiente, de acuerdo a su website y en traducción libre:

  • Solo se encuentra disponible para mayores de 18 años
  • Estar de acuerdo con que la empresa recolecte información personal, identificable y vinculable con el usuario
  • La geolocalización tambien es identificable y vinculable al usuario
  • La información se utilizara para proveer información y también ofertas
  • La información se puede compartir con terceros para fines publicitarios

Conclusiones

  1. Como en cualquier otra aplicación Android, el usuario que decida utilizar el app deberá estar consciente de los permisos que otorga
  2. Seria interesante analizar el código del app pero estoy 100% seguro que eso es ilegal y no lo intentare 😁
  3. Por si solo el modelo de negocio de la aplicación no es malo, en un mundo ideal todos los gobiernos tienen un sistema de alerta publico y tecnológico a través de apps, sms, teléfono, etc.. Pero esté momento de la historia es de lejos todo lo contrario a un mundo ideal. Me gustaría que en los hackatones que seguramente se realizaran en estos días se pudiera brindar una alternativa real, de código abierto y sobre todo que garantice que los datos se quedan en Guatemala, crítica con propuesta decía uno de mis profesores.
  4. Sinceramente más que el App, me preocupa que digan que es una app Israelí, espero que haya sido una confusión menor al respecto.
  5. Personalmente seguiré informándome vía Facebook con los «Giammatei Direct» y en la radio. No tengo los elementos suficientes para descartar el uso de la app de gobierno si se usa con permisos mínimos y consciente de que nuestros datos se compartirán con una API de terceros con fines comerciales.
  6. Tampoco tengo los elementos suficientes para confirmar que es una app Israelí, al menos no en la información publica disponible en internet.

Discutiendo las diferencias entre programador Junior, Mid, Senior y Arquitecto de Software

Un programador Junior con 50 años de experiencia

Una de mis motivaciones para escribir este post es que he visto dos tendencias tanto al contratar personas como al ser contratado por personas, la existencia de barreras artificiales, expectativas irreales por parte de desarrolladores y contratistas sin claridad en las responsabilidades, los niveles clasicos suelen ser:

  • Junior Developer
  • Mid/Regular Developer
  • Senior Developer
  • Software Architect
Versión TL:DR

La infografia es gracias a Academik.

Como muchas cosas en el área de TI, los criterios suelen ser subjetivos y heredados desde Estados Unidos, no están estandarizados en la industria, pero se pueden observar ciertas características y tendencias en cada nivel/oferta laboral.

En esta «clasificación» presento mis conclusiones luego de participar como interesado en plazas laborales, así como auxiliar a equipos de desarrollo y reclutamiento a contratar candidatos.

Junior Developer

Uno de los criterios primarios para identificar a un Junior Developer es su experiencia, o para ser más precisos, la falta de experiencia. Lo cual no es necesariamente malo

Características generales:

  • Un desarrollador recién egresado o aun estudiando en la Universidad/bootcamp/curso técnico de programación
  • Desde 0 a un máximo de 3 años de experiencia (ideal 1 año)
  • Suele tener experiencia en un lenguaje de programación, plataformas actuales aunque no necesariamente establecidas

Responsabilidades y roles ideales:

  • Se espera que la persona que haya sido contratada como Junior no tenga «mucha idea» de conceptos avanzados en su técnologia
  • Sus principales labores suelen ser dar mantenimiento a un sistema existente con lineamientos claros de arquitectura
  • Se espera que un desarrollador Junior eventualmente pueda ir tomando responsabilidades conforme avanza en su formación personal y profesional

Principales debilidades y consejos:

  • Suelen saber mucho superficialmente y poco a fondo. Aunque en TI nunca es bueno «casarse con una tecnología», si es bueno ser especialista en algo.
  • Aprender antes frameworks que lenguajes. Mi consejo en este caso siempre es aprender un lenguaje a fondo para entender mejor los conceptos fundamentales, mi listado siempre ha sido:
    • Aprender un lenguaje de tipado estático, idealmente Java
    • Aprender un lenguaje de típado dinámico, idealmente JavaScript
    • Aprender un lenguaje scripting, idealmente Bash.
  • «No saben que no saben». Algo conocido como el efecto Dunning Krugger. Mucho de esto se debe a la falta de enfrentamiento a proyectos reales y la única forma de acelerarlo es participar más en proyectos, participar en Open Source y rodearse de gente con más experiencia que pueda compartir sus conocimientos. Mientras más interacciones se tienen con el gremio/entorno es mejor para formarse una perspectiva amplia.
  • No les importa tanto el negocio. Aunque no todos nacimos para ser Project Managers, una receta para ser mal desarrollador es que no importe la generación de valor para el cliente.
  • No les importa tanto la arquitectura. Una de las tendencias modernas es que las herramientas suelen ser más fáciles y a la mayoría de developer Junior no les importa la arquitectura, la cual generalmente no es importante para entregar soluciones rápido pero es importante para que el código sea mantenible y escalable.

Mid developer

Uno de los criterios primarios para identificar a alguien como el Mid-developer es la experiencia en una plataforma, generalmente a un Mid developer se le pueden delegar tareas y reducir la supervisión e incluso trabajar en posiciones freelance.

Características generales

  • Un desarrollador que ya tuvo un contacto con educación en desarrollo de software en cualquiera de sus formas
  • Una persona que ya entendió que el ser autodidacta en el medio es super importante
  • Desde 1 a 5 años de experiencia

Responsabilidades y roles ideales

  • Se espera que la persona contratada como mid developer tenga familiaridad con herramientas universales en el desarrollo de software como sistemas de control de versiones, linea de comandos básica y un lenguaje de programación
  • Se espera que una persona contratada como Mid developer pueda utilizar jerga común en el área de sistemas
  • También se espera que sea un developer al cual se le pueden asignar tareas con componentes de investigación, desarrollo y sentido de responsabilidad
  • Se espera que sea un desarrollador con formación completa respecto a una plataforma

Principales debilidades y consejos:

  • Les es dificil migrar entre frameworks. Una característica «evolucionada» de ser un Junior developer en el dilema practicidad vs. fundamentación teórica, es la capacidad de evolucionar con el tiempo. Mi consejo es el mismo que para los Jr. Developers.
  • Sobreutilización de patrones. Aunque parezca una paradoja, una de las diferencias claras entre un developer Mid y un Sr. es saber cuando utilizar correctamente las herramientas/patrones/abstracciones, esto básicamente viene con la experiencia.
  • Les es fácil ser dogmáticos con la técnologia. Una vez se ha invertido una considerable cantidad de tiempo en la técnologia, es dificil aceptar que las soluciones van cambiando y lo que solía ser lo ideal, puede que ya no sea lo ideal.
  • No les importa tanto ayudar a otros desarrolladores en su equipo. Y esto previene muchas veces el avanzar en su carrera como desarrollador, el tomar responsabilidad de sus tareas y también del proyecto.

Senior developer

Uno de los criterios primarios para identificar a alguien como senior developer es su capacidad de trabajar en equipo, liderar equipos de desarrollo desde el punto de vista tecnologico y toma de decisiones.

Características generales

  • Un desarrollador que conoce a fondo varias plataformas (lenguaje, bibliotecas, entornos de ejecución)
  • Un desarrollador que cuenta con varios tipos de experiencia en proyectos exitosos pero sobre todo fracasados
  • Un desarrollador que se prepara y actualiza constantemente mediante certificaciones, cursos cortos, MOOCs, conferencias, libros, grupos de usuarios, etc.
  • De 5 años de experiencia en adelante

Responsabilidades y roles ideales

  • Se espera que la persona contratada como Senior developer tenga conocimiento avanzado en dos una plataforma y conozca dos o más plataformas para distinguir entre fortalezas y debilidades (gracias por el feedback en este criterio, parece ser un consenso común)
  • Se espera que un senior developer pueda participar en procesos revisión de código por pares (peer review)
  • Es un developer al cual se le pueden asignar tareas complejas, software de alto desempeño, software crítico y tolerante a fallos
  • Se espera que sea un developer que eventualmente pueda participar como líder de desarrollo (lead developer) ayudando a los demás miembros de su equipo con su experiencia

Principales debilidades y consejos:

  • Les es aun más fácil ser dogmáticos con la técnologia. Una vez que se es Senior no es dificil obtener trabajo en la técnologia de preferencia. Esto no es bueno ni malo pero en plataformas poco establecidas -e.g. Clojure- puede ser algo que le afecté en el futuro.
  • El ego. Un developer senior real no tiene problemas en reconocer que todos somos Junior en algo, un developer senior reciente suele tener mucho ego. Mi único consejo es la humildad y menos azucar. Esto a la larga suele jugar a nivel organizacional para volverse arquitecto de software.

Arquitecto de software

La linea entre un desarrollador Senior y un arquitecto de software suele ser muy delgada ya que ambos son profesionales con experiencia bajo el cinturón. Generalmente va más relacionada a la orientación de las tareas que cada uno realiza. En el caso de arquitecto, sus tareas van más enfocadas a investigación y desarrollo vs producción de software.

Debo decir que muchas veces el rol de arquitecto de software se confunde con el de gestor de proyectos pero esto depende en mayor o menor medida de las políticas de cada empresa.

Características generales

  • Un desarrollador que conoce a fondo varias plataformas (lenguaje, bibliotecas, entornos de ejecución)
  • Un desarrollador que cuenta con varios tipos de experiencia en proyectos exitosos pero sobre todo fracasados
  • Un desarrollador que se prepara y actualiza constantemente mediante certificaciones, cursos cortos, MOOCs, conferencias, libros, grupos de usuarios, etc.
  • De 5 años de experiencia en adelante

Responsabilidades y roles ideales

  • Se espera que la persona contratada como arquitecto de software tenga conocimiento avanzado dos una plataforma y conozca dos o más plataformas para distinguir entre fortalezas y debilidades (gracias por el feedback en este criterio, parece ser un consenso común)
  • Se espera que un arquitecto de software pueda tomar decisiones desde los puntos de vista técnicos, económicos y humanos en relación a la tecnológia a ser utilizada.
  • Es un developer que ya cometió demasiados errores y aprendió de ellos.
  • Se espera que sea un arquitecto de software defina lineamientos, políticas de calidad, de contratación de personal, tecnologías y proyecte la evolución de un sistema.
  • Se espera que un arquitecto de software pueda cargar con la responsabilidad del éxito o fracaso de sus lineamientos en proyectos de software

Principales debilidades y consejos:

  • Al alcanzar cierta edad es extremadamente fácil aburrirse de programar. Pero pienso que programar (incluso POCs) es la única forma real de evaluar las fortalezas de cada plataforma.
  • Un arquitecto real cobra caro. Y el no tener un arquitecto real puede ser incluso más caro dependiendo las características del proyecto.
  • El ego. Un arquitecto real no tiene problemas en reconocer que todos somos Junior en algo, un arquitecto reciente suele tener mucho ego. Mi único consejo es la humildad y menos azucar.
  • Una de las cosas más difíciles para un arquitecto es desarrollar la empatía. Esto es fundamental para entender las necesidades de compañeros de trabajo, clientes y mi único consejo es salir más.