Pesadilla en la oficina

Ahora que tenía este post pensado, me comentan que ya existe una entrada en youtube que parodia la serie “Pesadilla en la cocina”, pero en el mundo del software, es decir: “pesadilla en la oficina”. Pues ale, os adjunto el enlace para que disfrutéis del vídeo:


¿Os imagináis algo así en vuestras empresas? ¿Aguantaríais que alguien criticara tan duramente vuestro trabajo? Y ojo, no me vale la típica respuesta de listillo en plan “sólo si sabe mucho más que yo”. Las cosas son como son, nos la diga Chicote, el tal Alvarote del vídeo, o Rita la Cantaora.

Fauna laboral: el protegido

Dilbert-El-protegido

Hay quien lo llama enchufado, pero yo prefiero llamarlo el protegido. Después de todo, lo de enchufado es poco significativo, y por protegido entiendo que nos referimos al individuo que está liberado de marrones, no tiene que trabajar ni hacer nada salvo las peticiones especiales que su jefe le diga directamente. Cuando surge algo urgente o especialmente delicado, el protegido desaparece, hace su “mutis por el foro”, y de hecho suele estar ilocalizable.

El término enchufado, además suele utilizarse para “el hijo de…” o “familiar de…”, lo cual es inexacto.

Estos individuos los he podido observar en alguna de mis anteriores empresas, y existen diversas técnicas de actuación recomendables:

  • Estar cerca de ellos. Esta técnica intenta buscar que al estar junto a un protegido, estemos liberados de marrones, tareas infames de última hora, y proyectos imposibles. Por desgracia, los marrones que deberían ser responsabilidad de un protegido, pueden caer en sus alrededores. Es como si algo que sería responsabilidad natural de una persona, debiera de caer inherentemente en su área de actuación. No nos equivoquemos, el protegido estará ahí (no está muy lejos) para recoger los méritos y los laureles del triunfo.
  • Estar lejos de ellos. Esta técnica intenta evitar que los marrones nos salpiquen por cercanía de un protegido. Con suerte, podremos estar en un proyecto lo suficientemente complejo y alejado que haga que no se acuerden de nosotros. Sin embargo, esta técnica tiene también sus problemas, ya que los marrones tienden a caer lejos de los protegidos.

¿Cómo suele actuar el protegido?

  • Animal social. Se sabe protegido, por lo que da prioridad a las relaciones públicas, las sonrisas y los cafés. Su hábitat natural está junto a la máquina del café, aunque los más peligrosos son los que saben alternarlo con su puesto de trabajo, simulando una actividad febril.
  • Acompaña siempre a su protector. Sin él, no es nada y lo sabe. Sus actividades requieren de la constante supervisión y conformidad de su protector.
  • Rendimiento. Rinde lo menos posible, aunque lo verás teclear como si tuviera la enfermedad de Párkinson en cada uno de sus dedos.
  • Sólo le preocupa su marca personal. Esta característica la comparte con el trepa. Por supuesto, hay protegidos pasotas, pero rara vez mancharán su imagen profesional.
  • Transparencia. Simplemente, carece de ella. El protegido se limita a realizar las tareas oscuras y secretas que su jefe (o el jefe que los ha acogido bajo “su protección”) les ha encargado. Nunca sabrás qué hacen, ni para qué. Eso sí, todo será super-importante y muy urgente. Aunque todos sabemos que no es así, ya que de serlo, sería un marrón, que por definición, no les es nunca asignados a  los protegidos.
  • Actividad: el protegido está continuamente preparándose. Y me diréis, ¿normal, no? Pues no tanto, ya que como el protegido tiene mucho tiempo libre, suele estar preparándose para formarse (algún día puede que tenga que demostrar que sabe hacer algo) y para promover su marca personal.

Y tú, ¿conoces a algún protegido?

 

 

Cómo afrontar una entrevista de trabajo (1)

dilbert-entrevista-trabajoEmpiezo poniendo a esta entrada el número 1 porque ya preveo que va a dar para unas cuantas más. Y es que las entrevistas de trabajo son cada vez complejas, y no siempre es dicha complejidad proporcional al puesto de trabajo.

Hoy para empezar, veamos un par de preguntas que así, sin venir a cuento, le hacen a unos amigos en otra empresa, para puesto de programador con experiencia:

Pregunta #1: La cuerda que rodea la tierra

Pregunta: Suponiendo que la tierra fuese una esfera perfecta, si ponemos una cuerda que de la vuelta completa a la tierra por el ecuador y quede perfectamente ajustada a ella…si añadimos un metro a dicha cuerda, ¿cuáles de los siguientes objetos podrían pasar por el hueco que quedaría bajo la cuerda (una moneda, un gato, un vaso de vino)?

Respuesta: Resulta que se trata de un famoso problema matemático, una paradoja matemática que consiste en que el hueco que quedaría entre la tierra y la cuerda es exactamente el mismo, y sólo depende del tamaño de la cuerda añadida (y no del tamaño de la cuerda). Es decir, que si a una pelota de golf (o de tenis, o lo que os de la gana), le añadís un metro de cuerda, la distancia o hueco entre la superficie de la esfera y la cuerda…será exactamente la misma que en el problema inicial de la tierra (aproximadamente, unos 16 cm). Más información y detalle del cálculo del teorema que lo demuestra en: https://en.wikipedia.org/wiki/String_girdling_Earth

Pregunta #2: Una de interruptores

Hay 3 interruptores (de los de encender/apagar luces de toda la vida), en la planta calle de un edificio. Sólo uno de ellos apaga/enciende una bombilla del piso 3. Los otros dos, están conectados a cualquier otra cosa. Si sólo tuvieras una oportunidad de tocar los interruptores y subir al piso 3 (sin volver a bajar ni alterar los interruptores)…¿cómo podrías saber qué interruptor era el correcto?

Respuesta: La solución, en: http://www.scientificamerican.com/article/answers-to-puzzles-posed-in-let-the-games-continue/

Conclusión.

Por desgracia, estas preguntas tenían poco o nada que ver con la pericia técnica del trabajo para el cual se hacía la entrevista. Sin embargo, son preguntas que se suelen hacer en entrevistas de trabajo, en empresas como Google o Microsoft.

¿Os parecen preguntas adecuadas? ¿Creéis que realmente son objetivas de alguna forma? Ya hay voces de algunos responsables de RRHH que alzan su voz en contra de este tipo de técnicas. Pero eso, lo dejaremos para otro día.

 

 

 

 

 

ÑaaS (Ñapa as a Service)

ñapa-as-a-serviceHoy os traigo una delicatesen que un buen amigo me ha proporcionado. Como ilustra la figura adjunta, la ñapa es una de las lacras de esta profesión del desarrollo de software, y por desgracia, hay quien la ofrecen como servicio de forma habitual.

Quiero pensar que el autor de la imagen, al escribir “Programming the spanish way”, no hablaba en serio. Me niego a pensar que la forma habitual de programar en España sea la Ñapa.

Para los lectores de otros países, o que me lean mediante el traductor automático, vamos a ofrecer una traducción del término “Ñapa”. No os molestéis en buscar en la RAE (Real Academia Española de la lengua). El término Ñapa no aparece allí. Sin embargo, es harto conocido al menos en España

ÑAPA: chapuza, mierda, parche, remiendo. En informática, dícese del trabajo mal remunerado y peor ejecutado, que consiste en construir un simulacro de aquello que espera ver el cliente, con el mínimo esfuerzo, y totalmente alejado de lo que una mente sana entendería como adecuado.

Eso es una ñapa. Este término está muy relacionado con otros que ya he blogueado (y algunos que aún no he terminado de escribir) como: cantamañanas, o vendemotos, o vendedor de humos (smokeseller para los amigos). Es gracias a esta fauna de la selva informática, a quienes debemos agradecer la existencia de las ñapas.

También hay que agradecerlos a los clientes, que también los hay, que son capaces de cambiar de opinión cada poco tiempo para disfrute de los programadores. Esos programadores que se encuentran que después de docenas o cientos de horas construyendo aplicaciones, éstas dejan de tener sentido debido a “un pequeño cambio”.

Y me rio, me parto de la risa ácida que me entra de forma visceral e insostenible, cuando me salta el iluso de turno con su “esto se arregla siendo ágil”. Hay amigo, esto no lo arregla SCRUM, ni CMMI ni nadie. Cuando el cliente decide que lo más importante no es identificar el impacto de un cambio, ni priorizarlo. Solamente llevarlo a cabo. Aunque haya que tirar a la basura semanas y semanas de duro trabajo para rehacer desde cero miles de líneas de código.

La ñapa o chapuza, es una enfermedad del software (podéis leer más enfermedades del software que he ido recopilando en esta categoría, como la comentitis, singletonitis, excusitis, cacheitis, patronitis… ). Y esta enfermedad es difícil de erradicar. Desde mi experiencia, lo más importante no es la metodología, no es ser más o menos ágil. Sino ser consecuentes y tener la mente fría. Identificar el impacto de las cosas, y asumir que los cambios existen, y que la forma más rápida de llevarlos a cabo es precisamente…no ponerse a ellos de forma inmediata. Sino ponerlos en cartera y ver cómo se relaciona con otros cambios solicitados, los desarrollos en curso, etc, etc.

Gracias José Antonio Herrero por la imagen.

24h – El complejo de Jack Bauer

Ocurre en muchas ocasiones: más de las que nos gustaría y más de las que queremos admitir. En esta profesión de desarrollo de software, en la que tenemos metodologías, métricas, procesos, calidad, más de una vez nos habremos encontrado sufriendo el complejo de Jack Bauer.

Ocurre de forma progresiva: primero tenemos todo planificado y bajo control, todo parece ir sobre la seda, y cuando menos te lo esperas, salta un problema para el cual no tenías un plan de contingencia. La cuestión no es tanto si sabemos o no planificar, sino más bien cómo afrontar los problemas. Esos problemas que se suelen manejar en un comité y que en más ocasiones de las que nos gusta admitir, tememos escalarlos a ese comité por no asumir responsabilidades.

¿La consecuencia? Pues que trasladamos a nuestros equipos esa responsabilidad, enmascaramos la culpa con una falsa urgencia (o no tan falsa), y movilizamos nuestros ejércitos para afrontar lo que parece ser un capítulo de la serie de televisión “24”. Con un plazo imposible de cumplir, nos embarcamos en una tarea sobrehumana, y sustituimos la culpa, la gestión y las metodologías por un compromiso y resolución que nos lleva a ser protagonistas de esa serie, donde hay que salvar el mundo, hacer tareas imposibles, recorrer varias veces toda la ciudad y todo ello en 24 horas.

¿Os suena? Pues sí, esto es el complejo de Jack Bauer, personaje protagonista de esa serie de televisión, y que representa muy bien las situaciones de “bombero” o “apagafuegos” en las que nos vemos inmersos.

Esta forma de afrontar los problemas, la podéis encontrar en la red con otros nombres. Uno que me ha gustado es el antipatrón “apagafuegos”. Os recomiendo leer esa web de antipatrones.

Hay que tener mucho cuidado con esta forma de actuar, porque lleva a ser estimulante. Nos podemos sentir héroes salvando el mundo, apagando fuegos constantemente, en ese complejo de Jack Bauer. En lugar de afrontar los problemas como lo que son, no podemos tratar de resolverlos todos a la primera de cambio, en ese ciclo de subida (esfuerzo heroíco de resolver el problema) y de bajada (bajón inevitable que tenemos cuando la situación ya es estable y la adrenalina se agota…hasta el siguiente fuego).

Hay quien ve esta forma de actuar como una adaptación al cambio. Pero adaptarse al cambio no significa afrontar los problemas con sesiones a lo Jack Bauer (es decir 24 horas sin dormir y con esfuerzos histéricos para resolver las cosas). Hay que atajar los problemas de base, porque distraer al equipo de esa forma significa alejarlo del objetivo del proyecto. Esa distracción no supone 24 horas, sino mucho más: el coste de recuperar el ritmo, y también de recuperarse de ese esfuerzo.

Los cambios los gestionamos nosotros, no al revés.

MasterDev, el MasterChef del software

Hala, por fin se ha acabado en España la versión infantil o “Junior” de un conocido concurso internacional de televisión llamado “MasterChef”.

Yo, personalmente, os propongo hacer uno parecido llamado “MasterDev”. Los objetivos de este nuevo concurso serían más o menos los siguientes:

  • Los concursantes, tendrían una sección inicial del programa en el que se mostraría el lado humano: cómo han convivido, cómo han aprendido las últimas técnicas de programación, frameworks, lenguajes, etc. Se les vería su día a día encerrados en “la casa”, donde tendrían sus momentos de roce, tensiones internas, se formarían grupos…
  • Por supuesto, habría un apartado de “expulsados” en el que los concursantes elegirían a los 3 nominados. De entre ellos, uno sería expulsado por votación del público.
  • Finalmente, el plato fuerte del programa sería el desarrollo “en directo” de una aplicación, basada en los requisitos y exigencias de los chefs (bueno, en este caso, scrummasters o similar). En este apartado, unos famosos programadores harían de estrellas invitadas y propondrían los casos de uso/historias de usuario a desarrollar. Serían los jueces que elegirían a los mejores programadores cada semana. Éstos “Master-Dev” podrían salvar a uno de los nominados, tal y como se hace en otro conocido concurso: “Gran Hermano”. Durante esta parte del programa, se nos estaría mostrando a los programadores llevando a cabo las tareas encomendadas, con la tensión de ver el reloj. Para darle mayor realismo, podría ser un reloj marcando la hora de salida del  trabajo, lo que aportaría una tensión increíble.
  • Finalmente, el momento culmen del programa sería cuando los jueces irían diciendo los puntos fuertes y débiles de cada programador, y se elegirían los “Master-Dev” de la semana.

No sé lo que os parece, pero yo creo que no tendría la misma tensión que el programa original “MasterChef”. Ver 20 minutos a una serie de programadores, sentados en sus sillas, tecleando como si les fuera la vida en ello, no se si sería digno de ocupar el prime-time de las principales cadenas de televisión.
En el cine, “Swordfish” (2001) ha sido una de las películas en las que más tensión se ha podido observar mientras se mostraba a un programador (Hugh Jackman) tecleando en sus teclados y observando con pasión sus múltiples monitores. Sin embargo, veo difícil el llevar esto a la televisión, especialmente recordando el motivo que hace que Hugh Jackman salve su vida cuando es sometido a presión por John Travolta (sí, se trata del trabajo realizado por cierta señorita). Por cierto, ver a Hugh Jackman programando un peligroso virus simplemente “pegando” cubos entre sí en pantalla, es un puntazo. No tendría la misma tensión si “Swordfish” tuviera un diálogo más realista:
– “A ver…mierda. Me he dejado un punto y coma”
– “Compilo…y a ver….15%….40%….mierda. Dos warnings y 1 error. Pues vaya.”
– “A ver…busco el error en google, pero ¿esto que es?”
– “Ah ya lo tengo. Venga, cambio el tipo de la variable….añado el parámetro que faltaba…”
– “Compilo…y a ver…15%…40%…(dios que lento)…60%…mierda. Otro error.”

Tal vez se le podría dar algo más de emoción. Y no, no me refiero al trabajito que le hacen a Hugh Jackman en SwordFish para motivarle. Me refiero a comentarlo como si fuera….no sé…un partido de fútbol:
– Atención, John recibe el código, lo compila yyyyyyyyy Uyyyyyy. Un erroooor. Sí señores, un error ha entrado de llenoooooooo. Neumáticos Martinez, los mejores. Compreeeee neumáticos Martínez (no podía faltar la publicidad en una retransmisión deportiva).
– Señoras y señores, qué tensión! John todavía no ha corregido su error, y Anthony ha compilado con éxito atencióoooooon que ha compiladoooooo.
– Cuidado, cuidado, que un tercer programador está a punto de terminar, es Juan. Recuerden que Juan no había destacado en otros programas, pero ha terminado sólo 1 segundo y 3 décimas por detrás de Philips. Cuidado, todavía no han hecho checkin! Beba Rock-cola, burbujeante, maravillosa!
– Increible! Philips ha perdido el código! Error de aplicación, eso lo deja fuera del concurso! Qué tensión, John está terminando de depuraaaaaar yyyyy gana Juan!  Por tan sólo unas líneas de código por delanteeeeee.

¿Y vosotros? ¿Os gustaría ver un “MasterDev” como concurso?
En fin. Feliz año nuevo.

Update: Gracias a Julián Gómez por la idea de cambiar el titular, y por leerme. Me había quedado muy simplón como “MasterDev” sin más.

No te olvides de poner el Where…

Si alguna vez has programado, creo que tienes que ver y oír esto.

Ha pasado un mes sin publicar anda en este blog, y ya era demasiado tiempo. Y al ver esta entrada de forma fortuita en linkedin, no me he podido resistir. Merecía la pena ponerlo y guardar este momento. Que aproveche…

Gracias a Jorge Eduardo Olaya Perdomo por compartirlo y permitirme conocer la existencia de este vídeo. Y a Jorge Rubira, por publicarlo en YouTube. Saludos.