Distracciones productivas

Soy hiperkinético. Desde muy pequeño.

Afortunadamente, cuando era niño no existían los remedios "mágicos" como el Ritalin o las sesiones infinitas de psicopedagogía. A lo más, los niños que éramos hiperactivos, pasábamos por ser "niños inquietos" y apelábamos a la infinita paciencia de padres, profesores, tías, abuelas, parientes y amistades. Una pelota y una bicicleta bastaban.

Y era frecuente desaparecer de casa por 5 o 6 horas seguidas durante las tardes, revolucionando otros entornos domésticos.

Hoy en día, soy igual de hiperkinético.

Es difícil que pase más de 1 hora continua en mi puesto de trabajo en la oficina.

Si bien tengo múltiples formas electrónicas para comunicarme con colegas y colaboradores, prefiero levantarme de mi silla, ir al lugar de los otros y conversar en persona. Por eso, el teletrabajo no siempre me es cómodo, porque el toque personal lo considero importante en el día a día.

Pero hay una situación particular donde la "prisión física" me obliga a buscar otras formas para eliminar los excesos de energía, especialmente cuando atenta contra mi concentración: durante las teleconferencias, audioconferencias o conference call.

El punto es que equivocadamente, uno cree que durante una audioconferencia, se puede adelantar otros trabajos en el computador personal y que no estén relacionados con el tema de la “reunión virtual”.

Después de todo, el único vínculo con los otros participantes es a través del audio común, por lo cual nadie ve lo que estás haciendo en tu espacio propio. Y por ello, surge la tentación durante estas reuniones virtuales, de "aprovechar el tiempo" para revisar un documento, armar una presentación o responder correos electrónicos.

El resultado es que ninguna de estas cosas las puedes hacer bien en forma simultánea, porque generalmente son de contextos muy distintos.

Por tanto, no sólo eres improductivo por tratar de multiplexar tu concentración: peor aún, puedes cometer errores importantes por la falta de atención. Y eso sí que puede tener consecuencias bien complicadas.

Así que por lejos la mejor opción, es concentrarse exclusivamente en lo que corresponde: la Conference Call.

Pero en este caso y con mayor razón, surge nuevamente el problema de la "prisión física".

En muchos puestos de trabajo en Microsoft y otras corporaciones con trabajos intensivos de "coordinación virtual", siempre encontrarán pequeños juegos, de diversos tipos y formas: puzzles, juegos de ingenio, piezas encajables, pentominos, armables magnéticos y múltiples otros artefactos de escritorio, los cuales ayudan a realizar labores manuales simples y mantener la concentración.

Aunque suene paradojal, son pequeñas distracciones físicas, cuyo objetivo es mejorar la productividad virtual.

Aprovecho de pasar el dato, por si están buscando alguna idea de regalo futuro para Maz. Y por cierto, el merchandising inteligente, siempre será bienvenido. ;-)

Stay Tuned!

Fuente de la imagen: Publiblanes

Leer artículo completo ...

Memorias de un hacker retirado

Recuerdo mis primeros intentos por desentrañar los misterios de los computadores y la programación, en el lejano 1982. Mi primer compañero fue mi viejo y querido VIC20.

Obviamente, yo era de la hermandad de los fanáticos de Commodore. Y hasta el día de hoy, todavía mantengo largas discusiones con viejos camaradas, sobre cuáles eran los líderes de los primeros microcomputadores para el hogar.

Nunca llegaremos a una conclusión definitiva.

Commodore, Sinclair o Atari, todos con su legión de apasionados defensores y furibundos detractores, plenos de argumentos teñidos por la pasión.

N. del A.: Parece que desde los orígenes del mundo digital, el fundamentalismo forma parte de nuestra cultura.

Mi VIC20 tenía la fabulosa cantidad de 4.096 bytes de RAM (4 Kilobytes ... término que las nuevas generaciones no conocen).

En ese VIC20 aprendí los primeros vericuetos de la programación en BASIC y nació mi amor por transformar una abstracción en código fuente. A través de la animación de sprites, extensiones a la ROM y programación de rutinas de aceleración gráfica, conocí la simpleza y potencia de la fuerza bruta del lenguaje de máquina, la sutileza en el uso de un JMP condicional y la precisión necesaria para hacer un shift de bits en un registro.

Pero mi vida cambió radicalmente, cuando mis padres me pudieron comprar un Commodore 64.

Un nuevo y fabuloso equipo, que seguía conectando en largas veladas nocturnas al TV "en colores" del living de mi casa.

Siempre hemos escuchado que mirar TV excesivamente cerca, hace pésimo para la vista. Claramente, las largas jornadas de 6 o más horas, a una distancia de 35 o 40 centímetros de la pantalla del televisor, programando a punta de peek y poke, son un importante antecedente para mi temprana miopía.

A pesar de tener buses de 8 bits, el C=64 direccionaba hasta 64 Kb. La ROM/BIOS ocupaba sólo 8 Kb., por lo cual el C=64 me ofrecía ahora la fabulosa cantidad de 56 Kb de RAM, disponibles totalmente para mí.

Y permitía hacer maravillas, como ejecutar ese maravilloso juego llamado Ghosts & Goblins.



Así continué aprendiendo y experimentando, hasta que el año '86 tuve mi primer PC en casa.

Un "monstruo" con un procesador 8088 con 768 Kb de RAM (768 = 640 + 128, los geeks entienden por qué :-) y la increíble cantidad de 30 Mb en disco duro.

Cada vez que partía, ese computador con sus vibraciones y crujidos me recordaba el motor de un viejo refrigerador.

También en esa época, alrededor del '86, tuve la oportunidad de poseer un modem de 1.200 bps., aún cuando ciertamente no tenía muchos "nodos remotos" con los cuales aplicar mis nuevas "capacidades telemáticas".

Mi principal actividad remota era conectar mi ruidoso computador, a unos pocos BBS chilenos, participando de las primeras comunidades digitales locales. Incluso en algún momento, recuerdo haber levantado un servidor Wildcat, pero las continuas llamadas telefónicas recibidas en mitad de la noche, hicieron que mis padres rápidamente prohibieran el nuevo hobby.

Eran los tiempos donde debíamos aprender obligadamente las diferencias entre E-7-1 o N-8-1 para una emulación de terminal, y nos sabíamos de memoria los comandos y argumentos Hayes para configurar un módem (recordar un ATDTX3S0=0 me sirvió muchísimo hace unos días ...:-).

Esto de la paridad par o impar era particularmente importante, cuando nos conectábamos a la U para emular un IBM 3270 (que obviamente era MUY distinto de una emulación VT100, para conectarse a una VAX o un equipo Unix). Y aprendíamos con dificultad la diferencia entre la codificación EBCDIC y ASCII.

Ahí, en esos primeros tiempos, aprendí la importancia de la interoperabilidad, más allá de la teoría.

Eran buenos tiempos, donde nos rebuscábamos la mejor forma para poder acceder a ese gran banco de software llamado SIMTEL, ya fuera por una BBS potente o a través de una conexión a BITNET.

Más de alguien aprendió (después de quebrarse la cabeza) que XModem era un protocolo engañoso (porque modificaba los archivos recibidos), alabamos la flexibilidad de YModem y la capacidad de restauración de ZModem. Estos protocolos no sólo los usamos, sino que también los programamos y modificamos, adaptando el modelo de administración de ventanas y puntos de restore para diversos proyectos locales.

Y definitivamente nos graduamos de magos, cuando logramos completar una sesión de transferencia multiplataforma mediante Kermit.

En esos tiempos, lograr transferir un archivo de 150 Kb. era más preciado que un diamante. Y durante los 30 minutos o más que duraba una simple transferencia (en esos tiempos sí que había latencia), rezábamos para que no se cayera la sesión.

La experiencia de esos años austeros, en los cuales debíamos aprovechar al máximo cada bit disponible, me ha servido mucho y en diversos contextos.

Recuerdo un complejo proyecto a principios de los '90, en el cual todos esos conocimientos de hacker, los incluimos en un sistema distribuido de alta disponibilidad, que combinaba computadores clientes con 1 Mb de RAM, procesos residentes con corrutinas bajo DOS e interfaces usuario en Clipper orientado al objeto, una arquitectura fault tolerant sobre 3 nodos servidores VAX/VMS espejados en tiempo real, dispersos geográficamente y conectados sobre redes X.25, con anchos de banda de 64 Kbps. En ese sistema, diseñamos y programamos desde el más mínimo bit hasta los procesos de sincronización en tiempo real. Eran buenos tiempos.

Cuando estuve a cargo de Cybermarket en 1997 y montamos el primer mall virtual en Chile, en una operación de Comercio Electrónico pero "de verdad" (ofrecíamos un mix de 44.000 productos en 4 rubros, incluyendo lechugas, martillos, azúcar, destornilladores y crema facial), definimos algunos criterios de uso de recursos, tiempos de respuesta y usabilidad, que como responsable tecnológico consideré en ese tiempo como "intransables", con el pesar del equipo de implementación.

Cybermarket debía cargar las páginas en los browser de los clientes, en un máximo de 7 segundos, considerando transferencias con un ancho de banda de 14.4 kbps. y sin exigir capacidades de procesamiento de Javascript en el lado cliente. Y por cierto, con esas estrictas definiciones, problemas de interoperabilidad no teníamos.

Fue difícil lograr cumplir con esas duras condiciones. Pero hace más de 12 años, implementamos un sistema de e-commerce con algunos servicios que incluso hoy podrían aparecer como avanzados, porque nos preocupábamos más de la funcionalidad y usabilidad, que de los "bells & whistles" de las interfaces.

Probablemente, si no hubiera aprendido en mis primeros tiempos en un entorno de "carencia digital", habría sido más derrochador durante mi carrera profesional.

Pero en los momentos difíciles no transé y resistí la tentación de la abundancia. Y fue bueno no transar, motivo por el cual varios de esos proyectos fueron exitosos y tuvieron una larga vigencia.

En estos nuevos tiempos de "abundancia", ser un "avaro digital" sigue siendo una buena actitud.

Me sorprende ver cómo algunos nuevos arquitectos y diseñadores, consideran que el "ancho de banda" es cuasi ilimitado, el almacenamiento infinito, la disponibilidad continua, el hardware infalible. Y formados en la "abundancia", diseñan servicios, modelos, negocios, considerando un pool ilimitado de recursos.

Hoy declaro formalmente que soy un "hacker retirado", que se dedica a tomar litros de café conversando sobre el diseño de modelos de negocios y de servicios, y que lo más complejo que programo, son las reglas de distribución de mis correos electrónicos.

Pero a la luz de la experiencia, mi única y principal recomendación a los nuevos programadores (teniendo sólo algunos de ellos los antecedentes suficientes para ser llamados "arquitectos"), es que sean siempre .. unos "avaros digitales". :-)

Stay Tuned!

Fuentes de las imágenes: Wikipedia

Leer artículo completo ...