Tag Archives: lecciones

El futuro que le debemos a Alan Kay

Cuando [Alan Kay] fue a la entrevista de trabajo en [Xerox PARC], una de las preguntas tenía que ver con sus sueños ¿cuál crees que será tu mayor logro? le preguntaron. “Una computadora personal”, respondió.

Como parecía que no le entendían lo qué estaba hablando, cogió una cartera del tamaño de un cuaderno, la abrió y dijo: “Esto será una pantalla plana. Aquí abajo habrá un teclado, y tendrá la potencia suficiente para almacenar correo, archivos, música, imágenes y libros. No pesará más de un kilogramo. De eso estoy hablando”.

El entrevistador se rascó la cabeza, murmuró: “Sí, claro” y lo contrató. Era el año de 1970.

Esa historia la descubrí mientras leía [Los Innovadores] de [Walter Isaacson]. Había escuchado un poco de Alan Kay, pero no tenía idea del genio que me estaba perdiendo.

No quiero entrar en más detalles pues este sería un post interminable. Me queda agregar que este pionero de la computación ha hecho más de lo que conocemos y posiblemente estemos usando algo que haya sido uno de sus sueños (sin ir muy lejos, la programación orientada a objetos, la interfaz de usuario y claro ¡las tablets!). Los dejo con un video que resume rápidamente los aportes del gran –y quizá único– Alan Kay.

Un abrazo (y gracias, Alan)

Fuente cabecera: [Extracts from Alan Kay’s AMA on Hacker News]

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