Nota: no hace falta que lean aquel post para entender este, pero igual lo recomiendo.
En el mundo de la programación existe la idea de que un "muy buen" programador es ridículamente más productivo que un programador "estándar". Podríamos decir que en la mayoría de las disciplinas, el que es bueno supera la velocidad/calidad/productividad de su compañero promedio (no del malo) por factor de alrededor de 2, para poner una relación razonable. Es decir, que un empleado muy capaz le rinde al jefe el doble que uno promedio. En programación, existe la idea de que la diferencia no es lineal, sino que el buen programador supera a la mayoría por un orden de magnitud: es 10 veces mejor. Para muchos esto es ridículo e imposible, para otros hasta se puede quedar corto. No hay forma de medirlo con total objetividad, así que la discusión es válida e interesante,
El artículo del que hablaba aboga mayormente a favor de tal afirmación, argumentando que al ser la programación una tarea de diseño y creatividad, los distintos tipos de errores o aciertos no se suman, sino que se multiplican entre sí. Por ej: es obvio que una mala elección en la arquitectura va a complicar todas las etapas siguientes, no importa lo buenos que sean los que estén a cargo de ellas. Entonces suena muy razonable.
La lista de factores que propone que multiplicados pueden llevar al 10x es:
- habilidades básicas de codificación
- experiencia para reconocimiento de patrones
- capacidad de concentración
- criterio para hacer sacrificios/compromisos
- simplicidad
- no exceso perfeccionismo
- conocimiento de la teoría
- entendimiento de lo que pasa a bajo nivel
- habilidades para la depuración
Ahora vamos al lado B. Varios comentarios parecen venir de parte de los que ya no creen en el programador 10x. Algunos argumentan que los programadores que parecen 10x en el corto/mediano plazo, no lo son a largo. Que han visto compañeros que parecían súper productivos en cierta etapa, pero que han tenido que pagar las consecuencias más tarde al encontrar la basura bajo la alfombra. Digamos por ejemplo que un aparente 10x resuelve una tarea complejísima en muy poco tiempo; pero más adelante, a otro le toca mantener o continuar ese código y descubre que es imposible. Entonces empieza a tener que pagar/gastar los 9x que se habían ahorrado.
Y a pesar que de parece contradictorio, luego de pensarlo un poco, nuevamente, no podría estar más de acuerdo con esto. Y el motivo es simple: mi experiencia, yo fui un falso 10x. Yo me consideraba capaz de implementar cualquier programa, rápidamente, y lo hacía. Lo hice por muchos años. Tengo en mi haber desarrolladas decenas de aplicaciones muy efectivas por fuera, pero que no me gustaría volver a ver por dentro. Muchas veces me ha tocado reconocer que era mejor reescribir una de esas desde cero que corregir o mejorar lo que ya había hecho.
Pero creo que es parte de la evolución natural, al menos para el entusiasta. Sobre todo si le aportamos una buena cuota de "autodidacta", algo muy accesible en estos días con tanto recurso libre en Internet. Al principio uno no produce casi nada. Luego, a medida que suma horas de vuelo agarra ritmo, se entusiasma, y se pone (aparentemente) súper productivo. Pero la serie de clicks mentales que llevan a uno a dar un salto de calidad requieren mucho más tiempo y experiencia. Y por sobre todo, requieren de la clase de experiencia que brindan los grandes errores. Leí una vez un tweet genial y profundo que viene al caso:
"Pienso que los programadores invierten sus primeros 5 años de programar aprendiendo la complejidad. Luego pasan el resto de sus vidas aprendiendo la simplicidad."
Aquí el tweet original de @MattFederovich
En conclusión, no es nada fácil el análisis del 10x, y hay que hacerlo a largo plazo, porque ahí es donde falla el 10x trucho, no escala. Y cuando uno programa pensando a largo plazo, priorizando la legibilidad, mantenibilidad, flexibilidad, etc-bilidad, la velocidad con que resuelve los problemas cae sensíblemente. Igual pienso que para un buen programador sigue arriba del promedio, y que su repercusión en el futuro aumentará tarde o temprano este factor si el proyecto vive lo suficiente. Por otro lado, sí es cierto que un programador malo es 10x o más (mucho más) veces peor que uno bueno. Y en nuestra industria abundan, porque (para nuestra tranquilidad) a veces hay más demanda que oferta en cuanto a trabajo, pero esa es otra historia.
Por el momento, exista o no, todos aspiremos a serlo algún día. Pero esperemos que ese día no llegue nunca, porque así tendremos que seguir creciendo. Y si hay algo que la experiencia me repite una y otra vez, es que nunca me van a faltar errores de los cuales aprender.
Muy bueno el articulo, leí el original también..
ResponderEliminary felicitaciones por el pseint, lo uso para la facu, es excelente!
Saludos!
Buen post
ResponderEliminar