Combinando teoría y práctica.

La teoría es cuando crees saber algo, pero no funciona. La práctica es cuando algo funciona, pero no sabes por qué. Los programadores combinan la teoría y la práctica: Nada funciona y no saben por qué.

– Anónimo (visto en Mundo Geek).

Lecciones aprendidas.

En este caso no por mí sino por Sriram Krishnan en Microsoft. Las resumo aquí copiando y pegando los títulos (el resaltado es mío), algunos frases poderosas sin lugar a dudas, de esas que es bueno tener pegadas en las paredes de la oficina:

• Ask for forgiveness, not for permission
• (Most) Screw ups are OK
• Look for the line at your door
• Code is king
• Lone wolf syndrome
• Try out stuff
• New team? Pick people over products
• Get out of your comfort zone
• Ask the uncomfortable questions
• Go say ‘Hi!’
• Praise in public, pull down pants in private
• Best things are taken, not given
• Don’t be an asshole

El desarrollo en la entrada original, imperdible.

Mejor tratála con cariño…

…porque si no…

Computerfightsback
por sk711

Visto en Abadía digital.

40 ejemplos de manipulación de imágenes.

No me termina de convencer Popego, pero hay que reconocer que de vez en cuando le pega a algo interesante (aunque raramente dentro de las categorías que hacen al hilo principal de este blog).

En este caso de descolgó con una muy buena recopilación de imágenes surrealistas creadas a partir de capturas fotográficas… y mucho talento para el Photoshop.

Para muestra van algunas de mis preferidas:

Entrada original: 40 Examples of Incredible Photo Manipulation.

Lo que sabemos que sabemos, lo que sabemos que no sabemos, lo que no sabemos que sabemos y lo que no sabemos que no sabemos.

Hay aquí alguien a quien nunca pensé que podría citar –seriamente- en este blog: Donald Rumsfeld. Parece que el tipo se da aires de poeta, y que encima no es tan malo:

The Unknown
As we know,
There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don't know
We don't know.

—Feb. 12, 2002, Department of Defense news briefing

El poema fue mencionado en el recientemente muerto y resucitado Coding Horror (por cierto, qué vergüenza. Es brutalmente cierto aquello de “En casa de herrero cuchillo de palo” y “Haz lo que digo mas no lo que hago”).

Jueguitos de viernes

Si remontaron el rastro del Breakdown del otro día ya han descubierto otros dos jueguitos convenientemente camuflados, Leadership y Cost Cutter. Para aquellos demasiado perezosos (u ocupados) como para seguir aquel link va esta actualización.

Leadership: Sí, esto de acá abajo es un juego de naves espaciales en el que tendremos que maniobrar peligrosamente entre las series de un gráfico de líneas.

Y este otro es Cost Cutter, en el que tenemos que evitar que las barras progresen hasta el final del gráfico destruyendo bloques de colores.

Bueno, los dejo, realmente estoy muy ocupado ahora.

Monkey Business.

Son casi humanos... somos casi monos, mejor dicho.

Visto en La Pastilla Roja

Me deja pensando, al trasladar la situación a nuestra vida laboral, en que –si bien entre otros factores- las reglas de juego tienen un peso fundamental para determinar si será la colaboración, la competición o la indiferencia la característica predominante en un entorno de trabajo.

En todo caso estoy bastante seguro de que las reglas pesan más que las características personales. Somos ante todo animales sociales –al punto en el que sólo sobrevivimos en sociedad-, mucho más influenciables por los que nos rodean que –en conjunto- ellos por nosotros.

¿Se pueden alcanzar altos niveles de calidad –esa esmeralda perdida- en el desarrollo de software sin colaboración, sin verdadero trabajo de equipo? Yo creo que sí, pero es mucho, muchísimo más difícil que en un ambiente colaborativo.

Los costos de un ambiente de “indiferencia” en el que cada uno “sólo hace lo suyo” se ven reflejados en complejas estructuras de control superpuestas que coordinan el trabajo: líderes de esto y gerentes de lo otro, supervisores de lo de más allá y más acá, capas y capas de jefes de jefes cuyo trabajo es apenas un poco más que distribuir información y controlar el correcto ensamblaje de subproductos que se construyen en la base de la pirámide aisladamente, sin visión de conjunto.

Se podría decir que parte del trabajo de esa jerarquía es, justamente, proporcionar una visión de conjunto. El problema es que, para el momento en el que el flujo de trabajo llega a ese nivel de revisión es un poco demasiado tarde para cambiar nada.

Para el momento de revisar la calidad –siguiendo las metodologías tradicionales- ésta está prácticamente determinada –sí, claro que podemos corregir desvíos funcionales… ya sabemos lo que sucede con la calidad del código durante esas correcciones-. Si el producto no cumple con las expectativas –de calidad, no sólo las de cumplimiento de requisitos funcionales- la única solución real es el retrabajo.

La solución propuesta generalmente es dividir el desarrollo en pequeñas etapas y revisar la calidad en cada una de ellas –siempre al final- con la esperanza de que la “suma de las calidades” sea provechosa –siempre al final-, y si así y todo las etapas presuponen productos demasiado amplios, las subdividimos… y luego ponemos a un responsable de cada división y de cada etapa, y ya estamos donde empezamos: jefes de jefes de jefes y poco trabajo real.

En un ambiente de colaboración las cosas son diferentes. La revisión es constante porque nadie es indiferente a lo que lo rodea. Cada corrección es mínima pero se dan constantemente. Es mucho más probable que la calidad final sea –para bien o para mal- toda la que el equipo pudo dar en un momento determinado. En esta situación el retrabajo cobra otro sentido: no es la corrección de lo que –en teoría- podría haberse hecho bien desde un principio sino la materialización del aprendizaje acumulado en el camino.

Pero son las reglas las que determinan si esa colaboración es posible. Si la ruta, -correcta o no, eso se verá al final- está predeterminada a través de un diseño milimétrico, el combustible de horas/hombre está calculado como para llegar con el tanque vacío y encima el vehículo no tiene ventanillas de poco sirve ponerse a pensar si hay o no un árbol en el camino, más vale rezar y esperar que cuando nos bajemos estemos en donde queríamos estar. ¿Parece difícil, no?

Reuniones técnicas…

…en las cuales el arquitecto explica a la audiencia la estructura del sistema en el que luego deben meter los dedos:

(gracias a Nicolás por apuntarlo)

Jueguitos de Viernes: Penguins Attack

Uno por el que vale la pena reflotar la sección… Penguins Attack es un clásico del estilo “tower defense”: hay que ubicar, mantener y actualizar diferentes tipos de armas que disparan automáticamente para impedir el paso de las tropas enemigas.

Los últimos que había encontrado en este estilo ya eran demasiado complicados para mi escasa capacidad de concentración y procesamiento… Penguins Attack es perfecto para cortar 15 o 20 minutos.

Visto en Juegos Microsiervos.

Invitaciones para Google Wave

Tengo invitaciones a Google Wave. A falta de algo mejor que hacer con ellas (no más sugerencias, gracias) serán repartidas entre los 10 mejores links (si tienen algo que ver con desarrollo de software, mejor) que se dejen en los comentarios de esta entrada. Autobombos bienvenidos.

El “jurado” de este “concurso” (bueh…) está conformado exclusivamente por mí, y la consigna se mantiene mientras haya una cantidad razonable de links para revisar. Actualizo esta entrada cuando se cierre.