EDICIóN GENERAL
196 meneos
4852 clics

El mítico programador "10x" (10 veces más productivo): ¿existe realmente? [ENG]

Si ningún atleta corre 10 veces más rápido que otro, ni un obrero construye 10 veces más que otro, ¿puede un programador ser 10 veces más productivo que otro, cómo a veces se asegura? Así lo defiende este programador, basándose en la naturaleza no lineal del SW y el efecto multiplicador de grandes diferencias en: habilidad al implementar sub-tareas y debugar, experiencia, sacrificios en el diseño, simplicidad de las soluciones, rechazo del perfeccionismo, conocimientos teóricos y de HW... [ Vía: news.ycombinator.com/item?id=13752887 ]

etiquetas: programador , sw , software , productividad , no lineal , efector multiplicador
Comentarios destacados:                            
#10 Sí existe. Yo conozco personalmente al programador 10x, que sale a fumar 10 veces por la mañana y otras 10 por la tarde. Y también al que toma 10 cafés, al que repasa el Marca 10 veces...
Me pareció un artículo muy acertado, que da en el clavo tanto en las habilidades generales críticas para un programador, como sobre todo en el efecto multiplicador de éstas sobre su productividad a medio/largo plazo, y en la no-linealidad del trabajo.

Clave es el hincapié que hace en mantener un diseño lo más simple posible, convenciendo "a los de arriba" de las nefastas consecuencias de una innecesaria complejidad. (Esto, dicho sea de paso, es tarea del programador, no se puede…   » ver todo el comentario
#1 ese programador se da cuenta que a los de arriba se la suda y lo único que consigue es perder tiempo y esfuerzo.

Decidiendo invertir ese tiempo en meneame, reddit o mirar la pared.
#1 un maestro mío nos hablaba en términos de optimización de un factor de 100x. Mantenibilidad ya es otro tema.
#1 Convenciendo a los de arriba.. y a los de al lado también. ;)
#1 Me ha gustado mucho el artículo.

Y tu comentario me ha gustado bastante pero podría una pega:
Cuando dices:
"Clave es el hincapié que hace en mantener un diseño lo más simple posible, convenciendo "a los de arriba" de las nefastas consecuencias de una innecesaria complejidad."
pareces dar a entender que el artículo hace hincapié en convencer "a los de arriba" y al menos yo no vi nada de eso en el artículo.
Creo que el artículo señala con bastante…   » ver todo el comentario
#1 ese factor 10x se me queda corto entre lo peor y lo mejor que he visto...

Coño pero es habra que poner limites en lo que se compara... si comparamos a algunos """"juniors""" con los que he trabajado y un senior del monton la diferencia es de un 999999x ...
#1 A mi lo que me extraña es que desarrolla muy bien el planteamiento de como pequeños procesos bien ejecutados aumentan el rendimiento, y no hace ningún tipo de referencia al lenguaje de programación.

Esta comprobado que con lenguajes como python se programa mucho mas rápido que en C pero, esa programación mas rápida se traduce en un rendimiento inferior por parte del programa.
#88 "no hace ningún tipo de referencia al lenguaje de programación"

Es que precisamente lo que explica es válido para escribir un programa en C, Java, Phyton... y en gran medida también para escribir una libro de recetas gallegas.

Para el libro de recetas tendrás que aplicar muchas cosas que usas en SW:
- "Divide y vence": separa tu libro en apartados (mariscos, cocidos, sopas, carnes...) y a su vez con sub-capítulos (cocidos de lentejas, de alubias, de…   » ver todo el comentario
#90 Ya ya
Me refería a que no hace referencia a las herramientas.

Como tu dices, es como el método para escribir recetas, pero no entra en la diferencia entre usar una olla en un fuego de leña, de gas o en una olla express.

La receta es lo mas importante, pero las herramientas también influyen, y ahí puedes sacar ventaja.

Vamos que programando peor, puedes programar mas rápido en python que en C.
#1 Me acuerdo de un proyecto en Github, dado el siguiente programa:

- Pedir un numero al usuario.
- Si el numero es modulo 3, imprimir "Foo"
- Si el numero es modulo 5, imprimir "Bar".
- Si el numero es divisible entre 3 y 5, imprimir "FooBar"
- Repetir hasta que se introduzca un cero.

Lo hicieron en Java implementando técnicas de diseño de la forma más estricta posible: Interfaces, factorys... Hasta creo un objeto para hacer el bucle while (con su interfaz y su factory por supuesto).

Que pena que no lo encuentre, porque era muy buenísimo.

EDITO: Lo encontre:
github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
"debugar"? los barbarismos están llegando demasiado lejos.
#2 Yo lo uso: debugar, jarcodear, tracear, logar... Soy un mal español, lo se. :-(
#9 no sé, pero lo que sí sé es que suena fatal. Usarlo acompañado de "hacer", un debug, un ping, vale, y "logar" aún psé, pero "tracear"? "jarcodear"? Eso es otro nivel xD
#11 Updatear, escapar (convertir un carácter en la secuencia de escape correspondiente), comentar (convertir una línea de código en un comentario, para que no se ejecute), linkar... :-( Mi idioma es un horror, lo se. :-(
#12 comentar... eso es castellano, eh?
#13 Sí, aunque con el significado algo cambiado. Aunque si te gusta el tema, puedo seguir: zipear, deployar, serializar... Ah, y descomentar, que es volver a activar una línea de código que "comentaste".
#14 que yo también soy informático, pero no uso tantos, creo. Por cierto, soy más de rarear que de zipear :-D
#15 Igual usas más de los que crees. Presta atención y te descubrirás usando muchos sin darte cuenta.
#16 soy consciente, créeme.
#12 el que más repelús me da es "hostear"
#27 Es peor cuando se habla de hostiar.
#12 No, lo que pasa es que tu lenguaje ni es muy rico ni variado.
En Castellano existen los equivalentes a todas las palabras que estás inventando:

Depurar, actualizar, tracear, etc.
Yo he trabajado con uno así. Menudo chapucero. ¿Una tarea que nos obligaría a rediseñar la BD? No pasa nada, reutilizamos este campo, aunque originalmente no tuviera nada que ver, metemos un par de «switch case» por aquí y por allá, y voilá, problema resuelto en 10 minutos. Productividad total.

Lo peor de todo es que me pregunto si no será eso lo correcto.

#73 ¿Seguro que «tracear» está en el diccionario?
#74 Es lo correcto cuando en tu empresa sois cuatro y no esperáis tener que mantener el producto durante años.
Conozco un caso tal que ese en una empresa, con un producto que se parcheó cambiando el uso de una columna de la bd que solo se había usado para las migraciones de versiones anteriores, y metiendo un par de líneas aquí y allá.
Tiempo después, los instaladores de otra sede de la empresa estuvieron casi un con una incidencia que les retrasaba la puesta en marcha de la maquinaria en el cliente, y no entendían por qué pasaba, porque no relacionaban el error en esa columna con el fallo real.
Y el cliente estaba que fumaba en pipa, y la empresa perdió un pico de dinero por la broma.
#12 apt-getear xD
#12 Ojo con deployar! jajaja En mi ámbito usamos todas las que comentas y nadie murió aún.
#11 trazar por $deity, trazar.

Y comentar no pierde significado...
#47 prefiero "hacer una traza" que "trazar", es sutil pero importante la diferencia.
#50 ¿Prefieres "hacer una traza" que "trazar" pero usas "rarear" en vez de comprimir? Pardiez! Menos mal que no targezeteas....
#54 en realidad digo "comprimir", lo de rarear lo digo en coña. Por ejemplo, si alguien es de estatura reducida se puede decir que está "rareada" ;)
#11 #9 yo prefiero debuguear y loguear (aunque ahí no se sabe si haces login o metes algo en el log xD). Y comitear!
#78 logar más que loguear, aunque depende de la persona en la frase, es decir, yo me logo, pero él se loguea.
#84 qué tal "iniciar sesión"? xD
#93 también lo uso.
#84 yo me logueo
#9 el imperio de turno influencia demasiado sobre las mentes más débiles :-P
#2 Con lo bonita que es el la palabra depurar.
#19 excepto cuando la acompaña "responsabilidades", entonces entra un canguelo...
#19 y hospedar.
#2 Luego te forguardeo el memo del brieffing.
#28 no lo has atachado... xD
#2 Desde luego, una cosa es que los usemos y otra muy distinta que los escribamos en lugares públicos. Un poquito de escrúpulos, por favor.
#2 GITanear
O infinito. Yo he trabajado con gente que no sabe resolver un problema.
Si existe. No lo conozco personalmente, pero conozco su trabajo. Si algún día alguien me lo presentan, le voy a cortar la cabeza de un tajo, por la mierda de código que programó. ¡Maldito seas Víctor, hijo de la gran puta!
Ya tengo un caso real. Trabajo presupuestado en 300 horas. Tiempo de realización: 12 horas (incluyendo los 10x cafés que dice #10 ). Código limpio y conciso(*). Defectos en la fase de pruebas: 0. Defectos en piloto: 0.
realmente no es un programador 10x, la proporción dice que es 25x.
(*): quizá el siguiente que lo coja se puede quejar de que esperaba miles de líneas y cuando va a ver solo encuentra decenas pero bien estructuradas y se mosquea como dice #4
cc/ #22
#61 A lo mejor eso que cuentas no es un caso de "programador x10", sino de "estimador /10". Vamos, que valoraron el trabajo mal, o pensando que se iba a programar mal.
#70 y a lo mejor no.
#61 Si presupuestas 300 horas y lo haces en 12 es que el cliente no tiene mucha idea y tú le has engañado vilmente :troll:
#75 ¿ Y por qué me lo dicen como ejemplo de una persona productiva ? Si se dedican a eso y hacen cientos de proyectos tanto ellos como el cliente, supongo que algo sabrán.
O no, a lo mejor siguen yendo al tuntún después de tantos años.
No acabo de decidirme si el mundo está lleno de inconscientes y todos los programadores tienen la misma productividad o si por el contrario hay personas buenas y malas, los que programan más y mejor, los que sacan sobresaliente en el colegio...
Y 100x también.
Existen, todo depende el tipo de proyecto y los tipos de programadores. Es muy fácil encontrar diferencias de 10x o más entre ellos. Yo he sido testigo de varios.
Hay tareas que simplemente no las puede hacer todo el mundo, algo que alguien hace en un día a otro puede costarle meses, por ejemplo si hablamos de hacer formularios pues ahí es difícil sacar ventaja a fuerza bruta, más o menos tardará todo el mundo lo mismo, cargar la vista, las validaciones, etc. no puedes ser mucho más rápido, pero luego te encuentras al que en vez de hacer los formularios hace el motor que los genera dinámicamente, ahí la productividad es de 100x.
Existe, en contadas ocasiones; ejemplo épico: {0x1f4fc} www.youtube.com/watch?v=08PmIv1l5LY :professor: :troll:
#8 ¿Existe Novell aún?
#42 Podríamos decir que si; actualmente es una división de Micro Focus: {0x1f517} en.wikipedia.org/wiki/Micro_Focus

/cc #8
#43 Madre mía, casi lloro de la nostalgia. Pues no he escrito lineas en COBOL
Sí existe. Yo conozco personalmente al programador 10x, que sale a fumar 10 veces por la mañana y otras 10 por la tarde. Y también al que toma 10 cafés, al que repasa el Marca 10 veces...
Lo normal en esta profesión, es que los más productivos vayan alejándose de la implementación y pasar a análisis/arquitectura del software y coordinación de equipos, así que su mayor pericia programando la usan en supervisar al resto.
#21 O al revés yo conozco algún analista de los que mientras funcione pasa del tema.
#21 Mi experiencia es justo la contraria.
#25 Osea que conoces un 0.1x programmer. Por lo tanto un 1x será 10x en comparación.
#33 No, mi experiencia es que el programador 10x se queda como programador Senior, Arquitecto o cualquier puesto de ingenieria o desarrollo, pero no pasa a gestión ya que es desperdiciar su talento.
#21 Correcto.Yo era el 10x (O 5x) pero ya apenas toco código
Sí existe. Como cuando se estudia existe el que saca sobresalientes sin aparente esfuerzo.
Solo que hay pocos.
#22 cuando llevas un tiempo en el mundillo te das cuenta de que hay gente simplemente excepcional, las estadísticas de productividad no les aplican, tienen un don natural. Los demás somos simples mortales intentado ganarnos el pan jajajaja
#31 En mi opinión, los que tienen "un don natural" en vez de estar a las 9:00 am del domingo escribiendo en menéame están programando alguna cosilla interesante.
Ahí el problema está en que contar como base, conozco a alguno que es """programador""" (y trabaja de ello!!) y claro, alguien que sepa del tema es un programador x10 comparandolo con ese como base.
Claro que existen programadores el doble de productivos que otros. ¡Qué preguntas!
#26 Hay 10 tipos de meneantes: los que han entendido el chiste y los que no.
#32 hay 10 tipos de programadores: los que creen que saben y los que saben quien sabe.
#39 Y aquí de poco saldrá el que sabe y no sabe a la vez.
#32 Y los que se dan cuenta que esa broma está en ternario
¿Debugar?
¿Peo eso que eh?
O lo ha escrito a propósito o es perezoso er mushasho o Qué se yo que, er caso eh que eh una barbaridá.
Si la tontería volara algunos no bajaban ni a beber.
La mayor parte del tiempo de desarrollo viene determinado por las decisiones que toma el arquitecto del sistema.
#30 eso de tener programador, analista y arquitecto es bastante estúpido, en mi pueblo el que diseña algo es el que lo implementa, eso de separar responsabilidades es para modelos verticales de organización que suelen coincidir con ser los sitios donde peor calidad hay (de empleados y resultados)
#34 Exacto.

Todos deberían implementar y diseñar, los programadores Junior podrían tener un poco más de supervisión pero es todo.
#34 Te puntualizo: quien lo piensa debería implementarlo, pero es necesario un arquitecto cuando hay tropocientas personas tocando lo mismo.
He trabajado en una gran teleco donde había tres subcontratas y cientos de programadores trabajando en distintos proyectos en paralelo.
Era un infierno recuperar algo de las bases de datos porque para asuntos similares, cada una era de su padre y de su madre, con criterios cambiantes, debido a que se habían creado dentro de proyectos distintos. Y encontrar…   » ver todo el comentario
Sí, existe... Y lo llamamos programador de mierda porque también introduce 100x vectores de ataque al software resultante.

Vale que se puede ser más eficiente cuando preparas herramientas de apoyo y personalizas el editor (más de la mitad de mi código lo escribo mediante mini-plantillas y mis propios generadores) pero, que algo funcione, no significa que esté bien construido (como AWS nos demostró hace poco).
c&p I win ;) everything's a remix....
Vaya si existe. Yo conozco varios, y me puedo incluir entre ellos.
Es llamativa la cantidad de personas trabajando en este sector que no se ayuda a sí misma haciéndose herramientas para facilitarse el trabajo, por no invertir un poco de tiempo.

Yo conseguí (y esto al poco de empezar) reducir una tarea que necesitaba unas 150 horas de trabajo manual y que necesitaba de conocimientos específicos, muy propensa a errores y correcciones a un proceso semiautomático que lleva entre 1 y 3 horas y…   » ver todo el comentario
#40 Yo soy abogado.

En una empresa en la que trabajé un grupo de trabajo a mi cargo tenía que elaborar respuestas jurídicas (las cuales incluían también fotografías de ciertos casos) a diferentes peticionarios. En total, se generaban cientos por día.

Con la ayuda de ciertas librerías gráficas como GD realicé un código que manipulaba las imágenes de manera tal que las recortaba, añadía marcos, manipulaba el tamaño, incluía algún filtro, etc.

Luego con ayuda de otra librería, en este caso de…   » ver todo el comentario
#40 "Los mejores programadores son las personas perezosas" No sé dónde lo leí, pero le doy la razón. Tu caso es extremo, pero es habitual que haya gente a la que no le importe hacer trabajos repetitivos y aburridos que toman un par de horas en vez de invertir algún día en que sea automático y tarde minutos.
#40 Tengo una parecida, yo tampoco soy programador profesional pero soy físico y algo sé. En la empresa en la que actualmente estoy aluciné en mi primer día, resulta que de madrugada se hacían diariamente 20 informes para un cliente, nada complicado un par de análisis de datos en Excel pero era un rollo tremendo porque los datos se recogían en un formato y había que transformarlo en otro para excel, revisarlo, enviarlo, etc. Cuando llegué me explicaron que se hacían uno a uno a mano: copia…   » ver todo el comentario
#40 #77 Yo estuve en un proyecto en el que cada mañana había que ejecutar unas querys, exportar los resultados en unas hojas excel para copiarlos y pegarlos a otras hojas que realizaban unos cálculos (cuadres). En un par de días me hice un script que ejecutaba al llegar al curro, me iba a tomar el café, y cuando volvía tenía todos los informes hechos... me ahorraba unas 4 horas de trabajo al día.
Tiene gracia que esto lo diga antirez, que él solito se picó la base de datos Redis, y que a día de hoy sigue manteniendo en un 90%.

github.com/antirez/redis/commits/unstable
Programar no es apretar tornillos, tiene una buena parte de arte.

La comparación con otras actividades no es del todo correcta. Si te dicen que alguien dibuja 10x mejor que otro yo podría decir que cualquiera lo hace 1000x mejor que yo por mucho que practique y me quedo corto.

Este oficio tiene una parte de aprendizaje y otra de arte/dotes naturales/factor X o como quedamos llamarlo.
#46 No estoy de acuerdo
De hecho, en una empresa ideal todos los programadores escribirían el código igual y sería imposible diferenciarlo a simple vista, siguiendo unos procesos estandarizados.
#53 y en un colegio ideal todos los estudiantes sacaban un cinco, claro.
Creo que ya va siendo hora de asumir que hay personas distintas.
#55 Puede hacer personas diferentes. Pero si la empresa lleva una guía de buenas prácticas en el código. Si el IDE formatea el código a todos por igual con las mismas reglas... No tiene por qué ser diferente.

Hace un tiempo sí que había más diferencias. Hoy se tiene muy estudiado qué es más limpio, escalable y simple. KISS, DRY, SOLID...

Luego, en mi experiencia, los mejores programadores son los que gastan horas y horas diarias de su tiempo libre en seguir programando. Pura y dura práctica. Entre personas que ocupan el mismo puesto puede haber decenas de miles de horas de práctica, y eso se nota muchísimo.
#58 Vamos a ver, el punto de partida es el análisis. Si se hace análisis para ver cuál es el problema, es que a priori no se sabe y el oficio de analista es ese: decidir cómo plasmar en algoritmos algo que en su presentación inicial no está ni siquiera formalizada y que posiblemente no esté ni bien definido el alcance. Desde ese punto de partida y hasta el momento en que se escribe la última línea el trabajo es ir añadiendo pasos desde lo etéreo del problema inicial a lo científico del…   » ver todo el comentario
#63 He trabajado como programador en media docena de empresas y nunca he visto que los sistemas los diseñen personas que luego no las programan.

Tal vez sea cosa de cárnicas, con exceso de burocracia. Pero la gente que conozco que ha trabajado o trabaja en cárnicas tampoco me han hablado nunca de ese método.

De todas formas, sin duda habrá diferencias entre personas, pero son irrelevantes. Cuando comparas a un tío que empezó a programar en la carrera y lleva cinco años en alguna empresa y…   » ver todo el comentario
#80 <<De todas formas, sin duda habrá diferencias entre personas, pero son irrelevantes>>
Bueno, si eso eso es así porque lo dices tú, nada más que hablar.
#80 perdona en #81 que no ha sido mi expresión más amable. Estoy seguro que si seguimos con el tema, acabamos llegando a puntos de entendimiento 8que supongo puedes imaginar por dónde irán) a pesar de que las posiciones de partida aparentemente puedan parecer distintas.
Lo que pasa es que estoy un poco liado y no tengo tiempo :-P
#89 No te preocupes, gracias por la aclaración :-)
#58 Hombre un buen dibujante tambien ha echado horas y horas para perfeccionar la tecnica...pero sin creatividad nadie innovaria con nuevos algoritmos
#53 Una cosa es compartir metodología y otra lo que planteas. Eso no es un ideal, es una cadena de producción de código ... Un error más basada en la idea de que el desarrollo no es una tarea creativa.
#53 esa empresa ideal acabará sustituyendo los programadores por scripts :-D
Bah, en serio. Depende de a qué se dedique la empresa, este mundillo es muy grande.
Hay gente trabajando en cosas para las que ni ellos ni nadie tiene experiencia previa, son los que abren el camino por el que luego pasan los demás. En programación hay innovación constante.
Esa gente que está ahí haciendo veta no solo tienen que tener mucha experiencia si no también mucha inteligencia y una capacidad superior para resolver problemas desconocidos, que va mucho más allá de aplicar tal cual receta porque ¡ellos están inventando la receta! Ahí es donde un auténtico programador-ninja-artista quiere ir.
Muy buen artículo. Destacando algunas cosas que pueden parecer obvias y otras que no tanto. En mi último trabajo por cuenta ajena mi empresa contrató unos cuantos "cracks", gente habitual en charlas sobre diferentes tecnologías, especialmente mentalizados con estructuras y código limpio. Hasta la locura, no aplicaban las herramientas con sentido común sino porque en algún libro les decía que siempre tenía que hacerse así.

Gente que, curiosamente, no era productiva. La sobreingeniería…   » ver todo el comentario
#56 Por si acaso , un apunte. También contrataban a cracks que también daban charlas y que tenían sentido común y hacían código limpio, sencillo, escalable y útil. Porque sabían entender cuando había que escribir alguna ñapa
Si, se le llama experiencia y las comparaciones depende de los "otros". Ale, y ahora me voy a leer el articulo xD
El que ha escrito esto no sabe que hay competiciones de programación donde puede encontrar a los mejores del mundo?
En casi todas las profesiones de tipo intelectual pasa esto, mientras que en los trabajos físicos no se nota tanto. Pero no es algo que se pueda medir de forma exacta. Por ejemplo, puede haber programadores que terminen sus tareas en muy poco tiempo pero de una forma tan cutre que lleve mucho trabajo a sus compañeros poner las cosas en orden. O también puede haber programadores muy buenos pero que no sepan trabajar en equipo, cosa bastante habitual: gente mandona y egocéntrica que a veces fuerzan a que los demas se tengan que adaptar a decisiones incorrectas que acaban en meses de complicaciones.
El programador 10x no sé si existe, el que si que existe es el /10, que produce la décima parte de lo normal :troll:
#69 y menos, recuerdo un caso de delito penal de un programador (con título universitario y tal, no te creas) que estuvo una semana haciendo un comando ¡en C! para algo que se podía hacer...con un "grep". No lo acabó porque le vi y le corté, pero ahí estamos hablando de /1000 y ¡de que hay que prestar más atención a las expresiones regulares en el cole!
#87 Si tuvo unos profesores como los míos, no me extraña. Yo he tenido profesores que te decían que tirar de la biblioteca estándar del lenguaje era hacer trampas, pretendían que lo programaras todo tú a pelo.
#91 yo creo que eso tiene sentido para educarse, está bien ser capaz de implementar la biblioteca estándar. Pero una vez que sabes hacerlo, también tienes que saber no hacerlo :-D
O saber distinguir entre un entorno académico y uno profesional, no te "premian" las mismas cosas, ni te enfrentas a los mismos problemas.
#92 A ver, es lógico que en una asignatura de estructuras de datos te obliguen a implementarlas tú, porque de eso se trata. Pero en este caso era una asignatura de compiladores, y pretendían que implementáramos nosotros la tabla de símbolos, que no deja de ser un array asociativo. El problema es que la profesora ni se sabía la STL, me empezó a reñir por una tontería y le tuve que sacar la referencia oficial para demostrarle que estaba equivocada.

Como decía un colega mío, hemos aprendido a ser buenos programadores a pesar de la universidad.
#97 es que, simplemente, no da tiempo en la universidad a aprender lo suficiente. Para programar bien de verdad hacen falta muchos años, aunque puede costar aceptar cuando se termina la carrera de que se está en el inicio de un laaaaargo proceso de aprendizaje que no terminará nunca.
Pero no solo pasa en informática, pasa en muchas otras profesiones, que tampoco se terminan nunca de aprender (y también hay muchas diferencias entre la gente, no todos los que acaban física ganan un nobel)
#99 Ya bueno, y que en ciertas ramas los profesores no tienen experiencia profesional real, y cuentan lo que han leído en los libros sin haberlo llevado nunca a la práctica. Que me pasé un montón de años de técnico de apoyo y lo vi desde dentro :-D
Existe el programador 100X.

Si comparamos el programador promedio, éste programador hace las cosas 100 veces más rápido. ¿Por qué?. Porque el problema no es programar, el problema es la complejidad, y ésta va a aparecer por mala programación, el tamaño del código mientras se va haciendo grande, mal diseño, falta de planificación, etc.

El programador 100X usa un tiempo para programar como todos los demás, pero también emplea una buena cantidad de tiempo en combatir la complejidad,…   » ver todo el comentario
#72 Adicional.

El programador 1.000.000.000 X es el que se inventa cosas que son ampliamente usadas por los demás, como por ejemplo los que se inventaron las estructuras dinámicas como listas encadenadas, árboles, grafos, etc, los que se inventaron algoritmos como balanceo de árboles, camino más corto de grafo, neuronas artificiales (como el perceptrón), etc, el que trajo los patrones de diseño de la arquitectura a la computación, etc, etc, etc. Estos programadores trabajan y tienen un amplio…   » ver todo el comentario
Programador 10x que regala una deuda técnica de 100x para sus colegas.
Seguro que existen, los he conocido, pero gracias a grandes gestores y mejores consultores los han convertido en 0.5x.

Tb los he conocido 10x (o más) que visto como les agradecían su trabajo (a fin de mes), se han autolimitado a 1x, hasta que conseguían mudarse de compañía.
#82 puedes estar hasta los webs y largarte de la empresa, pero un programador "10x" no puede autolimitarse a 1x, porque eso significaría escribir 10 veces más código para hacer lo mismo, que es la clave del asunto. A nadie le gusta teclear más sabiendo cómo teclear menos.
Otra cosa es que aproveche sus poderes ninja para acabar antes y gastar el resto de tiempo en tocarse las pelotas, eso sí es muy posible :-D pero serán casos de extremo malestar en el trabajo, ya que si algo caracteriza a un buen programador es que le gusta programar.
Yo llevo programando más de 25 años de forma ininterrumpida laborales y no laborales, que le digan a mi mujer :-)
Bien, en este tiempo puedo certificar que las diferencias entre programadores pueden ser abismales.
Recuerdo casos de módulos de 20.000+ líneas de C++ re-hechos en unas 500, trabajos que han llevado más de un año a un mal programador repetidos por uno bueno en un mes, y por supuesto pasando de innumerables bugs a muy pocos.
En términos de rendimiento también he visto funciones…   » ver todo el comentario
#83 por fin alguien que sabe de lo que se habla :hug:
«12
comentarios cerrados

menéame