10 aspectos a considerar si te interesa la arquitectura de software

Hace mucho que esta idea ronda por mi cabeza:

¿Qué necesito para ser un arquitecto?

Creo que es la consecuencia de tantas conversaciones con mis amigos o conocidos en eventos de tecnología.

Por mi parte –como apreciación personal– les comparto que he tenido la suerte de haber trabajado como arquitecto en más de un proyecto de tecnología y que este tipo de experiencias me ha ayudado a diferenciar entre las funciones que debería realizar un arquitecto y encontrarme con algunos malosentendidos a consecuencia del rol.

Consecuencias de una mala arquitectura
[Code Complete, Steve McConnell, 2004]

Con “malentendidos” me refiero a que me he topado con frases como “nuestro proyecto no necesita un arquitecto” o “ese rol no debería existir” o “los arquitectos no saben programar”, y la verdad es que, así como hay buenos profesionales, también los hay de aquellos que no saben hacer bien su trabajo y que por lo general son los responsables de muchos inconvenientes.

Lo bueno de estas experiencias es que –casi siempre– logramos conseguir –gracias a la apertura del equipo con el que estaba– que el trabajo se pueda realizar de manera exitosa.

En fin, desde mi perspectiva, creo que cada rol existe gracias a una necesidad en particular y de ser así, debería cumplir con algunos criterios fundamentales. El rol del arquitecto no es una excepción, así que he preparado algunos aspectos que me gustaría compartir con ustedes:

1. Saber programar: No hay que ser un experto en programación pero es importante contar con la experiencia suficiente para entender el código del equipo de trabajo, hablar su idioma y claro, participar en los code review.

2. Enseñar con el ejemplo: Si bien es cierto este es un criterio básico de liderazgo, aquí se debe reforzar a nivel técnico, pues todo diseño o presentación debe ir acompañado con código de ejemplo. Sí, con esto me refiero a “la demo” y claro está, no tiene que ser algo completamente funcional pero debe demostrar la factibilidad de nuestra propuesta.

3. Conceptualizar: Esta capacidad será complicada de adquirir si creemos que un arquitecto tiene que ser un programador con mucha experiencia. La clave para acortar el camino, es dejar dejar de pensar en líneas de programación para hacerle un espacio a los componentes y sus tipos de integración.

4. Ser estratégico: Lo “fácil” de esto, es diseñar soluciones flexibles (fáciles de modificar o extender). Lo complicado viene cuando olvidamos los objetivos del negocio y sus respectivas restricciones. Esto implica que tengamos la facilidad de conversar tanto técnicamente, como en términos del giro del negocio. Luego de superar esta barrera, debemos proyectar lo que podría ocurrir en el futuro.

5. Presentar efectivamente: Como regla general, toda propuesta de arquitectura debe ser concreta, de fácil entendimiento y claro, con una “demo” que evidencie la factibilidad de nuestro trabajo. Esto pasa a segundo plano cuando tenemos que enfocarnos en ser concretos y convincentes al momento de explicar nuestras ideas.

6. Ser humilde: Debemos eliminar cualquier tipo de barrera a consecuencia del “poder que llevas por tener este rol”. Una forma de acortar distancias es dejar el ego a un lado para escuchar sugerencias, aceptar nuestros errores y si se da el caso, pedir disculpas de la única forma en la que se deberían pedir, con honestidad y sin condiciones.

7. Estudiar y poner en práctica: Además de reforzar nuestros soft skills, necesitamos entender la importancia de la [construcción de software], la [programación orientada a objetos], los beneficios del [código limpio], comprender los [patrones de diseño], averiguar sobre los [tipos de arquitectura] que existen en el mercado, las [nuevas tendencias de arquitectura] y claro, debemos [programar] en nuestros ratos libres.

8. Leer: Los líbros técnicos tienen que ser algo normal en nuestras vidas, pero también debemos incluir cualquier otro tipo de lecturas. El tópico queda a nuestra elección.

9. Preguntarnos ¿qué más podríamos hacer? Esto aplica al diseño en el que estamos trabajando, pero tiene más sentido cuando lo revisamos en nuestra vida profesional (pues lo natural es que evolucionemos a arquitectos empresariales) y ¿por qué no? también deberíanos hacernos la pregunta a nivel personal.

10. Sentido común: Yo creo que esto es algo que se puede entrenar y que podría tomar más tiempo del que pensamos, no por algo dicen que termina siendo “el menos común de los sentidos”. Pero no nos desanimemos, tomemos un momento para respirar y revisar si estamos construyendo un [homeromóvil] cuando lo que realmente necesitamos es algo tan simple como un skate.

Desde un punto de vista netamente personal, creo que cada aspecto tiene muchos requisitos y restricciones que se deben ir superando en el camino y si llega el momento en el que te das cuenta de que no te estás divirtiendo, pues es posible que tengas revisar otra vez si te gusta lo que estás buscando, o mejor aún, no presionarte pues nadie es perfecto y menos, un excelente arquitecto.

Un abrazo, JD

¿Qué aprendí luego de haber liderado un programa de entrenamiento?

Al culminar la universidad, se me ocurrió la –¿genial?– idea de dictar un curso de programación. Creo que era muy joven –e inocente– para lanzarme con esa aventura y la verdad es que no sabía lo que me esperaba.

Fuente: [Archivo personal]

Recuerdo que inicialmente eramos dos personas interesadas en dictar el curso. Mi primera tarea fue preparar el temario de las clases (que serían semanales y durarían al menos dos meses) e invitar a todos los alumnos que estuvieran interesados (aún recuerdo que imprimí y pegué muchos anuncios en mi querida facultad). Mi compañero de proyecto –o locura– se encargaría de conseguir un aula con las respectivas herramientas (proyectos, computadoras, etc) y luego de esto, nos repartiríamos el dictado de las clases.

Fuente: [Archivo personal]

Al finalizar la primera clase, mi amigo me dijo que no tendría tiempo para continuar. Escuché sus palabras y acepté lo que en adelante se convertiría en una de las aventuras más interesantes de mi vida. De eso me gustaría escribir con más detalle pero aquí algunas lecciones que aprendí en ese camino.

  1. Preparar clases con –mucha– anticipación: Es importante separar un horario de preparación de clases. En este revisaba toda la información que quería compartir y si me daba el tiempo, practicaba lo que iba a hablar (al menos una vez)
  2. Si hay laboratorios o “hands-on”, se deben probar con anticipación: Tienes que encontrar una forma de probar tus laboratorios. En mi caso imprimía el material y lo ejecutaba paso a paso. Al encontrar observaciones, las anotaba y luego actualizaba el documento. Esto lo hacía al menos una vez.
  3. Ser paciente: No todos los alumnos conocían lo que yo hubiera esperado. Es por ello que ahondé en los fundamentos y modifiqué el contenido de las clases planificadas.
  4. Ser empático: Entender la causa de algunas preguntas y el comportamiento de los alumnos fue una habilidad que fui ganando con el paso de las clases.
  5. Ser sincero: Hubo situaciones en las que las que la clase no me salía como esperaba, o en las que no podía responder todas las preguntas. Antes estos casos siempre funciona el “faltó tiempo para prepararme” o el muy difícil “no lo sé”, con la promesa de averiguar al respecto. El ego no funciona.
  6. Promover la diversión: Esto no solo involucra hacer bromas en clase. En mi caso buscaba que haya participación de los alumnos. Para esto preparaba casos que resolvíamos en clase, a veces hacía preguntas como si fuera un juego de trivia y –ok, lo admito– otras veces solo hacía bromas.
  7. Promover la competencia: Casi todos los inicios de clase, hacía preguntas sobre las clases anteriores. En algunas ocasiones dejaba tareas para que los alumnos trabajen en conjunto y presenten algo al respecto. En otras tomaba algún examen y compartía la solución o promovía la conversación o el debate.
  8. Ser transparente: En cada clase compartía los puntajes por alumno, en esa época usaba excel e indicaba cómo se movía el tablero de posiciones. De haber un problema con el avance del curso, también lo compartía con los alumnos.
  9. Pedir ayuda: Hubo un momento en el que ya no pudimos usar el salón que nos había prestado, así que recurrí a la empresa en la que trabajaba pues ellos tenían una sala que nos vendría –y nos vino– muy bien.
Fuente: [Archivo personal]

Si bien es cierto, de todo esto ya ha pasado mucho tiempo y fue duro –y a veces triste– trabajar practicamente solo, pero aprecio todo lo ocurrido y claro, admito que mi ego hizo que cometiera errores. Por suerte el balance general arrojó un grupo de chicos muy inteligentes que poco a poco logró conseguir un empleo y que de alguna forma ese curso impactó en sus vidas.

Fuente: [Archivo personal]

En mi caso, la empresa en la que trabajaba me pidió que lidere un segundo programa de entrenamiento (y lo que en el tiempo formaría parte del trainee de la compañía), pero ya con presupuesto que ellos admistrarían. Este también fue un capítulo que aprecio bastante y al igual que el anterior, forma parte de uno de los proyectos que cambió mi vida personal y profesional.

Me gustaría terminar esta publicación agradeciendo a todos los que participaron en ese sueño, y claro, también recordando que una noche, ya caminando hacia la salida de la universidad, uno de mis amigos (y también alumno) me preguntó por qué dictaba el curso. Aún recuerdo lo que le respondí “es que no tenía opción, ya habíamos empezado y no quería dejarlo así”, no sé si estuvo mal responder eso, pero me alegra mucho haber participado en sus vidas.

Un abrazo,

Fundamentos, fundamentos, fundamentos

Si hay una de las tantas cosas que aprendí del gran [Randy Pausch], es que, si no entiendes los fundamentos de lo que sea que estés haciendo, terminarás haciendo cualquier cosa.

Lo gracioso es que, por más simple que parezca, esa enseñanza se puede aplicar a cualquier ámbito de nuestras vidas. Personalmente me ha servido en muchos rubros, incluyendo en el extraño –y amado– mundo de la tecnología.

Todo esto me vino a la mente pues hace unos días terminé de leer (una vez más) [The Last Lecture] (Pausch, 2008) y solo puedo decir, muchas gracias Randy, tengo pendiente por escribir tantas cosas sobre tus enseñanzas, pero de momento quiero publicar este pequeño detalle.

Aquí un [video] que es una de las razones por la que es mi héroe (además claro, de mi mamá)

Sin más me despido, un abrazo, JD

¿Quieres aprender Vue? Aquí una excelente referencia

Hace poco decidí aprender Vue, pues –hasta donde pude averiguar– no requiere mucho conocimiento –más que el de JavaScript– y se puede implementar en aplicaciones web ya existentes, lo cual para mi es un factor muy importante.

Image result for learn vue
Fuente: [Medium]

En fin, estoy preparando un post al respecto pero antes quería comentarles que luego de buscar en la web, me puse a estudiar usando:

Ambas referencias me parecen buenas pero la información por defecto está en inglés, así que ya tenemos una razón más para seguir aprendiendo el idioma.

Con respecto al material en LinkedIn Learning, para este se necesita una suscripción pero es posible suscribirse gratis temporalmente o acceder por invitación. Si gustan me escriben y les mando una para que puedan ver el curso 🙂

Ya enfocándonos en la documentación oficial, además de ser gratis encuentro que:

  • Tiene traducción al español
  • El material está integrado a plataformas como [Vue Mastery] o [Scrimba]
  • Ambas plataformas presentan la información en inglés (no hay traducción) e incluyen secciones que nos hacen escribir código.
  • Vue Mastery nos deja retos por lección, lo cual hace interesante el proceso de aprendizaje.
  • Scrimba me ha sorprendido pues cada video se puede detener en cualquier momento para editar el código de ejemplo que están mostrando. Si desean pueden probar con [este video]
Fuente: [Scrumba]

En este punto del post debo hacer una acotación. Me considero una persona que prefiere entender los fundamentos antes de ponerse a escribir código sin entender lo que está ocurriendo. Respeto mucho a las personas que “aprenden la teoría en el camino” pero en mi caso necesito un momento para entender, luego de eso ya me pongo a “aprender en el camino” 😀

Habiendo mencionado lo anterior, les cuento que encontré un curso en español que está MUY BUENO, aquí el [enlace] para que lo disfruten, claro está, luego de –por favor– entender los fundamentos 🙂

Un abrazo, JD

Linus = Linux + Git + …

Este video tiene poco más de tres años y creo que mientras más lo veo, más inspirador me resulta. No quiero pecar de fundamentalista (o parecerlo) pero siento que le debemos mucho al buen Linus Torvalds.

Es ya sabido por muchos (y si no, esta es una buena oportunidad) que es el creador de lo que en el tiempo se ha convertido en uno de los sistemas operativos más reconocidos y (posiblemente) más utilizados en el mercado.

Linus en su oficina 🙂
Fuente: SFGATE

No creo estar exagerando, pero vale la pena recordar que en la actualidad hay muchos dispositivos que trabajan con una distribución de Linux, pues además de los equipos de escritorio, están los televisores, celulares, tablets, lectores de libros electrónicos, refrigeradoras y podríamos seguir contando pero mejor lo dejamos ahí 🙂

En fin, en la entrevista también se menciona la creación de Git y sobre esto les comparto que hace muchos años, un buen amigo me contó la anécdota de la creación de este excelente gestor de versiones, y sinceramente, una cosa es tener una conversa techie con tus amigos (sí, tengo de esas y varias) y otra cosa es que el creador cuente la razón de la existencia de un producto que en este momento –creo yo– es un requisito básico, si necesitas trabajar seriamente en el mundo de la programación.

Ya para terminar y dejarlos con el video (que es un TED Talk con subtítulos en español, por si el idioma representa una barrera), me es muy difícil resumirlo con una frase, pero la que ahora viene a mi mente es “tú nunca te rindes”, la cual refleja mucho la vida del buen Linus.

Espero les guste, un abrazo.