viernes, 29 de enero de 2010

Frases: Participación y compromiso.

¿Cuál es la diferencia entre participación y compromiso? Digamos que si el objetivo es preparar huevos con jamón la gallina participa, pero el cerdo está comprometido.

(me la recordó un reciente twit de @Yoriento)

jueves, 28 de enero de 2010

Frases: $.noop()

“$.noop returns the sound of one hand clapping.”

$.noop devuelve el sonido de una sola mano aplaudiendo.”

- Karl Swedberg comentando la documentación de $.noop() de jQuery.

Para los despistados: $.noop() es una función de jQuery que -como su nombre indica- no hace nada.

martes, 12 de enero de 2010

Desafíos.

Un desafío es el deseo de alcanzar un objetivo ubicado un poco más allá (no demasiado, porque si no ya sería un sueño) de nuestras capacidades actuales. Implica mejora, autosuperación.

Para mí, lo motivador de mi trabajo es lo desafiante que puede llegar a ser. Frecuentemente se nos plantean proyectos parecidos a aquellos que enfrentamos en el pasado pero con algún matiz, algún punto oscuro, alguna particularidad especial que nunca hemos implementado. Estas particularidades representan nuevos problemas y son las que hacen al proyecto desafiante en esa medida justa que nos permite enfrentarlo con cierta confianza sin llegar al extremo de la sensación del salto al vacío.

Cuando no es así simplemente me aburro, y no tolero bien el aburrimiento. A mediados del 2009 di el salto y cambié de trabajo. En su momento actué guiado más por esos sentimientos –de aburrimiento- racionalizados que por razones objetivas. De alguna manera ese creciente aburrimiento ante los problemas y situaciones han alimentado este blog -inmejorable vía de escape- en la primera parte de este año (y a cuya ausencia se debe, en cierta medida, la poca producción bloggera de la segunda).

Finalmente el tiempo puso las cosas en perspectiva y el nuevo entorno me da un punto de comparación. Me llama la atención lo nimio, lo poco importantes que eran los problemas y situaciones que ponía como excusa del cambio. Ahora es claro que esa necesidad de cambio no estaba dada por el entorno sino que provenía de mí mismo, que su origen no era la gravedad o repetición de algún problema o situación sino el nulo desafío que éstos representaban para mí. Pareciera que “nulo desafío” implica que todo era “fácil”. Nada más lejos de lo que quiero decir, aquí vamos.

El punto central de toda esta cantinela es que uno no sólo “es parte de” sino que también construye la situación que lo rodea. Decir “no habrán nuevos desafíos” es, en realidad, una vuelta retórica por la que esquivamos la responsabilidad en la construcción de esa situación al ubicar a los desafíos en el entorno cuando en realidad están en nosotros.

Los desafíos no están allí, uno no los encuentra sino que los crea. Es decir que constantemente enfrentamos los desafíos que nos hemos creado, como Don Quijote contra los molinos de viento.

Un entorno de trabajo desafiante no es, por si queda alguna duda, algo objetivo. Lo que para unos es tierra fértil es desierto para otros, no por la dificultad o no de los problemas objetivos a resolver –finalmente el único problema objetivo lo constituyen los requerimientos de un cliente-, sino por la predisposición o no de cada uno a crear desafíos en ese entorno en un momento determinado.

Pareciera ser, entonces, que a nivel institucional hay poco que se pueda hacer para crear un entorno desafiante, dado que esta característica reside en cada persona y no en ese espacio creado grupalmente.

En alguna medida es así. No se pueden “crear” desafíos institucionalmente. Pongamos un ejemplo: se plantea “ser referencia en el uso de la tecnología X” como un “desafío en el que todos tenemos que estar comprometidos”. Esto es en realidad apenas un objetivo y una expresión de deseo que puede ser origen de un desafío motivador para algunos pero indiferente o incluso fuente de sentimientos negativos –inseguridad, presión, rechazo- para otros.

Lo que sí se puede hacer institucionalmente es ubicar a cada integrante en un puesto en donde los problemas objetivos –los requerimientos de sus clientes externos o internos- estén alineados con su predisposición a crear desafíos en torno de esos problemas y proporcionar los recursos, la libertad de acción o la guía que necesite cada uno para superarse. Esto será mucho más productivo que el vano intento de imponer desafíos a diestra y siniestra como si todos fuéramos iguales y nos interesaran las mismas cosas.

Pero esto implica un conocimiento muy personal de cada integrante del equipo por parte de la institución… mejor dicho por parte de las personas que definen los puestos en las instituciones y que –erróneamente o no- generalmente están muy alejados del resto de la empresa, si no física por lo menos profesionalmente.

La solución común, dado que a nivel institucional no puede haber un conocimiento personal profundo de cada uno, es dividir la responsabilidad entre persona e institución: la responsabilidad institucional es de abrir las puertas, proporcionar los caminos para que cada uno busque o cree ese lugar desafiante, y está en cada uno la responsabilidad y el esfuerzo de motorizar esa búsqueda. Motorizar es buscar, proponer, convencer, buscar alternativas, concretar.

Es tan común en sistemas la queja constante sobre las posibilidades de desarrollo profesional (“de encontrar nuevos desafíos”) como la inacción de quien las enuncia en cuanto a la creación o búsqueda de ese espacio fértil en desafíos profesionales.

De ser sincero el deseo, de existir esa búsqueda y de ser infructuosa, debería continuar por fuera (pero ya basta de quejarse), la posibilidad de que no haya intersección entre lo que una persona encuentre como desafiante y las necesidades de una institución en particular existe, y no hay más que hacer que seguir buscando.

viernes, 8 de enero de 2010

Jueguitos de Viernes: Basketball

Simplemente apuntar y tirar. ¿La gracia? Que todos los jugadores online juegan al mismo tiempo y vamos viendo nuestra posición en tiempo real. Además podemos formar grupos para competir con amigos.

basketball-online

Link: Basketball (visto en Juegos Microsiervos).

jueves, 7 de enero de 2010

Palabras del general sobre metodologías ágiles…

peron  ….útiles para convencer a los compañeros (nunca mejor utilizada la palabra) del equipo de desarrollo.

- Pongan el carro en movimiento que los melones se acomodan solos.

- La única verdad es la realidad.

- Mejor que decir es hacer, mejor que prometer es realizar.

- Gobernar es fácil, lo difícil es conducir.

- Para conducir un pueblo la primera condición es que uno haya salido del pueblo, que sienta y piense como el pueblo.

- La organización vence al tiempo.

- Es evidente que en todos los movimientos revolucionarios existen tres clases de enfoques: el de los apresurados, que creen que todo anda despacio, que no se hace nada porque no se rompen cosas ni se mata gente. El otro sector está formado por los retardados, esos que quieren que no se haga nada... Entre esos dos extremos perniciosos existe uno que es el equilibrio y que conforma la acción de una política, que es el arte de hacer lo posible...

miércoles, 6 de enero de 2010

Curiosidades en los lenguajes de programación.

A veces la lógica sobre la que se asienta un lenguaje de programación (cosa “estricta” –con comillas- si las hay) tiene algún extraño efecto colateral. Otras veces un mal momento (¿demasiado temprano por la mañana? ¿demasiado tarde por la noche? ¿resaca?) de aquél que debe dar una definición queda inmortalizado por las consecuencias de ésta.

Cuestión que en todo lenguaje hay ciertas curiosidades, puntos oscuros, cosas que no parecen todo lo claras, lógicas o esperables que deberían. Es el tipo de cosas que se han ido destapando en Stack Overflow bajo el título Strangest language feature con la consigna “What is, in your opinion, the most surprising, weird, strange or really "WTF" language feature you have encountered?”

Por ejemplo…

Javascript se lleva las palmas en la categoría "sutilezas tramposas":

return
{
    id : 1234,
    title : 'Tony the Pony'
};

//devuelve undefined, ya que el salto de línea luego del return implica
//(implícitamente) el final de la instrucción. Por eso esto sí funciona:

return {
    id : 1234,
    title : 'Tony the Pony'
};

//Y esto también (grrr....)

  return /*
*/{
    id : 1234,
    title : 'Tony the Pony'
  };

...su tabla de verdad tiene algunas cositas impresentables:

''        ==   '0'           //false
0         ==   ''            //true
0         ==   '0'           //true
false     ==   'false'       //false
false     ==   '0'           //true
false     ==   undefined     //false
false     ==   null          //false
null      ==   undefined     //true
" \t\r\n" ==   0             //true

Por otro lado, el integer cache en java es un buen ejemplo de esos extraños aunque esperables efectos colaterales:

Integer foo = 1000;
Integer bar = 1000;

foo <= bar; // true
foo >= bar; // true
foo == bar; // false

//pero si los valores de foo y bar están entre 127 y -128 (inclusive)
//el comportamiento cambia:

Integer foo = 42;
Integer bar = 42;

foo <= bar; // true
foo >= bar; // true
foo == bar; // true

Y no es la primera vez que escucho quejas (muy justificadas, según mi propio criterio) sobre el manejo de cadenas en php:

//uno pensaría que
"01a4" != "001a4"
//pero la realidad es que
"01e4" == "001e4"

Captaron la idea, me imagino. El resto en la entrada original de Stack Overflow.

martes, 5 de enero de 2010

La queja.

Soy quejoso por naturaleza. Siempre le encuentro el pelo al huevo y, a falta de errores o problemas más graves, hago de un charquito una inundación…

A veces exagero un poco. Cuando mis compañeros de trabajo están –razonablemente- ya un poco hartos de mis cancioncitas plañideras les recuerdo, como para equilibrar un poco la balanza, que si bien me quejo

a) estoy en general encargándome activamente o lidiando con el problema, así que eso me da cierto derecho a una breve descarga emocional –a veces no es tan breve como debería-, y

b) estoy constantemente pensando y tratando de proponer soluciones –a veces peores que el problema, pero bueno… prueba y error, y sin error no hay prueba- y que

c) soy el primero en ponerle el hombro a cualquier intento de mejora, incluso cuando no crea que vaya a funcionar –probemos, con un poco de suerte me equivoque-.

Sí, a veces exagero y soy demasiado duro con algún temita en una solución que, en general, funciona bien. Pero bueno, es parte mi forma de motivar –correcta o no, efectiva o no, ésa es- y de motivarme a concentrarse no en lo que salió bien sino en lo que salió mal, que es lo que merece más atención.

Lo que es seguro es que es menos probable –a veces se requiere de más de un golpe- que me vuelva a dar con la misma piedra… aunque luego encuentre otra con la que impactar.

Por otro lado, hay personas en las que la queja es sólo eso, una queja. Una enumeración interminable de problemas, errores y malas decisiones que no las mueve a la acción o al cambio en lo más mínimo.

Estas personas piensan en el pelo antes de hacer el huevo. Como el “pelo a futuro” desmotiva, se quedan en la inacción y la queja se vuelve constante –porque sin acción nada cambia-, autosuficiente e inmortal.

Si es la queja la que lleva a la inacción o si es la excusa para la inacción, es imposible de saber. Pero es en todo caso indiferente, si el resultado es el mismo y es la nada.

Pero ojo, porque el quejoso no es mentiroso y no necesariamente tiene malas intenciones. Normalmente los problemas sobre los que la queja se asienta son reales, la práctica de la observación pasiva lo ha vuelto experto en su detección.

Así que –para mí- tampoco es prudente hacer oídos sordos a su cantinela. Lo que debemos evitar –a veces harto difícil- es quedar atrapados girando en la órbita de su parálisis.

Una solución imperfecta es siempre mejor que nada. Incluso una solución equivocada es mejor que nada, es una posibilidad menos en el camino de la prueba y error. Hacemos sistemas, no estructuras de concreto, y siempre podemos volver atrás y buscar otra salida. El tiempo insumido, al que usualmente calificamos de “perdido”, no será tal hasta que nos demos por vencidos.

viernes, 1 de enero de 2010

Jueguitos de Viernes: Air Traffic Chief.

Gracias a Cerebrado, que como siempre sabe qué tirar para arruinar la productividad de un viernes… pero hoy es viernes 1, así que podemos procrastinar sin culpas y combatir la resaca con este adictivísimo juego.

En Air Traffic Chief hacemos las veces de controladores de vuelo y lograr que todas las naves lleguen a destino. Empieza fácil, casi aburrido, pero se complica rápidamente. Yo todavía no logro pasar las 70 naves aterrizadas.

AirChief

¡Feliz año nuevo!

drunkmonkey Se termina el año… se terminó. Un año en el que los vientos de cambio han soplado bastante fuerte para mí, tanto en lo personal como en lo profesional, y del que no puedo quejarme.

Espero que la hayan pasado tan bien como yo, y que si no fue así que el 2010 empiece y termine mejor.

Felicidades a todos, ¡nos leemos!