Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Thursday, August 24, 2006
Combatir la procrastinación
¿Qué es la procrastinación? Pinchando en la palabra podemos acceder a su definición más detallada pero básicamente, en nuestra profesión, la podemos resumir como la pereza de los programadores.
No se puede averiguar exactamente cuáles son las causas de porqué en alguna ocasión nos vemos aquejados por estos síntomas. Hablando con unos compañeros de trabajo coincidí en que una de las causas más culpables es el calor (¿a lo mejor por eso las jornadas intensivas en verano son positivas?). Y la verdad es que yo he notado estas dos semanas de atrás que he estado más productivo que al principio del verano y que ahora (porque ya ha vuelto el calor otra vez).
Otra es la falta de motivación, por supuesto, pero afortunadamente en mi caso personal creo que hace mucho que no me ocurre esto. De todos modos, hay técnicas que los jefes podrían aplicar y que serían bastante menos intrusivas que un aire acondicionado ultrapotente o un emulador de tormentas xD. Una de ellas es el Pair Programming, de la que ya hablé una vez, que consiste en situar a los desarrolladores/analistas/arquitectos en parejas. En la mayoría de las ocasiones me he encontrado con que la gente piensa que esto reduce el grado de productividad individual en la mitad, cuando yo creo que lo que ocurre es precisamente lo contrario (la duplica), a parte de aportar otras muchas ventajas que pueden valorarse tanto desde el prisma profesional como incluso del personal:
(Extraído vía Carl Rosenberg, de DB4O.)
Por supuesto, como ya anuncia Carl en su entrada, el Pair Programming no es perfecto pues uno de sus inconvenientes es el agotamiento (principalmente provocado por la tercera razón de las mencionadas en la lista anterior), el cual se ve compensado con creces con la siguiente afirmación que él sostiene:
There is only one downside of pairing: It can be very strenuous. I can write code on my own 10 hours a day, 7 days a week and it's always a fresh breeze of flow. Pairing is different. Sometimes two intense 2-hour pairing sessions are absolutely enough for one day to be very tired. That's good, you can have a life too because you get much more work accomplished in less time. I believe that 20 hours of pairing ( 4 hours, 5 days ) produce more valuable output than 70 hours of solo programming ( 10 hours, 7 days).
(¿Entendéis ya lo del plano personal que mencioné antes? ;)
Por último, no todas las parejas de programadores encajan bien (al igual que ocurre con otros tipos de parejas ;), así que habría que tener cuidado de a qué tipos de programadores juntamos.
Si alguien quisiera medirse conmigo, yo he usado este articulito denominado Tipos de programadores de la A a la Z y me he determinado como la siguiente mezcla:
35% de GG, 20% de HH, 35% de OSO, 9% de ZZ y 1% de RR
(Si sólo lees los que yo he escogido, vas a pensar que soy un desarrollador bastante mediocre. Bueno, no lo sé, pero el caso es que debería avisarte de que la mayoría, por no decir todos, están descritos con connotaciones negativas, jejej. Sino, prueba a determinar tu perfil ;)
Actualización 12-SEP-2006: Después de leer el ensayo Cultivando la noosfera de Eric Raymond, me gustaría citar algunas partes que están en cierta manera relacionadas con esta entrada, ya que habla de la motivación de los programadores, y cita concretamente la diferencia que puede haber entre los componentes de un proyecto de software abierto comparado con los de otro cerrado:
El veredicto de la historia parece ser que el capitalismo de libre mercado es la forma globalmente óptima de cooperar para la eficiencia económica; quizás, en una forma similar, el juego de la reputación de la cultura del don es la forma globalmente óptima de cooperar para generar (y verificar!) trabajo creativo de alta calidad.
El soporte de ésta teoría viene de un conjunto de estudios psicológicos en la interacción entre arte y recompensa. Estos estudios han recibido menos atención de la que deberían, en parte quizás porque sus popularizadores han mostrado una tendencia a sobre-interpretarlos en ataques generales contra el libre mercado y la propiedad intelectual. Sin embargo, sus resultados sugieren que algunos tipos de escasez económica en realidad disminuyen la productividad de trabajadores creativos como los programadores.
La sicóloga Theresa Amabile de la Universidad de Brandeis, resumiendo cautelosamente los resultados de un estudio de 1984 sobre motivación y recompensa, observó: “Puede ser que el trabajo por comisión, en general, sea menos creativo que el trabajo que es hecho por puro interés”. Amabile observa que “Cuanto más compleja la actividad, más es dañada por la recompensa extrínseca”. Paradójicamente, los estudios sugieren que los salarios desinflados no desmotivan, pero si lo hacen los premios y bonos.
Así, sería económicamente inteligente entregar bonos a gente que vende hamburguesas o cava fosos, pero es más inteligente desligar el salario de la calidad en una tienda de programación y dejar elegir a la gente sus propios proyectos. Verdaderamente, éstos resultados sugieren que la única vez que es una buena idea recompensar la calidad en la programación es cuando el programador está tan motivado que él o ella hubieran trabajado sin la recompensa.
Otros investigadores apuntan a los problemas de autonomía y control de creatividad que tanto preocupan a los hackers. “Mientras el grado de experiencia de uno de ser auto-determinado sea limitada,” dice Richard Ryan, profesor de sicología de la Universidad de Rochester, “la creatividad de uno será reducida también.”
En general, presentar cualquier tarea como un medio más que como un fin en sí misma parece desmotivar. Aun ganando una competición con otros o ganando estima de sus pares puede ser desmotivizante en ésta forma si es experimentada en el trabajo como una recompensa (lo que puede explicar por qué los hackers son culturalmente prohibidos de buscar explícitamente o clamar esa estima).
Para complicar más el problema de la administración, controlar los dichos verbales parecen ser tan desmotivadores como el pago por el trabajo de uno. Hay una diferencia crítica entre decir, “Te estoy dando ésta recompensa porque reconozco el valor de tu trabajo” y “Estas recibiendo ésta recompensa porque te ajustas a los estándares.” El primero no desmotiva; el segundo sí.
En éstas observaciones psicológicas podemos decir que un grupo de desarrollo de código abierto será substancialmente más productivo (especialmente a largo plazo, en el cual la creatividad se vuelve más crítica como un multiplicador de la productividad) que un grupo de igual tamaño y conocimiento, de programadores de código cerrado (des)motivados por recompensas.
Verdaderamente, parece que la prescripción de software de mayor productividad es casi una paradoja Zen; si quieres el producto más eficiente, tienes que dejar de tratar que los programadores produzcan. Manejar su subsistencia, darle sus cabezas y olvidarse de fechas límites. Para un director convencional esto suena locamente indulgente. Pero es exactamente el recipiente con el cual la cultura de código abierto está llevando a cabo su competencia.
(Énfasis añadido.)
Actualización 10-MAR-2007: Ya que he hablado en esta entrada sobre personalidades de programadores, voy a añadir un interesante test de personalidad para programadores que he encontrado. Los resultados que he obtenido son:
Your programmer personality type is:
PHTB
You're a Planner.
You may be slow, but you'll usually find the best solution. If something's worth
doing, it's worth doing right.
You like coding at a High level.
The world is made up of objects and components, you should create your programs
in the same way.
You work best in a Team.
A good group is better than the sum of it's parts. The only thing better than a
genius programmer is a cohesive group of genius programmers.
You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as
freely as possible to help simplify the task. We're not writing on paper anymore
so we can take up as much room as we need.
Actualización 01-FEB-2008: Otro test: "What colour is your brain?". Resultado:
Actualización 17-AUG-2009: Dos enlaces interesantes relativos a esta entrada que he descubierto hace poco:
- La procrastinación se hace rentable (español)
- La jornada ultra-intensiva (fuente en inglés)
No se puede averiguar exactamente cuáles son las causas de porqué en alguna ocasión nos vemos aquejados por estos síntomas. Hablando con unos compañeros de trabajo coincidí en que una de las causas más culpables es el calor (¿a lo mejor por eso las jornadas intensivas en verano son positivas?). Y la verdad es que yo he notado estas dos semanas de atrás que he estado más productivo que al principio del verano y que ahora (porque ya ha vuelto el calor otra vez).
Otra es la falta de motivación, por supuesto, pero afortunadamente en mi caso personal creo que hace mucho que no me ocurre esto. De todos modos, hay técnicas que los jefes podrían aplicar y que serían bastante menos intrusivas que un aire acondicionado ultrapotente o un emulador de tormentas xD. Una de ellas es el Pair Programming, de la que ya hablé una vez, que consiste en situar a los desarrolladores/analistas/arquitectos en parejas. En la mayoría de las ocasiones me he encontrado con que la gente piensa que esto reduce el grado de productividad individual en la mitad, cuando yo creo que lo que ocurre es precisamente lo contrario (la duplica), a parte de aportar otras muchas ventajas que pueden valorarse tanto desde el prisma profesional como incluso del personal:
- Se crean mejores diseños y se implementa código de mejor calidad. (Calidad)
- Se previenen más errores y por lo tanto se ahorra tiempo que pasar con nuestro amigo el Debugger. (Productividad)
- Se consigue estar concentrado el 99% del tiempo en una tarea concreta. (Productividad)
- Se consigue un conocimiento más distribuido y compartido del proyecto por parte de la plantilla; así que es más fácil intercambiar personas entre tareas. (Eficiencia/Productividad)
- Se produce un aprendizaje mutuo completamente abrumador sobre nuevas formas de afrontar los problemas (patrones), estilos de programación y técnicas de uso de los entornos de desarrollo. (Calidad/Productividad)
- Se eleva el espiritú de equipo a raudales. (Motivación)
- Se usa más ese área de tu cerebro empleada para comunicarte, por lo que aumenta tu creatividad. (Motivación/Calidad).
- Por último, programar en parejas es mucho más divertido. (Motivación)
(Extraído vía Carl Rosenberg, de DB4O.)
Por supuesto, como ya anuncia Carl en su entrada, el Pair Programming no es perfecto pues uno de sus inconvenientes es el agotamiento (principalmente provocado por la tercera razón de las mencionadas en la lista anterior), el cual se ve compensado con creces con la siguiente afirmación que él sostiene:
There is only one downside of pairing: It can be very strenuous. I can write code on my own 10 hours a day, 7 days a week and it's always a fresh breeze of flow. Pairing is different. Sometimes two intense 2-hour pairing sessions are absolutely enough for one day to be very tired. That's good, you can have a life too because you get much more work accomplished in less time. I believe that 20 hours of pairing ( 4 hours, 5 days ) produce more valuable output than 70 hours of solo programming ( 10 hours, 7 days).
(¿Entendéis ya lo del plano personal que mencioné antes? ;)
Por último, no todas las parejas de programadores encajan bien (al igual que ocurre con otros tipos de parejas ;), así que habría que tener cuidado de a qué tipos de programadores juntamos.
Si alguien quisiera medirse conmigo, yo he usado este articulito denominado Tipos de programadores de la A a la Z y me he determinado como la siguiente mezcla:
35% de GG, 20% de HH, 35% de OSO, 9% de ZZ y 1% de RR
(Si sólo lees los que yo he escogido, vas a pensar que soy un desarrollador bastante mediocre. Bueno, no lo sé, pero el caso es que debería avisarte de que la mayoría, por no decir todos, están descritos con connotaciones negativas, jejej. Sino, prueba a determinar tu perfil ;)
Actualización 12-SEP-2006: Después de leer el ensayo Cultivando la noosfera de Eric Raymond, me gustaría citar algunas partes que están en cierta manera relacionadas con esta entrada, ya que habla de la motivación de los programadores, y cita concretamente la diferencia que puede haber entre los componentes de un proyecto de software abierto comparado con los de otro cerrado:
El veredicto de la historia parece ser que el capitalismo de libre mercado es la forma globalmente óptima de cooperar para la eficiencia económica; quizás, en una forma similar, el juego de la reputación de la cultura del don es la forma globalmente óptima de cooperar para generar (y verificar!) trabajo creativo de alta calidad.
El soporte de ésta teoría viene de un conjunto de estudios psicológicos en la interacción entre arte y recompensa. Estos estudios han recibido menos atención de la que deberían, en parte quizás porque sus popularizadores han mostrado una tendencia a sobre-interpretarlos en ataques generales contra el libre mercado y la propiedad intelectual. Sin embargo, sus resultados sugieren que algunos tipos de escasez económica en realidad disminuyen la productividad de trabajadores creativos como los programadores.
La sicóloga Theresa Amabile de la Universidad de Brandeis, resumiendo cautelosamente los resultados de un estudio de 1984 sobre motivación y recompensa, observó: “Puede ser que el trabajo por comisión, en general, sea menos creativo que el trabajo que es hecho por puro interés”. Amabile observa que “Cuanto más compleja la actividad, más es dañada por la recompensa extrínseca”. Paradójicamente, los estudios sugieren que los salarios desinflados no desmotivan, pero si lo hacen los premios y bonos.
Así, sería económicamente inteligente entregar bonos a gente que vende hamburguesas o cava fosos, pero es más inteligente desligar el salario de la calidad en una tienda de programación y dejar elegir a la gente sus propios proyectos. Verdaderamente, éstos resultados sugieren que la única vez que es una buena idea recompensar la calidad en la programación es cuando el programador está tan motivado que él o ella hubieran trabajado sin la recompensa.
Otros investigadores apuntan a los problemas de autonomía y control de creatividad que tanto preocupan a los hackers. “Mientras el grado de experiencia de uno de ser auto-determinado sea limitada,” dice Richard Ryan, profesor de sicología de la Universidad de Rochester, “la creatividad de uno será reducida también.”
En general, presentar cualquier tarea como un medio más que como un fin en sí misma parece desmotivar. Aun ganando una competición con otros o ganando estima de sus pares puede ser desmotivizante en ésta forma si es experimentada en el trabajo como una recompensa (lo que puede explicar por qué los hackers son culturalmente prohibidos de buscar explícitamente o clamar esa estima).
Para complicar más el problema de la administración, controlar los dichos verbales parecen ser tan desmotivadores como el pago por el trabajo de uno. Hay una diferencia crítica entre decir, “Te estoy dando ésta recompensa porque reconozco el valor de tu trabajo” y “Estas recibiendo ésta recompensa porque te ajustas a los estándares.” El primero no desmotiva; el segundo sí.
En éstas observaciones psicológicas podemos decir que un grupo de desarrollo de código abierto será substancialmente más productivo (especialmente a largo plazo, en el cual la creatividad se vuelve más crítica como un multiplicador de la productividad) que un grupo de igual tamaño y conocimiento, de programadores de código cerrado (des)motivados por recompensas.
Verdaderamente, parece que la prescripción de software de mayor productividad es casi una paradoja Zen; si quieres el producto más eficiente, tienes que dejar de tratar que los programadores produzcan. Manejar su subsistencia, darle sus cabezas y olvidarse de fechas límites. Para un director convencional esto suena locamente indulgente. Pero es exactamente el recipiente con el cual la cultura de código abierto está llevando a cabo su competencia.
(Énfasis añadido.)
Actualización 10-MAR-2007: Ya que he hablado en esta entrada sobre personalidades de programadores, voy a añadir un interesante test de personalidad para programadores que he encontrado. Los resultados que he obtenido son:
Your programmer personality type is:
PHTB
You're a Planner.
You may be slow, but you'll usually find the best solution. If something's worth
doing, it's worth doing right.
You like coding at a High level.
The world is made up of objects and components, you should create your programs
in the same way.
You work best in a Team.
A good group is better than the sum of it's parts. The only thing better than a
genius programmer is a cohesive group of genius programmers.
You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as
freely as possible to help simplify the task. We're not writing on paper anymore
so we can take up as much room as we need.
Actualización 01-FEB-2008: Otro test: "What colour is your brain?". Resultado:
Your Brain is Green |
 Of all the brain types, yours has the most balance. You are able to see all sides to most problems and are a good problem solver. You need time to work out your thoughts, but you don't get stuck in bad thinking patterns. You tend to spend a lot of time thinking about the future, philosophy, and relationships (both personal and intellectual). |
Actualización 17-AUG-2009: Dos enlaces interesantes relativos a esta entrada que he descubierto hace poco:
- La procrastinación se hace rentable (español)
- La jornada ultra-intensiva (fuente en inglés)
Labels: General, Programacion
# posted by knocte @ 10:33 pm 
