Las dos caras de la mudanza.

Día de mudanza. Un día con muchos baches y tiempos muertos para algunos...

(Esperando que lleguen los camiones...)

Y de trabajo tedioso para otros:

(Tejiendo la red corporativa. Es maraña de cables me daba mareos.)

Soñando recursivamente.

Los verdaderos programadores sueñan en recursivo.

Frase del día en Picando Código.

Es claro que por eso es que me cuesta tanto levantarme temprano y llegar a tiempo al trabajo, ¡soy un verdadero programador!

Lo que nos dice el entorno físico acerca del equipo de trabajo.

¡Después de muchos amagues, nos hemos mudado de oficina! Realmente muchos, pero muchos amagues. Recuerdo con cierta ironía que estábamos "a punto de mudarnos a la fábrica" cuando entré a esta empresa, hace más de dos años.

Bromitas aparte, esto me ha llevado a la reflexión sobre el entorno físico del equipo de desarrollo.

Los seres humanos nos adaptamos, y eso se nota cuando nos cambian el escenario. No me había dado cuenta hasta que punto la oficina anterior era poco amable para el desarrollo de software: estaba encerrada (no tenía ventanas al exterior... de hecho no tenía ventanas), polvorienta (tenía una alfombra milenaria), y era un lugar común de paso, ya que si bien un pasillo la rodeaba, es inevitable que la gente tome el camino más corto.

Pasamos a una oficina muy luminosa (extremadamente, tanto que tendremos que ajustarla un poco), ventilada y fresca y un poco más pequeña, aunque con una vista amplia. Nadie entra si no es para algo (aunque hoy ha sido en general para molestar o hacer turismo por las nuevas instalaciones), y, sobre todo, no tiene esa suciedad "por defecto" que se acumula en un ambiente con superficies ideales para el archivado de mugre y polvo (alfombras, empapelados, zócalos, conductos de ventilación) luego de largos años de uso cotidiano.

Así que muy contento con el cambio, en lo personal. Pasada la intro, vamos al tema.

Es interesante ver cómo la disposición de los elementos físicos refleja la ideología, la visión sobre el trabajo de quien los dispone. Uno de los primeros inconvenientes que notamos fue que algunas de las tomas de red y eléctricas estaban dispuestas contra la pared y a la altura de los ojos.

El mensaje que se transmite es claro: los escritorios se colocan contra las paredes (uno queda sentado mirando hacia ella), de manera tal que todo lo "enchufable" queda cerca y a mano de los conectores correspondientes.

Supongo que algo de control de los monitos picateclas hay detrás de eso, ya que es claro que todas las pantallas dan hacia el centro y uno no puede saber quién está detrás, así que resulta medio engorroso ponerse a leer un mail personal o distraerse 5 minutos con el periódico.

También tendrá que ver con el hecho de que ahora estamos en una fábrica, y ésa es la disposición "por defecto" de los puestos: la altura de las tomas permite enchufar y desenchufar equipos cómodamente (cosa que imaginarán que nosotros hacemos... una o dos veces por año, si se nos rompe la máquina).

El tema es que así todos quedaríamos dándonos la espalda, de manera completamente antinatural, contraria a (y perjudicial para) nuestra forma de trabajo.

Para el caso, nuestra reacción fue un simple "que incómodo, esto no está pensado para el trabajo en equipo", y listo. Era claro que se trataba de una incomodidad, ya que no adoptaríamos esa configuración por más sugerida que esté por las tomas de electricidad y red.

Hablando de desarrollo de aplicaciones, no se trabaja en equipo porque uno quiere, sino porque de otra forma es imposible. Es decir, no es que el ambiente debe facilitar el trabajo en equipo (aunque es recomendable que lo haga), ya que esto no es necesario: la naturaleza misma de nuestro trabajo implica comunicación, interacción y trabajo en equipo.

Esto se hace patente cuando las relaciones personales entre miembros del staff no son buenas. Se sufre justamente porque uno se ve obligado por necesidad a trabajar en equipo y coordinar con personas con las que no congenia en lo personal. Pero no hay elección posible. O todos nos adaptamos mutuamente (lo que puede implicar someterse a la jerarquía aún en discordia), o el trabajo no puede hacerse.

No es el caso de nadie en este equipo en particular, pero conozco de personas que realmente no se llevan con sus compañeros, interactúan lo mínimo e indispensable y sólo sobre temas relacionados con la tarea. Así y todo, es claro que la interacción es constante: hay que preguntar, diseñar, intercambiar opiniones, ponerse de acuerdo... o pelearse todo el tiempo hasta que finalmente alguien se imponga a la fuerza, lo que de todas maneras implica interacción constante.

Resumiendo: el ambiente, debería facilitar el trabajo en equipo, y lo mínimo indispensable para poder desarrollar es que no lo impida.

Nos ubicamos, sin tener que ponernos demasiado de acuerdo, en la disposición clásica de los equipos de desarrollo, mirando al centro, con las variaciones que el ambiente nos impuso (de todas maneras logramos una comodidad para la comunicación cruzada más que aceptable).

La oficina refleja bastante de nuestra ideología y metodología de desarrollo, que podemos resumir como: a) Tenemos que trabajar en equipo, por lo que b) podemos adaptarnos al ambiente en otros puntos, pero en éste en particular el ambiente debe adaptarse a nosotros. Así que unos cables cruzados de forma poco estética no son excusa.

Paseando luego por las instalaciones, veo que los ejemplos surgen de todos lados: el ambiente se adapta a la tarea. La disposición de los puestos en la fábrica hacen que las materias primas entren por un portón y pasen por una serie de puestos en forma circular hasta salir por el mismo portón, que da hacia el patio de descargas, y así con todo.

Me sorprendió ver que el sector de bajo nivel se ubicó como describía antes: todos mirando contra la pared. No sé mucho de su día a día, pero es claro que necesitan espacio al medio (para probar con equipos mecánicos que son grandes), enchufar y desenchufar continuamente, esas cosas. En todo caso también es claro que la comunicación cruzada pasa a un segundo plano frente a otras cuestiones.

Me despido con una imagen que resume las actitud típica del programador en días de mudanza, movimiento o reparación de equipos, corte de luz o durante cualquier actividad que lo prive del entorno de desarrollo por unas horas. No están posando ni nada por el estilo. 100% espontánea.

(es broma, ayudamos bastante)

Dibujando... ¿cochinadas? Casi.

Visto en Raro, curioso y gracioso.

Comunicación: aprender a comunicar y aprender a escuchar.

No me canso de machacar con el tema de la comunicación, competencia fundamental como pocas.

En El inconformista este par de artículos conforman un muy buen punto de partida, ideal para programadores huraños inmersos en una burbuja de algoritmos:

• Cómo convertirse en un buen comunicador.
• Aprender a escuchar.

Que les aproveche.

Hablando de entrevistas laborales... las preguntas más raras del proceso de selección de Google.

Mi propuesta de 5 preguntas para entrevistas de trabajo a programadores queda banal, inocente, suave, amable, juego de niños, en comparación con las que se enumeran en Entrevista en Google - Las preguntas más raras que han hecho.

• ¿Cuantos afinadores de piano hay en el mundo?
• ¿Cuanto deberia llevarte lavar todas las ventanas en Seattle?
• ¿Cuantas pelotas de golf entran en un autobus escolar?
• (la lista sigue, son 17)

No entiendo bien si esto es en serio y tiene una base teórica o algo así, una cuestión publicitaria, un especie de juego (estúpido), o qué. Pero si los empleados actuales de Google son capaces de responder algo así... no entiendo nada.

En todo caso, tengo la respuesta a la mayoría de ellas: ¿y a quién carajo diablos le importa?

Alabanza al trabajo en equipo.

Hace un par de años hubiese respondido (si me hubiesen preguntado) que, como a todo programador, me motiva resolver problemas. Con la aclaración de que tienen que ser problemas útiles, ya que prefiero perder mi tiempo (cosa que también me gusta) de otras maneras.

Por otro lado, si tuviese que escribir mi FODA pondría, del lado de las debilidades:

• Si bien me gusta resolver problemas, una vez que los tengo resueltos "en mi cabeza" la implementación (picar código) me aburre, sobre todo cuando la veo "trivial" (nunca lo es, pero hay veces que se percibe así).
• Me cuesta trabajar aburrido, se me hace muy cuesta arriba, me es casi imposible.
• Pierdo el interés velozmente, sobre todo cuando no tengo resultados inmediatos (por más mínimos que sean).
• Y cuando pierdo el interés, me distraigo muy fácilmente (si bien puedo retomar un hilo suelto de hace meses casi sin dificultad).
• La constancia no es uno de mis fuertes, en resumen.
• Y la auto-organización... puff... menos que menos.
• Y muchas otras cosas. Pero estos son los relevantes, que tampoco es momento de sacar todos los trapitos al sol.

Cuestión que he pasado la mayor parte de mi vida profesional trabajando casi solo. Si bien tenía gente alrededor (y muy buena), cuando llegaba el momento de trabajar lo hacía solo la mayor parte del tiempo.

En estos años de trabajo en equipo, no esporádico sino diario e intenso, he descubierto que (por lo menos este equipo) complementa perfectamente esos puntos, que son los que más me molestan.

• Una vez resueltos los problemas de palabra la implementación se divide, así que no tengo por delante una montaña de funcionalidades que implementar antes de ponerme a pensar de vuelta. Por otro lado, meto la cuchara en cuanto plato se cruce por ahí, así que eso me mantiene entretenido.
• La complejidad también se divide y a cada uno le toca según su nivel o experiencia, por lo cual rara vez tengo tareas excesivamente sencillas o imposibles (aunque hay algunos cadáveres dando vueltas por ahí que madre de dios, ¿en dónde no los hay?).
• Pero a veces hay que hacer trabajo aburrido. No hay problema, no necesariamente es el trabajo lo que me entretiene. Usualmente trabajo aburrido es trabajo mecánico, lo que da para hablar, meterse en conversaciones ajenas, divagar, opinar o pelearse. Siempre se dice algo.
• Las asignaciones son relativamente cortas, los resultados más o menos frecuentes (con viento en popa). Si me trabo es sólo cuestión de pedir opinión o ayuda y seguro alguien me saca del pozo rápidamente.
• ¿Distraído, disperso? Nunca falta presión para concentrarse. Y si falta mejor, es que no hace falta concentrarse (no es lo corriente).
• ¿Falta de constancia? ¿Falta de organización? Ésa es la mejor parte: no es mi problema, tengo un project leader que me dice qué tengo que hacer. La organización es siempre deficiente pero existe, y encima descubro que soy bastante bueno organizando las tareas de los demás.
• Me gusta construir catedrales, eso no puede hacerse solo.

Lo demás es secundario aunque necesario para la felicidad laboral: no trabajo gratis, el negocio es interesante (¿qué negocio no lo es? Bueno, hay algunos pocos realmente estancos, éste no es uno de ellos precisamente), ése tipo de cosas.

La evolución de los teléfonos celulares.

L'évolution de la téléphonie mobile
by carlton_banks

Visto en Paranoias :: Humor, videos y chorradas.

La Globalización.

El mejor ejemplo lo tenemos en el caso de la princesa Diana: Una princesa británica con un novio egipcio que usa un celular sueco que choca en un túnel francés en un auto alemán con motor holandés manejado por un conductor belga que estaba curado con whisky escocés. A ellos les seguía de cerca un paparazzi italiano en una motocicleta japonesa. Ella fue intervenida por un médico ruso y un asistente filipino que utilizaron medicinas brasileñas...

Este artículo fue traducido del inglés por un colombiano.

Y ahora lo está leyendo un huevón de cualquier parte del mundo en un ordenador chino sentado en una silla taiwanesa ...

¿Qué tal? ¿Está claro qué es GLOBALIZACIÓN?

Robado del recomendable Raro, curioso y gracioso.

Motivación, motivadores y negociación.

Anda dando vueltas por ahí una pseudo-conversación alrededor de temas laborales tales como motivación, compromiso, proactividad/pasividad, etc. de la cual el link presentado es tan sólo una punta para quien quiera seguirla hasta su origen.

Voy a chapucear un poco, si me lo permiten. Tal vez ayude, y en todo caso no creo que moleste.

Como principio, hablemos de personas. Motivadores grupales... puede que existan, pero esa idea siempre me hizo ruido.

Por otro lado, ¿la motivación está en cada uno? ¿es responsabilidad de la empresa? ¿del empleado? Irrelevante. El punto es: ¿quién quiere que alguien haga qué? Bueno, de ese quién dependerá lograr que ese alguien haga eso, ya que es lo que quiere.

Motivar es, de alguna manera, darle a otra persona lo que quiere para que haga lo que nosotros queremos. Pueden limarse las aristas, pero en el fondo es eso.

Así que la primera pregunta es ¿qué es lo que quiere?

Se dice por allí que una de las cuestiones más difíciles es determinar cuáles son los motivadores de cada persona. Porque cada quien se sentirá más o menos afectado por alguno en particular. Básicamente los motivadores son combinaciones de: poder, para decidir, para mandar, para obtener resultados; prestigio, reconocimiento, atención; orden, hacer las cosas "como deben hacerse", "hacer las cosas bien" y, por supuesto, riqueza, en todas sus formas.

¿Difícil? Es lo más fácil del mundo. Hay que preguntarle.

Lo anterior fue claramente irónico. Pero no tanto. Realmente la mejor manera de determinar qué es lo que motiva a una persona es preguntándole. El problema es que si no lo hacemos en un ambiente en donde esa persona se sienta libre de responder sinceramente obtendremos alguna de las clásicas respuestas enlatadas que todo el mundo conoce y sabe dar cuando es necesario.

Un truco que aprendí con el tiempo es que a veces es más fácil hacer que alguien hable sobre aquello que lo desmotiva que sobre aquello que lo motiva. Es decir, y esto es más o menos universal: nos encanta quejarnos. En todo caso, si alguien no quiere hablar de motivaciones, seguro querrá hacerlo de desmotivaciones, y viceversa.

Incluso cuando obtenemos una "respuesta enlatada" la selección de la "lata" nos dice mucho sobre las motivaciones de la persona. ¿Qué tipo de motivación "enlatada" menciona?

El segundo método es la observación directa. ¿Hablamos de una persona extremadamente ordenada? ¿Obsesivo de la calidad de los resultados? ¿Que todo se haga de determinada manera? Tal vez lo motive "presentar un trabajo bien hecho". ¿Es una persona sociable? ¿Se preocupa por el qué dirán? El prestigio social, el reconocimiento. ¿Es un tipo mandón, con vocación de líder, que quiere algo a toda costa? El poder. ¿Siempre dispuesto a ayudar, apoyando a los demás? El trabajo en equipo, el compañerismo, la pertenencia a un grupo.

El tercer y último método es el clásico prueba y error, y es el más complicado de todos. Implica presentar diferentes zanahorias y ver en cuál se apunta. No es muy recomendable.

Determinada esa cuestión, sin la cual no podemos continuar, tendremos que preguntarnos cómo conseguir aquello que la persona quiere. ¿Poder? Libertad de acción. ¿Reconocimiento social? Honores, premios, o una simple alabanza en público con cualquier excusa. ¿Hacer las cosas bien? Dejarlo que trabaje como quiera, felicitarlo y hacer notar que apreciamos un trabajo bien hecho, por más simple que sea.

Creo que siempre quedan algunos puntos grises.

Este tipo de motivadores no reemplazan al principal de todos en una relación laboral: un salario al menos acorde al mercado. Puede compensarse cierta escasez en la retribución económica con este tipo de cosas, pero... seamos realistas, por la moneda baila el mono.

Por otro lado, hay que tener en cuenta que las negociaciones son constantes, eternas y continuas. Cada parte -empleado y empresa, jefe y subordinado- tomará lo que la otra ceda como una base para ir por más. ¿Eso implica que no hay que ceder nunca? La mejor forma de mantener el status quo no es frenar cualquier reclamo o cambio mientras la presión se acumula, sino balancearse sutilmente de un lado a otro, ora exigiendo, ora cediendo, siempre alrededor del mismo punto.

Negociar. Todo es, finalmente, negociar. ¿Queremos compromiso? Como si fuera una mercadería cualquiera: mitad del pago ahora, mitad al momento de la recepción. ¿En qué moneda se paga? En aquélla que tenga valor para "el motivado".

Escribiendo todo esto recuerdo cuánto aborrezco todas estas "técnicas de manipulación motivación". Tanto más en cuanto más efectivas me parecen... En lo personal, trato de olvidarme de lo aprendido y tratar de ser insoportablemente espontáneo y natural, por lo menos en tanto no me encuentre en posición de tener que negociar la obediencia o el compromiso de los demás (no estoy seguro de querer estar en esa posición, realmente)... El trabajo asalariado es una institución tan perversa extraña... ¿se pusieron a pensar en eso?

Pero eso ya es tema de otro post.

Indexed

Vía Malas palabras caí en Indexed, un blog en el que la autora, Jessica Hagy... no sé cómo describirlo, supongo que ahí está la gracia. A continuación un botón de muestra, el resto véanlo por ustedes mismos.

¿Blogger vs. Reader en un abrazo mortal?

A ver si he entendido bien lo que ha sucedido aquí:

Hace un par de días (por lo menos en la versión en español) se lanzó en Blogger la posibilidad de "seguir" (follow) un blog. Visto desde el otro lado, cada blogger puede instalarse un widget que muestre quiénes son sus seguidores, ese tipo de cosas todo muy 2.0.

Así que hoy ando por aquí, acabo de escribir mi último artículo y estoy procrastinando porque no tengo ganas de hacer nada de lo que tengo que hacer. Voy al panel de Blogger, y casi sin querer importo desde el Reader la lista de mis suscripciones como "blogs a los que sigo".

Error 500 - internal server error.

Bien. Como soy un informático, y gusto de actuar racionalmente, hago lo que debe hacerse ante un error: probar nuevamente hasta que funcione. ¡Y funciona!

Aunque algunos se han agregado y otros no aparecen en la lista. ¿Tendré que agregarlos a mano? Me parece una injusticia para algunos de ellos, ¿a quién no le gusta tener un numerito de "seguidores"?

Resumen hasta aquí: importé a Blogger desde el Reader mi lista de blogs a los que sigo, algunos han pasado, otros no.

Por otro lado, a alguien en Google se le debe haber ocurrido que es muy intuitivo que si agrego un blog a mi lista de "lo que sigo" en Blogger éste debería agregarse en el Reader.

So... a ver, estoy mareado. Importé desde el Reader al Blogger y éste a su vez me agrega la misma lista al Reader...

Debe ser una de las razones del brusco salto de 150 a 300 elementos no leídos en el Reader y de este extraño deja vú que siento al leer los feeds de mis blogs preferidos.

De cualquier manera, supongo que borrando pacientemente los duplicados en mi lista de suscripciones soluciono el problema.

...mffff... por un rato. Los duplicados siguen. Y aparecen más. ¿O estoy confundido?

Google... me parece que la has cascado serio esta vez.

Panqueque System III: El infierno de las preferencias.

Es difícil que un desarrollador que haya trabajado en algún sistema de gestión no se haya enfrentado con esta situación.

Circuitos administrativos hay para todos los gustos. Tenemos los clásicos compras, producción, ventas, facturación, atención al cliente, liquidación de sueldos. También tenemos algunos más infrecuentes, pero de todas maneras muy comunes: presupuestos, importación, exportación, marketing...

Todos ellos han sido descritos, caracterizados y estandarizados extensivamente por la bibliografía de la administración de empresas. Algunos de ellos, por estar atravesados por restricciones legales, son muy parecidos en todos lados.

Pero el problema de las sutilezas existe siempre. Cada empresa tiene las suyas, a veces justificadas, a veces no. Y el momento de comprar un software que gestione el circuito será el de la dura negociación para determinar quién se adapta a quién (la empresa al software o viceversa) y en qué grado.

En Panqueque System II: Un caso de dependencia del cliente apuntaba al caso en el que el cliente requiere customizaciones de tal especificidad que termina quebrando al desarrollo en dos versiones (por lo menos). El problema es casi comercial: se cobran customizaciones pero el cliente domina hábilmente la negociación y termina con un software a medida.

Este caso es sutilmente diferente. Más que de un error comercial, estamos hablando de un vicio funcional.

Los analistas funcionales, en su contacto cotidiano con diferentes clientes, son caldo de cultivo para esas pequeñas variaciones orientadas a demostrarle a cada cliente que el software se adapta perfectamente a sus necesidades.

Tomadas individualmente cada una de estas variaciones parece inofensiva, fácil de implementar y con una relación costo-beneficio ampliamente favorable. El cliente siente que el producto le calza como un guante. Cada vez que durante la demostración él apunta a cuestiones como "ah, nosotros requerimos que el gerente apruebe el pago para los mayores a..." podemos responderle "eso es configurable aquí".

Finalmente, todo termina siendo configurable allí (en esa pantalla infernal con 200 opciones que se activan y desactivan unas a otras). Que si tal funcionalidad está desactivada tal pantalla no tendría que verse, que si el módulo tal no está activo los datos tendrían que mostrarse de tal manera o de tal otra... Que los vendedores a veces pueden y a veces no pueden, que los descuentos a veces son fijos o pueden ser variables o...

Cada una de estas variaciones aporta su granito de arena para hacer de la gestión de configuración un absoluto desastre.

Lo divertido es -esto le he visto ya en varias ocasiones- cuando la combinatoria de estas opciones a veces sutilmente incompatibles unas con otras, resulta en comportamientos completamente insospechados. O cuando para activar ésta se necesita activar aquélla y para activar aquélla necesito esta otra que requiere la primera... una especie de abrazo mortal.

Y ni hablar de cuando se pretende incorporar nueva funcionalidad. El desarrollador que esté a cargo del nuevo módulo o pantalla puede verse involucrado en uno de dos infiernos: o se encuentra con una larga lista de opciones y variaciones pre-existentes que está comprometido a implementar, o (esto es tal vez peor), no hay documentación clara sobre alguna o ninguna de ellas o de la relaciones entre todas y se va enterando sobre la marcha o durante el testing.

En el primer caso, se genera una sobrecarga tal que la más mínima funcionalidad agregada insume un número aparentemente desproporcionado de horas. Pero por lo menos esto puede estimarse. Es un problema, y es conocido. En el segundo caso -la falta de documentación-, el desarrollador se va enterando sobre la marcha, con la sensación de ir retrocediendo a cada paso. Si había estimado 4 horas, luego fueron 8 y luego 16 y luego...

¿Soluciones? Ninguna es categórica. Cuándo incorporar una variación que surge del circuito administrativo de un cliente en particular es siempre es una relación de costo-beneficio. Los beneficios son instantáneos y los costos a mediano y largo plazo.

¿Podemos decir que no? Dependerá de qué tan importante sea la "sutileza" para el cliente y de qué tan importante sea el cliente para la empresa. Lo que es imposible de explicar (de cara al cliente) es que de alguna manera la calidad del producto puede verse comprometida.

Desde lo técnico el nudo de la cuestión estará en crear una arquitectura en la cual se puedan establecer cambios de comportamiento en forma global, de manera tal que el programador no tenga que estar al tanto de estas variaciones al momento de codificar. Esto no siempre es posible, y si lo es, lo será sólo en cierta medida.

Y desde lo metodológico, la simplificación: no sólo implica hacer más simple el código existente, sino retirar lo que no es frecuentemente utilizado. Este punto es al que se le suele restar importancia. Un producto con algunos años y versiones sobre sus espaldas puede estar cargando con un sinfín de posibilidades que ya nadie utiliza.

De cualquier manera, lo importante no es evitar el infierno de preferencias, dado que éste infierno, si está controlado, puede ser el que incline la balanza hacia nuestro favor al momento de ganar clientes. Lo importante es que la parte comercial y funcional del proyecto o la empresa sea consciente de la forma en la que sus decisiones afectan al producto.

Varias veces el equipo de desarrollo se encuentra con que se han aprobado customizaciones u opciones sin ningún tipo de consulta previa. No es una cuestión de "querer estar en todo", pero... ¿Si no se ha consultado al área técnica, sobre qué bases se ha decidido que lo que se cobra o ingresa por la customización es mayor al costo actual y futuro de la misma?

Los artículos de la serie:

Panqueque System.

Panqueque System II: Un caso de dependencia del cliente.

Jueguitos de viernes: Electricman2HS

Llego un poco tarde, no creo que le arruine el viernes a ninguna empresa, pero en una de esas sí el fin de semana a más de uno.

Electricman2HS es un simpático y terriblemente adictivo juego de lucha. Que les aproveche.

5 preguntas para entrevistas de trabajo a programadores.

Son usuales las quejas cruzadas entre entrevistados y entrevistadores cuando se trata de puestos orientados a la programación.

Los primeros apuntan al escaso entendimiento técnico del entrevistador, a su apego a una lista incongruente o inútil de preguntas o a un cuestionario del tipo examen multiple choice sobre detalles técnicos que -por suerte- internet nos ha relevado de recordar, entre otras.

Los segundos recalcan cierta altanería de la gente del sector (en épocas de vacas gordas), poca o mala predisposición a hacerse entender cuando se rozan temas técnicos y sobre todo un tufillo a desprecio por cualquier competencia más allá de las puramente técnicas: puntualidad, presencia, formalidad, comunicación, etc.

Que para muestra baste un botón, aunque tengo la sensación de haber leído varios ejemplos más estos días.

Me he puesto a imaginar qué preguntaría yo en calidad de entrevistador. Aclaro que no tengo mucha experiencia como tal, aunque sí bastante de entrevistado. Éste es un seleccionado armado a partir de las preguntas que recuerdo, más algunas modificaciones.

0. El saludo, la mirada, la ropa, todo eso.

No me considero muy capacitado para examinar estos detalles en fino, así que dejo los consejos al entrevistado a cargo de los expertos.

Lo que sí puedo mencionar es un par de puntos que ayudan a ubicarse y a ver mejor al entrevistador "desde este lado": si no tiene conocimientos técnicos hay que aclararlo de entrada (el entrevistado debe poder y saber ubicarse). Tener tiempo disponible, prestar la debida atención, interrumpir con amabilidad, no discutir y en lo posible tampoco expresar desacuerdos (vale para entrevistados, también: dejar que el otro se entierre sólo). Si viene al caso, exponer las razones del desacuerdo una sola vez y objetivamente.

1. ¿Por qué buscas un nuevo trabajo?

   Me gusta esa pregunta para romper el hielo, suele ser una de las típicas, por lo que no sorprende al entrevistado (¿para qué hacerlo sentir incómodo?) y su respuesta nos brinda un panorama de sus principales motivaciones, gustos y preferencias. También pueden observarse detalles interesantes: ¿No está dando una respuesta "de compromiso"? ¿Parece tenerla preparada?

   Una búsqueda de trabajo necesariamente implica algún tipo de malestar respecto de la situación actual -creo-. ¿Parece sincero al expresarlo?

2. ¿Cómo es el proyecto en el que trabajas o el último en el cual has participado?

   Puede ser personal o laboral (habrá que ver hacia dónde apunta). ¿Es correcto en la utilización de las palabras técnicas? ¿Se esfuerza y logra evitarlas cuando su interlocutor no tiene suficientes conocimientos? ¿Puede resumir un proyecto complejo en unas pocas palabras?.

3. ¿Cuál es el problema más difícil al que te has enfrentado y cómo lo has resuelto (si lo has logrado)?

   De vuelta habrá que ver si logra ubicarse y hacerse entender sin entrar en excesivos detalles. También está el tema de la sinceridad: puede que no haya logrado resolver el problema sólo, o que no lo haya hecho en lo absoluto. Es una forma de explorar sus recursos: ¿utiliza internet? ¿bibliografía? ¿pide ayuda a otras personas o prefiere investigar por su cuenta? Resolvemos problemas todo el tiempo, y en todo desarrollo habrá algo, por más mínimo que sea, que nunca hemos hecho.

4. ¿Podrías escribir un breve resumen de (lo que es o de lo que te imaginas que es) un día de trabajo "normal"?

   Todos los programadores podemos leer y escribir código. Más fácil, más difícil, más o menos enmarañado, eso sólo implica más o menos tiempo y esfuerzo para entenderlo, finalmente sabremos qué es lo que hace. Por otro lado, el código es un tema que probablemente el entrevistador no esté capacitado para evaluar.

   ¿Pero puede escribir decentemente en lenguaje natural? En el quehacer cotidiano hay mucho que escribir aparte de código: hay que producir comentarios, documentación, notas o pautas de diseño que otras personas (o uno mismo luego de mucho tiempo) deben poder decodificar. También hay que reportar errores, intercambiar correos sobre cuestiones complicadas, a veces comunicarse directamente con personas ajenas al equipo.

   Éste es para mí uno de los puntos más importantes (ver Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir). Una nota mal escrita hace un mes implica rehacer todo un trabajo de investigación por no poder decodificarla. Un error mal reportado no puede corregirse. Una tarea mal especificada o mal decodificada son horas o días de trabajo perdido. Un mail hacia fuera del equipo con faltas de ortografía -o directamente incomprensible- es motivo de bochorno para el equipo o la empresa... ¡y ni que hablar de un error de ortografía en un mensaje de la aplicación!

   De más está decir que quien escribe correctamente suele leer más que correctamente, por lo que con este breve examen abarcamos todo.

   Ok, no tiene que ser Borges, pero... El contenido también demostrará qué es lo que espera de un día de trabajo "normal", qué situaciones le parecen comunes, y permitirá compararlo contra el ambiente en el que efectivamente se desenvolverá.

5. Una situación hipotética...

   Creo que ésta es una pregunta que se hace mucho, con sus variaciones. Comienza con una historia breve: "Tienes tu primera tarea asignada, eso implica demostrar de qué eres capaz. Ves que no estás logrando resolverla en tus horas normales de trabajo. De seguir así no cumplirás con los tiempos comprometidos"... ¿Qué haces?

   ¿Avisa? ¿Se queda hasta más tarde hasta resolverla? ¿Busca ayuda? ¿A un compañero, al jefe, a quién? ¿Intenta ocultarlo?

Creo que con esto se cubre más o menos explícitamente todo lo importante para un programador, más allá de lo técnico, y en las respuestas y en los modos está el resto.

¿Qué les parece? ¿Alguno de uds. tiene su propio método?

Estimaciones y responsabilidad.

Me han quedado dando vueltas por el fin de semana las cuestiones que planteaba en el último artículo, Estimaciones y compromisos.

Por un lado lo he charlado un rato con los colegas del trabajo. También se lo he referido a Yuki en su blog De consultor a Director de TI. Pueden ver su respuesta en los comentarios de esta entrada.

Quisiera desarrollar el tema de la responsabilidad, que surge de la transformación de la estimación en un compromiso, situación comentada en La masa, el ladrillo, la bota, el bocadillo... de la siguiente manera:

Generalmente cuando recibimos estimaciones es porque nos encontramos en una situación de autoridad dentro del proyecto y nunca debemos olvidar que la autoridad conlleva responsabilidad. Somos responsables de cómo tratamos estas estimaciones. Y la máxima es clara: No conviertas las estimaciones que recibes en compromisos.

Desarrollando esa idea, desde el punto de vista de los desarrolladores que elaboran esas estimaciones, había escrito:

¿Somos responsables del error? Del error de asumir el compromiso en ciertos términos, quiero decir. No digo del error de estimación, ya que no considero que la estimación sea errónea (¿lo es?). Por más desviada que esté, ese desvío refleja nuestro desconocimiento al momento de hacerla. Creo que no es lo mismo que un error (que sí sería uno de cálculo por ejemplo).

El hecho de si una estimación fallida es un "error" o no es una cuestión casi teórico-filosófica. El hecho es que el proyecto se encuentra desviado respecto de ella, y punto.

En las causas del desvío pueden converger un sinfín de factores. Tiendo a pensar ahora que el de más peso es la falta de experiencia. Estamos estimando, y obviamente no tenemos información completa. De todas maneras, toda información está referida al pasado, a un contexto diferente y en situaciones que no tienen garantía de repetirse. Pretender lo contrario sería requerir una bola de cristal.

Estimamos entonces utilizando nuestra experiencia. Y ponemos en juego nuestra habilidad para extrapolar esas situaciones al futuro, reconociendo similitudes y diferencias y tratando de asignarles un valor en horas.

¿Y si no tenemos experiencia? Bueno, por algún lado se empieza. Prueba y error, y probablemente al principio sean todos errores.

Ahora, el tema de la responsabilidad. En un proyecto cerrado hay que comprometer una fecha con el cliente. Esto es inevitable y razonable, son las reglas del juego. Es un compromiso que no puede eludirse.

Entonces, ante las preguntas que había planteado:

¿Nos hacemos cargo del compromiso asumido, dado que no hemos sido nosotros quienes lo hemos hecho? ¿Cómo? ¿Trabajamos más horas? ¿Aceptamos hacerlo gratis? ¿Hasta qué punto?

Creo que la primera respuesta es sí. Nos hacemos cargo del compromiso, porque no podemos pretender que ignorábamos las reglas del juego al momento de estimar. El tema es cómo.

Tenemos la responsabilidad de llegar a determinada fecha. Y de ser imposible, tenemos la responsabilidad de avisar apenas seamos conscientes de este hecho. Responsabilidad no implica hacer lo imposible, sino hacer todo lo posible.

¿Y qué es "todo lo posible"? Ahí está el punto. Sólo cada uno de nosotros sabe qué es lo que está dispuesto a dar. "Todo lo posible" es, en lo material, muy diferente para un joven recién egresado (digamos que vive solo y sin muchos compromisos familiares) y para una persona casada y con hijos (sobre todo) que siente una responsabilidad "de estar presente" mucho mayor para con ellos. Es, en todo caso, un tema personal.

Lo que no es personal es el compromiso para con el equipo. Que se traduce en dejar en claro de qué manera y bajo qué condiciones estamos disponibles. Se trata de volvernos previsibles, de dar predictibilidad al proyecto, de dar toda la información (incluso aquélla que nos deja en una situación incierta) que tenemos disponible para que los responsables formales puedan tomar una decisión.

Se trata, en definitiva, de ayudar a tomar una decisión con respecto al camino a seguir de forma que podamos estar de acuerdo con ella y apoyarla. Y si no podemos estar de acuerdo y acompañar, se trata de explicitarlo y asumir las consecuencias.

Es, por otro lado, no ceder ante la presión aceptando de palabra una situación que luego, en los hechos, no toleraríamos. Hacerlo sería mentir, engañar. Me imagino, por ejemplo, el clásico lugar común en el que un integrante del equipo "dice que sí a todo" y mientras se busca otro trabajo (pura imaginación, aclaro, es sólo un ejemplo). Esto último sí me parece moralmente reprochable. Es planear "con premeditación y alevosía" bajarse del proyecto mientras se lo envía con rumbo desconocido.

En resumen, ¿cuál es nuestra responsabilidad ante un desvío, error o como se llame en la estimación? Avisar y ser abiertos y sinceros al momento de buscar los caminos de acción posibles, dar información confiable. Creo que es un compromiso más razonable que el aceptar trabajar 15 horas al día sólo para decir, cuando todo se vaya al diablo, "yo hice todo lo posible".

Esta imagen me recuerda algo...

¿A uds. no?

La nueva burbuja .com

No puedo dejar de verlo y reírme. Es MUY bueno.

Visto en Picando código.

Actualización: encima se me pegó la canción.

Finales violentos para los clásicos de dibujitos animados.

¿Y si por una vez ganara el coyote? ¿O Silvestre? ¿O Tom?

Hay más. El resto en Paranoias.

Jueguitos de viernes: Don't Shoot the Puppy

Me encantó este jueguito que descubrí en Esquizopedia.

Advertencia: es de esos para perder el día, así que ya saben... con responsabilidad.

Estimaciones y compromisos.

Hace un par de días que venía con la idea de escribir al respecto, sin encontrar el hilo. Leyendo La masa, el ladrillo, la bota, el bocadillo... encuentro que en el artículo Recibiendo estimaciones se escribe exactamente lo que yo quería transmitir. Algunos extractos (y sigo escribiendo, no se me vayan todavía):

Generalmente cuando recibimos estimaciones es porque nos encontramos en una situación de autoridad dentro del proyecto y nunca debemos olvidar que la autoridad conlleva responsabilidad. Somos responsables de cómo tratamos estas estimaciones. Y la máxima es clara: No conviertas las estimaciones que recibes en compromisos. [resaltado en el original][...]

El otro aspecto a tener en cuenta es que convirtiendo estimaciones en compromisos dañamos la confianza de quien nos dio la estimación. Al fin y al cabo solo estaba estimando y nosostros sin embargo ¡hemos convertido su estimación en un compromiso!. Desde luego no estamos estableciendo las bases de una relación basada en la confianza. Y sin la confianza de los implicados en el proyecto nunca lograremos encontrar información veraz en la que basar la gestión del proyecto.[...]

La pregunta que planteo es qué posturas podemos o debemos tomar, como desarrolladores cuando notamos (es imposible no hacerlo) que estamos muy desviados de lo estimado, si se han asumido compromisos (a más alto nivel jerárquico) basados en esas desviadísimas estimaciones.

¿Somos responsables del error? Del error de asumir el compromiso en ciertos términos, quiero decir. No digo del error de estimación, ya que no considero que la estimación sea errónea (¿lo es?). Por más desviada que esté, ese desvío refleja nuestro desconocimiento al momento de hacerla. Creo que no es lo mismo que un error (que sí sería uno de cálculo por ejemplo).

¿Nos hacemos cargo del compromiso asumido, dado que no hemos sido nosotros quienes lo hemos hecho? ¿Cómo? ¿Trabajamos más horas? ¿Aceptamos hacerlo gratis? ¿Hasta qué punto?

¿Es reprochable si no queremos hacerlo, por las razones que sean? Aunque no sea gratis, ¿por qué debería sentirme o estar obligado a un sacrificio personal? Usualmente se dice que uno elige hacerlo, por ejemplo por razones monetarias o políticas -quedar bien con los superiores, un ascenso, etc.-... elegir implica poder decir que no. ¿Y si decimos que no?

Me imagino que si luego de un gran esfuerzo se llega (tarde pero menos que de seguir normalmente), el diferencial pasa desapercibido. Al fin y al cabo todo ha sido entregado a destiempo y a los apurones, a veces con sacrificios de calidad. Hemos "sacado las papas del fuego" sin ningún reconocimiento extra por ello, de ningún tipo... y ahora tenemos otro muerto esperándonos en el mantenimiento.

Cuando uno realiza un trabajo independiente, por ejemplo, las cosas son más claras. Uno asume todo el compromiso. Pero la relación laboral tiene para con el empleado un compromiso acotado... en los papeles. Esto varía mucho de acuerdo con el contexto económico.

Está en la balanza el querer que a la empresa le vaya bien, aunque no a costa nuestra... querer sacar el proyecto adelante, pero no regalar méritos ni levantar muertos ajenos... hacer esfuerzos pero no sacrificios...

Releo y veo que las preguntas redactadas pueden parecer una toma implícita de posición. Yo aclararía que reflejan más bien un estado de ánimo, que como todo ánimo es circunstancial.

Sé que algunos de los lectores de este blog se desempeñan como líderes de equipo, de proyecto, de área o de lo que sea. Mis opiniones se fundamentan puramente en la teoría, que conozco bastante bien a través de la preparación de mis clases. Pero quisiera conocer sus opiniones que además de la base teórica se sustentan con la práctica y el pragmatismo del día a día.

Ahora sí, los dejo que sigan con el resto del post referenciado.

Actualización: Le referí el post a Yuki en un comentario de su entrada 30 - Mi quinto cliente : Los malteses (III), anécdotas y reflexiones, quien responde con sus opinión al respecto (¡gracias!).

El tema sigue en Estimaciones y responsabilidad.

Los candidatos a presidente de USA con sus respectivos teléfonos.

No puedo parar de reírme con esta imagen, levantada de Esquizopedia. Sin palabras.

La biblia del desarrollo de software.

Frederick Brooks

Algunos parrafitos robados citados de Las bases de la gestión de proyectos software y los mitos del "hombre-mes", comentario en kybele consulting del mítico libro de Frederick Brooks:

Brooks (1931) fue director del desarrollo del famoso OS/360 de IBM, y a raíz de sus experiencias, éxitos y fracasos escribió “The Mythical Man-Month: Essays in Software Engineering” (aqui la reedición 20 aniversaro de 1995), libro al que deben su mayor fama, aunque no suficiente, frases como:

• “Añadir recursos humanos a un proyecto con retraso provocará un retraso mayor”.
• “En un proyecto la figura del arquitecto software es esencial”.
• “Medir el progreso de un proyecto en función del tiempo que lleva desarrollándose es un error”
• “¿Cómo puede un proyecto acumular un retraso de un año?... acumulando retrasos día a día”.

[...]

El libro de Brooks es de 1975, y lo más curioso es como más de 30 años después afirmaciones como las anteriores son muy poco conocidas así como frecuentemente incumplidas. Ya lo dijo el propio Brooks... "They call this book the Bible of Software Engineering... and that's because everybody reads it but nobody does anything about it!"

CMMI. ¿La calidad del proceso es garantía de la calidad del producto?

Ever been to McDonalds? Bet you didn't know that they are CMM Level five? Does anyone think that McDonalds product quality is high?

Enterprise Architecture
Does CMMi encourage worst practices?

Y relacionados:

desDesarrolloDeSoftware: Formalizar hasta paralizar.

Navegápolis: ¿A mayor nivel de CMMI, menor sueldo?

Kybele Consulting: Una certificación de la calidad de los procesos no siempre asegura un producto de calidad.

Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

A veces me pongo extremista y veo al desarrollo de software solamente como un sistema de comunicación. Si lo vemos como una caja negra, se trata de de transmitir y traducir los requerimientos en una serie de instrucciones que un hardware pueda ejecutar, llevando a cabo la tarea que estos requerimientos representan. Por lo menos idealmente.

Si abrimos esa caja negra, encontraremos varios "puntos de retransmisión y traducción", que más o menos se corresponden con las etapas de relevamiento, análisis, diseño y codificación. Cada etapa nos acerca más desde el lenguaje del emisor (el cliente) al lenguaje del receptor (ese equipo de hardware).

En resumen, los requerimientos son el mensaje, el cliente es el emisor y el hardware que finalmente debe ejecutar la secuencia de instrucciones acorde es el receptor. En el camino tenemos varios retransmisores, algunos humanos y otros no: analistas de negocio, analistas funcionales, programadores, entornos de desarrollo, compiladores, personal de soporte al cliente (al instalar), sistemas instaladores. El mensaje se transmite a través de varias formas y a través de varios medios: oralmente, por escrito, electrónicamente.

Bajo esta óptica, somos retransmisores al tiempo que traductores.

Como en todo sistema de comunicación, hay ruido de fondo y ruido generado por el propio sistema. Ambos tipos de ruido deforman inevitablemente el mensaje. La comunicación perfecta no existe, por tanto tampoco existe el software perfecto.

Siguiendo por este camino, en el que suelo entretenerme inventando y perfeccionando analogías, llego usualmente a la siguiente conclusión (bombos y platillos):

La calidad del software depende de es la fidelidad con la que el equipo transmite un mensaje, por ello todos los participantes de un equipo de desarrollo de software deben ser excelentes transmisores de información.

De nada sirve ser un experto programador, analista o visionario del negocio si no se puede transmitir fielmente esa información a través del proceso de desarrollo.

Transmitir implica básicamente dos tareas: recibir y enviar. Incluso un programador independiente que trabaja absolutamente solo debe ser un experto escuchando o leyendo al cliente (recibiendo) y programando (enviando).

Recibir es usualmente escuchar, leer. Transmitir es usualmente hablar, escribir.

El problema de escuchar y hablar es que, como se dice coloquialmente, a las palabras (y muchas veces a las personas que las pronuncian) se las lleva el viento.

¡Cuidado! Ahí vienen los pseudo-ágiles: que el exceso de documentación, que la comunicación informal, que los cambios continuos y un largo etcétera.

¿Cuál es la diferencia entre pseudo-agilidad y verdadera agilidad?

En el desarrollo pseudo-ágil no se preserva nada. Llegamos al punto de encuentro con el cliente y estamos solos. ¿Qué pasó? No tenemos idea.

En el desarrollo ágil se preserva solamente lo indispensable: el mensaje, los requerimientos. Es absolutamente minimalista: hay que preservar sólo el mensaje, pero hay que hacerlo como si fuera la vida misma, y verificar continuamente que no haya sido malinterpretado por nadie. Como recalqué muchas veces: tal es así que en XP las historias del usuario las escribe el mismo usuario, y éste es parte del equipo. Creo que solamente por una cuestión legal las cadenas para retenerlo cerca del equipo (que seguramente figuraban en los primeros bocetos) fueron finalmente suprimidas.

Aclarado que tenemos que preservar al menos el mensaje original, los requerimientos, el tema es cómo.

Me agarra el viejazo cuando me vuelvo tradicionalista, pero todavía nadie me convence de lo contrario: el texto es el rey. Es la herramienta más sencilla para el conjunto de actividades que se realizan alrededor de los requerimientos: recibirlos, discutirlos, modificarlos, transmitirlos, catalogarlos, archivarlos, buscarlos.

Pensemos en otros soportes posibles. Omito los puntos "catalogar" y "archivar" ya que con las herramientas disponibles serán sencillos para cualquier soporte.

Los gráficos son más difíciles de producir y modificar, aunque usualmente mejores para discutir y transmitir. La búsqueda no es sencilla, justamente porque contienen poco texto.

En cuanto a imagen y sonido, grabar la descripción de los requerimientos parece una buena idea, pero no me parece un soporte fácil para recibir o discutir, mucho menos de modificar. No me imagino en una reunión diciendo "poné de vuelta esa parte... no... un poco antes... ahí, ¿no debería decir...?" La transmisión es más complicada y la búsqueda sólo puede realizarse bajando el contenido a texto.

Recordemos que hablamos de requerimientos que cambiarán continuamente. A mayor complejidad mayor resistencia al cambio. Y cambio en los requerimientos es moneda corriente.

Así que si me preguntan a mí, texto.

Resumen: habilidades a valorar en un integrante de un equipo de desarrollo (¿o mejor dicho, de un equipo, a secas?): leer y escribir (porque si no a las palabras -o al integrante- se las lleva el viento). ¿Alguna vez los evaluaron en eso en una entrevista de trabajo?

BTW: Menudo título, ya sé, pero estoy cansado de aparecer en cualquier lado por hacer bromitas con los títulos de los post. No lo hagan.

De gurúes y otras yerbas.

Suerte que en estos tiempos de oscuridad en los que se está haciendo complicado escribir algo (y sobre todo aguantar las ganas de escribir algo -lo siento, tendrán que leer entre líneas-) llego a casa y encuentro algo que vale la pena destacar.

En este caso Se lo digo yo, que de esto se mucho, de Un Punto Azul Pálido, luchando en pos del pensamiento crítico.

10+4 cosas que más fastidian a los programadores:

José M. Aguilar refiere en este post de Variable Not Found este otro post de Kevin Pang comentando el resultado de una encuesta al respecto que propuso en Stack Overflow, y agrega 4 puntos "de su propia cosecha".

El que usualmente me suele sacar de quicio es el "experto" en desarrollo de software. Es una de las 4 agregadas por Aguilar, que lo pone muy gráfico:

Clientes, gestores y otros individuos que utilizan frecuentemente, y sin conocimiento alguno de causa, expresiones como "Esto es fácil", "Una cosa muy sencilla", "¿Eso vas a tardar en hacer esta tontería?"....

Acá va la lista de títulos. Los detalles están en los post referidos.

1. Comentarios que explican el "cómo" y no el "qué".
2. Las interrupciones.
3. Ampliación del ámbito.
4. Gestores que no entienden de programación.
5. Documentar nuestras aplicaciones.
6. Aplicaciones sin documentación (entre la anterior y ésta podemos decir "haz lo que digo pero no lo que hago").
7. Hardware.
8. Imprecisiones.
9. Otros programadores.
10. Tu propio código, 6 meses después.

Y sus 4 extras:

1. Requisitos evolutivos.
2. Problemas en el entorno.
3. El "experto" en desarrollo de software.
4. Usuarios corrosivos.

Se ve que el oficio nos saca a todos cortados por la misma tijera, ya que he renegado bastante alrededor de muchos de estos puntos. Iba a hacer mi propia lista, pero ya me he quejado tanto que puedo hacer un post de refritos:

• El infierno de los requerimientos, las indefiniciones, las idas las vueltas, los cambios esquizofrénicos... Comunica... ¿QUÉ?, eXtreme Programming es un arma peligrosa., Requerimientos: cuando no son asteroides sino sólo polvo cósmico.... las panquequeadas: Panqueque System I y II, en suma... División de tareas.
• Problemas en el entorno... Wanda Nara.
• El "experto" en desarrollo de software: No digas "programita".
• Tu propio código, 6 meses después: Antipatrones de diseño.
• Otros programadores... No hagáis esto en casa..., Hay tabla.

Blogger Syntax Highlighter

Cosas de newbie... Hacía tiempo que estaba buscando una herramienta para dar formato a los ejemplos de código en los posts. El problema, como siempre, son las palabras. No daba con ellas para la búsqueda.

Bien, hoy casualmente me entero del nombre de este tipo de cosas, Syntax Highlighter (sinceramente mi inglés no daba para tanto, jamás se me hubiese ocurrido). Encontré uno para blogger en FaziBear y puesto que ya está instalado, vamos a probarlo...

public class CSharpFormateado
{
  public int _mivariable;

  public CSharpFormateado(int mivariable)
 {
   _mivariable=mivariable; //comentarios OK.
 }

 public int MiVariable
 {
   get { return _mivariable;}
 }
}

function MiFuncionJS(arg)
{
  for(var i=0;i<10;i++)
   alert(i + arg);
}

<html>
<body>
<p>
Adoro HTML!
</p>
</body>
</html>

Actualización: Funcionó para c#, pero no para javascript o html. RTFM...

Actualización 2: Parece que el atributo "name" de los "pre" que envuelven al código debe ser "code" sí o sí. Queda entonces:

<pre name="code" class="html">
<!-- Noten la sustitución de < por &lt; -->
&lt;html>
&lt;body>
&lt;p>
Adoro HTML!
&lt;/p>
&lt;/body>
&lt;/html>
</pre>

Actualización 3: No me digan, no funciona en el feed... nada es fácil en esta vida...

Actualización 4: Hasta donde entendí el tema es el siguiente: ninguna solución que utilice javascript para procesar el código de ejemplo va a funcionar en todos lados. Ergo, lo óptimo sería crear una pequeña aplicación (un programita, bah) con la que podamos pre-procesar los ejemplos de código y postear directamente el resultado, evitando hacerlo on the fly... tal vez alguien lo haya hecho ya...

"IPhone vs..." - Resumen de comparativas.

Ahora que se han calmado un poco las aguas con respecto al teléfono de Apple es momento de recopilaciones...

IPhone vs. Palta

IPhone vs. Doblador de tubos

IPhone vs. Ladrillo

IPhone vs. Vibrador

IPhone vs. Piolín+Latas

IPhone vs. Casio

IPhone vs. Nokia 3310

IPhone vs. Piedra

Wanda Nara

(¡me costó encontrar una foto medianamente decente!)

No, el blog no cambió de rubro (por ahora) ni este post es un desesperado intento de SEO (¡dónde mostrará Google este post con esta chica en el título!).

Comencemos por el principio. Habrán notado un brusco parate en el ritmo de publicación que venía sosteniendo las últimas semanas (con mucho relleno, lo reconozco, pero la vida no es seria).

Como desarrolladores, requerimos muy poco de la tecnología para ser felices: una computadora decente, control de código fuente, un buen servidor de pruebas y conexión a internet. Lo demás es siempre bienvenido, por supuesto, pero no esencial.

Sucede que a veces algún problema de infraestructura hace que uno esté trabajando de lo más tranquilo y de repente algo falla. ¿Se cayó el SourceSafe? ¿Rompimos la base de datos? ¿No hay internet? Tranquilidad ante todo... bastan unos pasos a la oficina de al lado, meter la cabeza y anunciar con tono calmo "Me parece que se cayó... (tal cosa)". En general en breves momentos está solucionado.

Pero hay días, los menos por suerte, en que recibimos respuestas del tipo "Ya sé, no me digas nada. No anda internet, no anda el SourceSafe, no anda la base de datos, no anda la red, no anda nada".

No anda nada..., lo que dicho un par de veces a los gritos degenera en el nombre que da título a este post y que para el equipo, lejos de evocar alguna de las sugerentes imágenes de la señorita (perdón, señora), es anunciador del apocalipsis: ¡Wanda Nara!.

Así que lo que ha sucedido es que debido a problemas tecnológicos que no vienen al caso hemos sufrido un par de días "Wanda Nara" en la oficina.

Dejo para después el clásico post "Cuánto necesito internet" que es de rigor en estas ocasiones. Los dejo para que naveguen tranquilos por los links, si es que pueden hacerlo y no lo han hecho todavía.

Charlas esclarecedoras sobre la crisis financiera.

Por si algún despistado no lo ha visto todavía... versión con subtítulos:

Preguntas para la entrevista de trabajo a un postulante de sistemas.

Blog de un administrador de sistemas nos propone en Posibles preguntas a un administrador de sistemas en una entrevista de trabajo una serie de preguntas para evaluar a un candidato a administrador de sistemas.

Si bien el post es claramente humorístico, hay algunas que podrían utilizarse en cualquier entrevista para un puesto relacionado con sistemas (las posibles respuestas son propuestas mías):

• ¿Cómo trabajas en equipo cuando todos tus compañeros son idiotas?

  Posible respuesta: si mis compañeros de equipo son todos idiotas, entonces el idiota soy yo.

• ¿Cuanto tiempo gastas al día leyendo noticias en Internet?

Posible respuesta correcta: El que me venga en gana. Si no están contentos conmigo, pues que me den una razón basada en mi tarea, no en lo que leo.

• ¿Por qué demonios una persona sana como tú desea ser un administrador de sistemas?

  Posible respuesta correcta: Es que no soy una persona sana.

• ...

El resto de las preguntas en la entrada original.

Actualización: y yo propongo las mías (serias) en 5 preguntas para entrevistas de trabajo a programadores.

No más camisetas arrugadas.

Esta semana me lo armo.

Visto en Esquizopedia.

Malabarista musical

Un poco de relax después de tanto artículo largo y serio.

Visto en Emezeta.

El usuario (II)

Recordemos la definición ad-hoc de usuario que había presentado en la primera parte de este artículo:

[...] es el que opera el sistema en una situación real para alcanzar un objetivo determinado que coincide con el que fue requerido al desarrollar el sistema.

Luego lo caracterizaba, un poco maliciosamente, diciendo que

El usuario es tonto o malicioso a menos que se demuestre lo contrario.

para luego mencionar algunas de las características más comunes que todos adoptamos cuando somos usuarios de un sistema:

• Distracción: no leemos, no miramos.
• Falta de memoria: no registramos nuestras acciones ni sus resultados.
• Descontextualización: no interpretamos lo que vemos en su contexto, sino que tendemos a trasladarlo literalmente al nuestro.
• Mecanicismo: repetimos secuencias automáticas de acciones mecánicas que nos han dado resultado.

El origen (siempre de acuerdo a mi modesto entender en estas cuestiones, de las que no soy un gran teórico) es que el usuario no está utilizando el sistema. ¿Cómo?

No. El usuario no utiliza el sistema. Nadie dice, "mi trabajo es utilizar un sistema" o "estoy un poco aburrido, voy a utilizar el sistema". El usuario quiere hacer otra cosa. Querrá pagar una factura, vender un boleto, consultar el horario de una película, actualizar el stock, divertirse...

Los seres humanos no somos demasiado buenos ejecutando varias tareas al mismo tiempo. Nuestro cerebro tenderá a siempre a concentrarse en aquélla que juzgue más importante o le demande más atención. No es ésta la verdad revelada, precisamente. Es, por ejemplo, la razón principal de que no utilicemos el celular cuando manejamos (no deberíamos, por lo menos) o de que apaguemos la radio del auto cuando nos perdemos. En estas conductas vemos otro punto sutil: tampoco somos muy buenos concentrando nuestra atención conscientemente. El celular y la radio nos distraen, aunque lo neguemos o querramos evitarlo.

Entonces el sistema es una herramienta que, si bien el usuario quiere o debe utilizar, lo distrae inevitablemente de su objetivo principal. Como no puede apagarlo hace lo que hace: le presta la menor atención posible. Cuando somos usuarios desarrollamos toda una serie de conductas que tienden a reducir al mínimo la cuota que nuestro cerebro debe dedicarle al sistema en sí.

Así que tenemos que estar conscientes de que cuando el sistema trata de atraer la atención del usuario está molestando. Siempre. Así que más vale que lo haga por algo importante.

Si están de acuerdo con en el razonamiento que me llevó a la frase anterior, tendrán que coincidir con que los errores respecto de este tema son muy, pero muy comunes en casi todo software:

Molestar con bobadas:

• Propaganda intrusiva e irrelevante, sobre todo en Internet. Si el usuario quiere leer el diario ¿por qué demoraría más de un segundo en cerrar esa imagen molesta que le impide hacerlo?

  Se me dirá que ese tipo de propaganda funciona. Es verdad. Funciona desde el punto de vista del anunciante, que actúa más o menos como un spammer: molesta a varios cientos de miles para alcanzar a ese par de decenas de usuarios que tienen algún interés en el producto o servicio promocionado.

  Por otro lado ¿no funciona mejor la propaganda contextual? Ese sistema se basa en lograr un encuentro entre lo que el usuario busca y lo que el sistema le ofrece. Si el usuario busca pasajes baratos, encontrará la frase "Viaje casi Gratis" así esté ubicada en el extremo inferior izquierdo de la pantalla, en azul con fondo negro y letra chica.

• Intentando meterse compulsivamente en lo que el usuario quiere hacer, o insistiendo en enseñarle lo que no quiere aprender. Software que parece un chico de 3 años que demanda atención o quiere demostrar que sabe. Que haga tal cosa si desea hacer tal otra, que mejor si lo hace así, que por qué no lo hace asá.

  El momento en que el usuario está utilizando el software para otra cosa no es precisamente el mejor para brindar capacitación.

  Hay que darle al usuario la posibilidad de que haga lo que quiera hacer de la manera en que lo desee. Lo divertido de los programas que cometen los errores mencionados (Microsoft se lleva las palmas, y el paquete Office el premio mayor) es que cuando el usuario realmente quiere propaganda o capacitación o consejos útiles o ayuda o información detallada no la encuentra, porque si el sistema no la ofrece automáticamente (y de forma molesta) no hay detective que pueda ubicarla.

Molestar con información a destiempo o fuera de contexto.

La medida de lo importante la da el objetivo del usuario: si el usuario está ingresando una factura, poco le importará que se ha ingresado un nuevo producto al stock, por más relevante que esto pueda ser para él en otro momento.

No saber atraer la atención del usuario cuando es necesario.

Si soy un contador y estoy apurado para cerrar ese balance con mi jefe mirando por encima del hombro, el mensaje "se está quedando sin espacio en la partición primaria de la unidad Z" titilando en letras rojas pasará absolutamente desapercibido, por más catastrófico que le pueda parecer a cualquier administrador del sistema.

Esto es un completo despropósito, sobre todo teniendo en cuenta que, en general, ése tipo de alarmas contiene un mensaje más pequeño a continuación, que usualmente reza "Guarde sus trabajo en una ubicación alternativa para evitar pérdida de datos".

¿Qué es más importante para el usuario y tiene más posibilidades de atraer su atención? ¿Que la unidad Z se queda sin espacio o que está a punto de perder su balance casi terminado?

Después el analista funcional no entiende cómo el usuario no vio eso.

Los mensajes tienen que estar orientados al usuario que los lee, y en lo posible (aunque ésto es mucho más difícil) relacionados con la tarea que está realizando. Una buena regla para la redacción de mensajes es que en vez de decirle al usuario lo que le pasa al sistema (que poco le importa) hay que decirle lo que a él le está pasando o le va a pasar.

Mensajes de error incomprensibles.

Este punto es típico, terriblemente típico (vinculé una linda colección de delirios en la entrada Mensajes de error), y que encima se nos vuelve en contra, porque aquí los que solemos quedar como idiotas somos nosotros, los desarrolladores.

Yo tengo dos reglas básicas:

• La primera es de redacción: el título del mensaje de error es siempre "No se pudo [hacer lo que el usuario iba a hacer]", en palabras del usuario: "No se pudo ingresar la factura", "No se pudo imprimir el tícket", etc. Un mal ejemplo es "El recurso de impresion \\ADMNET\Imp\EPS345 no está disponible".

  El detalle, más pequeño, tiene que responder siempre a la pregunta "¿por qué?", también en palabras del usuario. Es como un diálogo: título - ¿por qué? - detalle del error. "No se pudo cerrar el balance" (¿por qué?) "No hay espacio suficiente en disco". ¿Ven que queda mejor?

• La segunda tiene que ver con los errores no manejados, es decir, con los errores de programación. Cualquier intento de brindar información al usuario es peligroso, porque el sistema está en un estado desconocido, y puede pasar cualquier cosa (como muestran los ejemplos de la entrada anterior).

  Creo que lo mejor en este caso es el típico "Se ha producido un error inesperado" o algo así, y brindar un curso de acción (número de soporte, reintente tal cosa, pruebe tal otra). Pero ojo, no estupideces, sino cursos de acción razonables teniendo en cuenta que el usuario quiere completar una tarea. Es decir, llamar a soporte técnico es una opción, pero no la mejor en este sentido.

  Lo que voy a poner es brutalmente difícil, yo nunca lo implementé: pero si tengo un error inesperado, tengo que dar una solución de negocio de acuerdo a la operación que el usuario está haciendo. Ejemplo: si estoy en la carga de la factura, tengo que explicarle al usuario que tiene que verificar si se registró la factura ingresada, facturar a mano, y luego llamar a soporte o lo que sea. Es decir, primero le resuelvo el problema al tipo.

  Pero claro, lo anterior implica prácticamente un manual de incidencias para cada funcionalidad. Dije que era brutalmente difícil.

Una última aclaración: cuando el personal de soporte técnico está revisando la instalación, también es de alguna manera un usuario. Lo mismo cuando lo está instalando o cuando el administrador lo está configurando. Al igual que en los ejemplos anteriores, aquí también tenemos que utilizar el lenguaje del usuario, que en este caso es más técnico.

El mismo mensaje ambiguo de error inesperado que para el usuario común es más amable, para éste tipo de usuario es casi ofensivo, ya que la falta de información, que antes se traducía en simpleza, ahora le impide saber qué es lo que está pasando.

En general se utilizan ejemplos mencionando usuarios "comunes", pero no debemos olvidar que también hay usuarios u operarios (si les gusta la diferencia) que juegan un papel más técnico y que por ello deben recibir más información técnica. Como siempre, lo lógico, aunque también lo más difícil, es responder correctamente de acuerdo a la situación.

Para cerrar, digamos que es terrible crear un buen sistema que la pifie justo en el momento en que el usuario realmente lo está utilizando para algo. Y sobre todo si, como en el caso de los mensajes de error, es una cuestión fácilmente evitable durante el desarrollo. Simplemente es cuestión de pensar dos segundos antes de escribir esa frase maldita (o con faltas de ortografía) que nos hará quedar como bobos ante el cliente. ¿No vale la pena?