¿Qué hace que los programadores se aburran? Psicología y Vida

Creo que Coy Bit ha ofrecido una excelente respuesta, pero la expresaría en el reverso, que luego da un poco más de información:

Los programadores no suelen aburrirse cuando intentan resolver algo de manera activa, es decir, cuando ESTÁN enfrentando un desafío nuevo y aún sin resolver.

Esto lleva a una conclusión útil: si desea que su mejor programador sea el más productivo para su organización, lo que de alguna manera es la preocupación implícita detrás de la pregunta que muchos podrían plantear, entonces solo quiere que él o ella se ocupen de resolver un problema. Hasta que él o ella lo haya resuelto, y no más allá.

La razón por la que esto parece ser algo crítico es que su mejor programador, al menos como lo he usado aquí, es el más capaz de descubrir cómo resolver con elegancia los desafíos de programación. Este es un ‘regalo aprendido’. Pero…

… ¿Cuánto más útil sería ese regalo si pudiera enseñarse? ¿Cuánto más útil sería un posible “hotshot” o “inconformista” de un gran programador si pudiera aprender humildad, que ninguno de nosotros tiene demasiado, y por lo tanto ser capaz de enseñar el cómo y el por qué a alguien? ¿Quién podría ser tan “bueno” pero no tan rápido para aprender los trucos?

Quizás extrañemos la parte de “vivir, aprender y transmitirla” que es la más importante.

Si es cierto que somos más productivos cuando no estamos aburridos, y el aburrimiento proviene de no ser desafiado, lo cual estoy de acuerdo en que en muchos casos sí, entonces la solución podría estar en recompensar a los programadores, tanto por descubrir cómo Resuelva un problema programáticamente y para implementar la solución que se ha resuelto.

A esto puedes decir, “doh, esto es lo que ya hacemos”.

Y a esa respuesta digo: “¿Es realmente? ¿Realmente los recompensa independientemente por cada uno? Cuando todo está dicho y hecho, realmente” ofrece una recompensa “por la solución más rápida, novedosa y” elegante “para un problema y luego una recompensa por separado sobre quién puede codificarlo de la manera más rápida y limpia.

¿Realmente se desacoplan los dos, que son habilidades muy diferentes, y de ese modo mejoran la productividad neta de su empresa mediante la eficiencia de la especialización sumamente simple y altamente estudiada ? ¿Por qué no tienes “solucionadores” y “codificadores”?

Sinceramente lo dudo. Al menos, dudo sinceramente que la mayoría de las organizaciones que podrían implementar tal estrategia realmente la estén implementando. Pero qué sé, ni siquiera soy un programador. Soy más de un analista. 😛

Una parte esencial de esta respuesta e idea es el valor innato de tener un programador que no solo puede ver la solución sino también, y casi tan importante, EXPLICA CÓMO Y POR QUÉ FUNCIONARÁ. Con demasiada frecuencia, las empresas se enfrentan a una situación en la que hay un tipo que resuelve todo lo que le das, pero que no puede explicar de manera concisa y concisa a los demás cómo y por qué funcionará. Eso lo deja a él (o a ella) como tal vez el único que puede depurar el trabajo de manera eficiente, por no mencionar el hecho absoluto de que, independientemente de cuán “buena” sea esa persona, todavía se perderá una fracción de la respuesta a la pregunta. Los rompecabezas más intrincados. Es solo que nadie lo notará porque las imperfecciones de un trabajo brillante a menudo requieren una comprensión o una brillantez comparables. (Es bastante común tener a “ese programador” que, si se fuera, torpedearía todo el proyecto. Es una mala situación si se puede evitar).

Entonces a la pregunta relacionada, “¿cómo evitar que los programadores se aburran?” La respuesta es relativamente simple:

Haga que sus trabajos sean más estimulantes intelectualmente SIN hacerlos más desafiantes.

Más sobre eso más tarde, supongo.