Portada
mis comunidades
otras secciones
#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...
#1:
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 esperar de un manager que sea consciente de la "explosión de complejidad", alguien de SW tiene que advertirle del peligro).
Además no cae en posturas extremistas, alertando expresamente contra perfeccionismos. El 10x puede parecer muy exagerado, pero yo mismo he leído códigos de muy distintas calidades, y ese factor 10x se me queda corto entre lo peor y lo mejor que he visto...
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 esperar de un manager que sea consciente de la "explosión de complejidad", alguien de SW tiene que advertirle del peligro).
Además no cae en posturas extremistas, alertando expresamente contra perfeccionismos. El 10x puede parecer muy exagerado, pero yo mismo he leído códigos de muy distintas calidades, y ese factor 10x se me queda corto entre lo peor y lo mejor que he visto...
#2:
"debugar"? los barbarismos están llegando demasiado lejos.
#7:
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.
#83:
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 pasar de segundos a milisegundos, o de necesitar megas de memoria a bytes.
El resumen de mi experiencia por no hacer largo el comentario es que los buenos programadores son más productivos porque escriben mucho menos código y con muchos menos bugs para hacer lo mismo, y además ese código es sólido y mantenible en el tiempo.
Por supuesto esas diferencias se ven más cuanto más compleja sea la tarea.
Otra cosa que he aprendido es que nadie es experto en todo, incluso con décadas de experiencia todos tenemos nuestro talón de Aquiles, a unos se les atragantan las matemáticas, a otros el bajo nivel tocando hardware...
Para hacer un proyecto complejo es esencial seleccionar bien a la gente, y nunca jamás dejar a un equipo de inexpertos sin un líder experto.
Luego hay programadores que yo llamo "naturales" que disfrutan programando (acaban siendo ninjas) y gente que realmente no le gusta y siempre serán mediocres aunque mejoren.
En fin ya lo dejo.
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 pasar de segundos a milisegundos, o de necesitar megas de memoria a bytes.
El resumen de mi experiencia por no hacer largo el comentario es que los buenos programadores son más productivos porque escriben mucho menos código y con muchos menos bugs para hacer lo mismo, y además ese código es sólido y mantenible en el tiempo.
Por supuesto esas diferencias se ven más cuanto más compleja sea la tarea.
Otra cosa que he aprendido es que nadie es experto en todo, incluso con décadas de experiencia todos tenemos nuestro talón de Aquiles, a unos se les atragantan las matemáticas, a otros el bajo nivel tocando hardware...
Para hacer un proyecto complejo es esencial seleccionar bien a la gente, y nunca jamás dejar a un equipo de inexpertos sin un líder experto.
Luego hay programadores que yo llamo "naturales" que disfrutan programando (acaban siendo ninjas) y gente que realmente no le gusta y siempre serán mediocres aunque mejoren.
En fin ya lo dejo.
#44:
#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 JS, hice un botón para subir todas las imágenes de forma masiva a un servidor y empezar el proceso. Al final el resultado era un archivo word con la respuesta jurídica (de acuerdo al caso escogido) y las imágenes dentro de dicha respuesta.
La verdad es que ese código ahorraba horas y horas de trabajo, aparte de eso, utilicé la base de datos de OpenStreetMap y cree una con las incidencias en los sectores de la ciudad en donde sucedía lo que solicitaban, etc.
Más interesante aún era que en dicha empresa prohibían ejecutar cualquier tipo de programa diferente a office y menos aún código así que me las arreglé para montar un servidor en una USB y ejecutar mi código desde allí.
Considerando que soy abogado, lo anterior no es para decirte que tengo la polla mas grande que tu. Pero si.
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 JS, hice un botón para subir todas las imágenes de forma masiva a un servidor y empezar el proceso. Al final el resultado era un archivo word con la respuesta jurídica (de acuerdo al caso escogido) y las imágenes dentro de dicha respuesta.
La verdad es que ese código ahorraba horas y horas de trabajo, aparte de eso, utilicé la base de datos de OpenStreetMap y cree una con las incidencias en los sectores de la ciudad en donde sucedía lo que solicitaban, etc.
Más interesante aún era que en dicha empresa prohibían ejecutar cualquier tipo de programa diferente a office y menos aún código así que me las arreglé para montar un servidor en una USB y ejecutar mi código desde allí.
Considerando que soy abogado, lo anterior no es para decirte que tengo la polla mas grande que tu. Pero si.
#40:
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 además sin errores (y además cambiar cosas es casi instantáneo cuando antes obligaba a rehacerlo todo). Hacer la herramienta me costó 3 o 4 días de dolor de cabeza y apurones con otras cosas, pero vaya si mereció la pena, más que nada porque quien más se benefició fui yo mismo.
Conseguí hacer eso no sólo con procesos rutinarios para mí, sino también para compañeros en otras ramas de la oficina. La gente (especialmente la gente ajena a la informática) agradece mucho librarse de rutinas tediosas que les llevan varias horas por semana y en las que es fácil cometer errores y quita tiempo para lo importante. Los compañeros pasaron de estar contínuamente al borde de un ataque de nervios por exceso de tareas a tener tiempo para atender otras cosas o símplemente para relajarse de vez en cuando. Y además te escuchan porque saben que si sugieres alguna mejora es realmente para bien.
Cuando la eficiencia que aportas es indiscutible, no te pueden toser, y no les queda otra que mantenerte contento.
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 además sin errores (y además cambiar cosas es casi instantáneo cuando antes obligaba a rehacerlo todo). Hacer la herramienta me costó 3 o 4 días de dolor de cabeza y apurones con otras cosas, pero vaya si mereció la pena, más que nada porque quien más se benefició fui yo mismo.
Conseguí hacer eso no sólo con procesos rutinarios para mí, sino también para compañeros en otras ramas de la oficina. La gente (especialmente la gente ajena a la informática) agradece mucho librarse de rutinas tediosas que les llevan varias horas por semana y en las que es fácil cometer errores y quita tiempo para lo importante. Los compañeros pasaron de estar contínuamente al borde de un ataque de nervios por exceso de tareas a tener tiempo para atender otras cosas o símplemente para relajarse de vez en cuando. Y además te escuchan porque saben que si sugieres alguna mejora es realmente para bien.
Cuando la eficiencia que aportas es indiscutible, no te pueden toser, y no les queda otra que mantenerte contento.
#34:
#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)
#52:
#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.
#46:
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.
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.
Comentarios
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...
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
#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...
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 esperar de un manager que sea consciente de la "explosión de complejidad", alguien de SW tiene que advertirle del peligro).
Además no cae en posturas extremistas, alertando expresamente contra perfeccionismos. El 10x puede parecer muy exagerado, pero yo mismo he leído códigos de muy distintas calidades, y ese factor 10x se me queda corto entre lo peor y lo mejor que he visto...
#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 acierto muchos de los 'problemas' a los que se enfrenta un programador, las actitudes que debería tener para ser un fuera de serie, etc... pero no afina hasta el último detalle que dices tú, es decir, no aclara si debe "convencer a los de arriba" (que se entiende que son los jefes ¿jefe de proyecto? ¿otros jefes?) o si, como dice #38 , debe convencer a los de al lado (muchas veces el jefe no dice "cómo" hacerlo sino el "qué" debe hacer... y el "cómo" puede ser algo que se deje al consenso de varios programadores que se ponen de acuerdo sobre cómo afrontar el problema) o si quizá en algún caso debería persuadir al cliente (ya sea al cliente en sí mismo, la persona que decide contratar y pagar por un desarrollo software o una persona influyente cercana al cliente, que aunque no sea el que paga ni el que tiene la última palabra sí puede saber cómo convencerle y hacerle ver las ventajas de un cambio sobre la propuesta inicial) o si quizá debería tener más de una conversación seria con el comercial...
Lo del comercial creo que merece mención aparte. La misión del comercial parecería muy claro decir que es vender, que suele ser conseguir que un cliente firme un contrato para desarrollar algo... pero ya no es tan claro si entre las argucias que puede tener permitidas o consentidas ese comercial estarían la de engañar al posible cliente con falsas promesas: desde conseguir una eficiencia del software que técnicamente es imposible o muy difícil de conseguir hasta la más común: prometer que el proyecto se hará a un precio muy bajo o que quedará acabado en un plazo muy corto.
Nos llevamos las manos a la cabeza con sobrecostes en obras públicas como el AVE a la Meca o el Canal de Panamá o un edificio. Vamos a ver ¿no han construido ya líneas de AVE y saben lo que cuesta un kilómetro? Saben lo que cuestan los materiales, la mano de obra, etc... pues no atinan, oye, les cuesta el triple de lo previsto. Lo mismo con un edificio ¿no saben con bastante precisión la cantidad de material y horas de trabajo necesarias así como lo que cuesta la hora de trabajo de cada empleado? ¿acaso no saben lo que costó hacer edificios similares? Pues tampoco aciertan. Incluso en Alemania hay algún caso que costó ¡¡10 veces más de lo previsto!!! ¿Acaso ocurren catástrofes imprevistas que disparan los costes? No parece que sea el motivo. Bueno, parece claro que el problema no es que calcular el coste en esos casos sea como acertar la primitiva sino que el problema es que el comercial tiene que ofertar un precio menor del real para que el cliente se decida por él y no por otro de la competencia... Bueno, pues si en obras más "físicas" (que encajarían literalmente en lo que los anglófonos llaman "brick and mortar") se dan esas falsas promesas a los clientes, cuánto más ocurre con los proyectos de software donde no es fácil predecir las "líneas de código" o las horas de trabajo que puede llevar, y, claro, el comercial suele estar incentivado para vender más y eso implica ofertar plazos irrealizables o especificaciones mágicas prácticamente irrealizable... y que, como dije, no me parece tan sencillo de calcular como en obras más físicas con lo cual un fallo en el presupuesto inicial parece más perdonable. Ante este panorama, es habitualmente el programador o programadores quienes cargan con el marrón: "hay que hacer este software maravilloso en solamente 2 meses" y es ahí donde un programador fuera de serie con experiencia en hacer cosas rápido y reducir plazos y reducir problemas puede al menos evitar el gran desastre de que eso se demore un año... si no se puede hacer en 2 meses al menos puede lograr que se haga en 2 meses y medio o 3, y si no se puede hacer la magia imposible prometida, al menos hacer algo muy similar que sea razonablemente aceptable y posible.
Esa es otra, que el artículo habla de 10x pero no dice qué... yo he supuesto que es hacer un megaproyecto en 1/10 del tiempo de lo que tardaría un programador.... pero también puede ser muchas otras cosas, como 1/10 en el coste total del software, a lo largo del tiempo de vida del mismo: las caídas de un software, errores, fallos de seguridad, costes de mantenimiento, etc. O podría ser, por ejemplo, hacer que un software corra 10 veces más rápido... que si se va a instalar en miles de máquinas puede ser un gran ahorro de dinero en compra/alquiler de esas máquinas, etc. O puede ser el UX, es decir, la experiencia de usuario que haga el software agradable: fácil de usar, bonito, rápido... lo cual puede hacer que tengan 10x más clientes que la competencia, y, quizá 10x los ingresos que tienen otros. Vamos, que se viene a decir "10 veces mejor" sin saber de qué coño estamos hablando exactamente... y, claro, si no sabemos a qué coño se refiere la pregunta ¿cómo vamos a responder si es posible ese programador 10x? Es otro ejemplo de especificaciones laxas / etéreas / ambiguas. Decir "quiero un programador 10x" o "te prometo que soy un 10x" (que más o menos es lo que parece "vender" el autor del artículo) es tan poco definido como cuando un cliente te dice "quiero un programa que gestionar mis inversiones"... que como no se dialogue con pelos y señales a qué se refiere al final sale una cosa que nada tiene que ver con lo deseado.
#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 garbanzos...).
- "Nombres adecuados": usa nombres que todo el mundo entienda.
- "No te repitas": explica las cosas sólo una vez, por brevedad y por evitar contradicciones: explicas sólo en un punto (en el apartado "salsas") cómo preparar la salsa de tomate, y luego haces referencia a ello en varias recetas, cómo si llamaras a una función (con parámetros, o quizá una clase, por ejemplo, para hacerla con orégano, tomillo u otra especia).
- ...
#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:
https://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
#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
#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
#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
). 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"?
#93 también lo uso.
#84 yo me logueo
#9 el imperio de turno influencia demasiado sobre las mentes más débiles
#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...
#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
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.
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 además sin errores (y además cambiar cosas es casi instantáneo cuando antes obligaba a rehacerlo todo). Hacer la herramienta me costó 3 o 4 días de dolor de cabeza y apurones con otras cosas, pero vaya si mereció la pena, más que nada porque quien más se benefició fui yo mismo.
Conseguí hacer eso no sólo con procesos rutinarios para mí, sino también para compañeros en otras ramas de la oficina. La gente (especialmente la gente ajena a la informática) agradece mucho librarse de rutinas tediosas que les llevan varias horas por semana y en las que es fácil cometer errores y quita tiempo para lo importante. Los compañeros pasaron de estar contínuamente al borde de un ataque de nervios por exceso de tareas a tener tiempo para atender otras cosas o símplemente para relajarse de vez en cuando. Y además te escuchan porque saben que si sugieres alguna mejora es realmente para bien.
Cuando la eficiencia que aportas es indiscutible, no te pueden toser, y no les queda otra que mantenerte contento.
#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 JS, hice un botón para subir todas las imágenes de forma masiva a un servidor y empezar el proceso. Al final el resultado era un archivo word con la respuesta jurídica (de acuerdo al caso escogido) y las imágenes dentro de dicha respuesta.
La verdad es que ese código ahorraba horas y horas de trabajo, aparte de eso, utilicé la base de datos de OpenStreetMap y cree una con las incidencias en los sectores de la ciudad en donde sucedía lo que solicitaban, etc.
Más interesante aún era que en dicha empresa prohibían ejecutar cualquier tipo de programa diferente a office y menos aún código así que me las arreglé para montar un servidor en una USB y ejecutar mi código desde allí.
Considerando que soy abogado, lo anterior no es para decirte que tengo la polla mas grande que tu. Pero si.
#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 columna, añade otra, borra fila, renombrar fichero, guarda, abre otro excel analízalo... Yo, que me considero un vago, y que además tengo una tendinitis en la muñeca, acababa con un dolor tremendo así que me puse a ello, hice una macro en excel muy sencilla, me llevó una semana de trabajo (no tenía casi idea de VBA) pero pasamos de tardar 1,5 horas para hacer los informes a 20', todo automatizado, solo hay que darle al botón y elegir unos pocos parámetros. Ahora 6 años después se sigue usando, imagina la cantidad de horas de trabajo que se han ahorrado.
Por cierto, el resultado que conseguí desde el punto de vista de algún compañero era que "lo hacía por destacar y quedar por encima del resto".
cc #52
#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.
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!
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 pasar de segundos a milisegundos, o de necesitar megas de memoria a bytes.
El resumen de mi experiencia por no hacer largo el comentario es que los buenos programadores son más productivos porque escriben mucho menos código y con muchos menos bugs para hacer lo mismo, y además ese código es sólido y mantenible en el tiempo.
Por supuesto esas diferencias se ven más cuanto más compleja sea la tarea.
Otra cosa que he aprendido es que nadie es experto en todo, incluso con décadas de experiencia todos tenemos nuestro talón de Aquiles, a unos se les atragantan las matemáticas, a otros el bajo nivel tocando hardware...
Para hacer un proyecto complejo es esencial seleccionar bien a la gente, y nunca jamás dejar a un equipo de inexpertos sin un líder experto.
Luego hay programadores que yo llamo "naturales" que disfrutan programando (acaban siendo ninjas) y gente que realmente no le gusta y siempre serán mediocres aunque mejoren.
En fin ya lo dejo.
#83 por fin alguien que sabe de lo que se habla
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 resultado final. ¿ De esos pasos no da ninguno el programador ? ¿ Le llega todo hecho hasta el detalle, con los nombres de funciones, variables, bucles que debe tener cada método y las llamadas entre ellos ? Pues entonces podría ser como tú dices(2), pero la productividad 10x la tienes en las personas de arriba. Hay quien al ver un problema te lo descompone en datos, funciones y algoritmos casi por instinto y quién no tiene esa capacidad y debe aplicar un método aprendido en el que no se siente cómodo y le lleva 10x de tiempo, del mismo modo que hay quien oye una melodía y la escribe en un pentagrama y hay quien por mucho que se entrene falla en todos los dictados musicales.
(2) que tampoco. Hay quien programa con seguridad y siguiendo un camino recto porque sabe que va a funcionar y cómo va a funcionar y quien después de haber dado cientos de vueltas a la codificación sigue sin estar seguro y tiene que hacer miles de pruebas, en el peor de los casos sin tener claro si son ortogonales o repetidas.
P.S.: la experiencia es un grado. Solo es eso, solo un grado. Una persona con capacidad es otro. Hay veces que nos gustaría que el mundo fuera distinto, que la experiencia lo fuera todo y que si uno quiere ser campeón mundial de boxeo solo tiene que entrenar una hora más que el actual campeón mundial. Pero es que el mundo no es así. Hay quien tiene más capacidad de manera innata. Hay que asumirlo.
#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 otro que ya tenía certificaciones oficiales antes de entrar, que multiplica por diez las horas de programación que lleva encima el sujeto anterior, las diferencias son tan enormes que da exactamente igual la capacidad innata de cada uno.
Las diferencias en horas de experiencia son tan gigantescas, que las habilidades naturales son despreciables.
La noticia es muy clara, la ha escrito un tío que sabe mucho de esto, en ningún lado habla de capacidad natural de nadie. Eso sirve en fútbol, donde todos los críos que quieren ser futbolistas han jugado las mismas horas desde su tierna infancia.
#80
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
#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
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.
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
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.
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.
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, simplificando o reestructurando las cosas, así que la complejidad no crecerá exponencialmente con los problemas, sino que tendrá una forma de diente de sierra, es decir, crece exponencialmente un corto tiempo, pero el programador 100X se toma un tiempo para eliminarla y hay un bajón de complejidad. Así, la complejidad generalmente no se sale de control, o en caso de salirse de control, no estará mucho tiempo allí.
El programador 100X es más lento que los demás programadores al principio, pero como, además de programar, aparta tiempo para luchar contra todo lo que tenga el potencial de volverse complejo, muchas veces antes de que se salga de control, en los meses o años siguientes, será 100 veces más rápido que el promedio, a veces 1.000 veces, y a veces un millón de veces más rápido. Porque mientras los demás están atrapados en la telaraña de su código y para resolver un problema o añadir una característica tardan una eternidad, luchando con el código viejo para poder implementarla, el programador 100X casi no tiene que luchar con ese basurero, pues lo ha ido resolviendo a medida que ha aparecido, y en un instante puede añadir esa funcionalidad. Igual para corregir errores, el programador 100X será 100 veces más rápidos porque mantiene el código bien organizado y simple, asesinando todo atisbo de complejidad poco después de que aparezca cualquier síntoma.
Ejemplo. Una muchacha que estaba aprendiendo a programar tenía un programa en C++ que tenía un problema de compilación, y, junto con el programador 100X tardaron toda la tarde en localizar el problema. El problema era un puntero que en vez de "->" tenía un punto, y la IDE no lo identificaba correctamente y se tuvo que revisar todo el código. El programador promedio resuelve el problema y sigue trabajando. El programador 100X resuelve el problema y se inventa una manera para que no ocurra más nunca. La solución del programador 100X es "hay que ponerle un prefijo a los punteros para diferenciarlo de los objetos, digamos por ejemplo "p". Así "Televisor" es un objeto, y "pTelevisor" es un puntero. Así, el tiempo para resolver un problema como éste de los punteros se reduce de toda una tarde a cero.
La mayoría de las buenas prácticas de programación vienen de programadores 100X, casi nunca del promedio y nunca de los mediocres. ¿Por qué los nombres de las constantes se escriben en mayúsculas? Porque muchos programadores asignaban valores a las constantes (porque no las distinguían de las variables), incluso el programador 100X también lo hacía, pero el programador 100X, después de un tiempo de hacerlo, y estar fastidiado por eso, se le ocurre. Vamos a poner las constantes en mayúscula para distinguirlas de las variables y que no se pueda confundir nunca. Reduciendo así los problemas que en el pasado podían durar horas en resolver (o días), a cero segundos.
Luego, con el tiempo, los programadores promedios usan las técnicas inventadas por los programadores 100X acelerando enormemente su propio trabajo, y creen que los 100X no existen. Y nunca se dan cuenta que los programadores constantemente inventan este tipo de cosas, porque constantemente crean soluciones para matar la complejidad que les apararezca, y reducirla de horas, días y meses, a cero, y están siempre años adelantados a los demás.
#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 rendimiento incluso después de su muerte, pues sus algoritmos y sus conceptos se siguen usando después de muertos. De hecho, son programadores infinito-X (∞X).
Los programadores buenos conocen estas cosas y las usan, acelerando su trabajo millones de veces. Los promedio algunas veces las conocen y las usan, acelerando su trabajo mucho menos, y los mediocres no saben donde están parados.
O infinito. Yo he trabajado con gente que no sabe resolver un problema.
Y 100x también.
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 documentación de que significaba la combinación de cada campo era tarea imposible. Cada cual creaba tablas, o codificaba sus inserciones, como le daba la gana. Y las consultas eran churros infumables.
El rendimiento de la base de datos era risible, iba a pedales.
Un poco de coordinación y estandarización por parte de un arquitecto o departamento de arquitectura, que mantuviera un diccionario de datos, controlara los permisos, y dijera "NO" a los numerosos despropósitos, hubiera ahorrado miles y miles de horas de programación a la empresa.
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 era su día a día, pasaban semanas perfeccionando algunos códigos de poca relevancia (o que incluso borraban y hacían desde cero otra vez al cabo de los meses).
Nunca fueron capaces de entender que existen unas necesidades empresariales que estaban por encima de su ego personal, siendo al final un peso muerto para sus compañeros, que veíamos cómo desarrollaban api tras api a las que meses después les seguía faltando funcionalidad básica.
Cualquier otro programador era 100x.
#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
El programador 10x no sé si existe, el que si que existe es el /10, que produce la décima parte de lo normal
#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
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
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.
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.
Existe, en contadas ocasiones; ejemplo épico: 📼
#8 ¿Existe Novell aún?
#42 Podríamos decir que si; actualmente es una división de Micro Focus: 🔗 https://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... 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....
El que ha escrito esto no sabe que hay competiciones de programación donde puede encontrar a los mejores del mundo?
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%.
https://github.com/antirez/redis/commits/unstable
Si, se le llama experiencia y las comparaciones depende de los "otros". Ale, y ahora me voy a leer el articulo
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 pero serán casos de extremo malestar en el trabajo, ya que si algo caracteriza a un buen programador es que le gusta programar.
Programador 10x que regala una deuda técnica de 100x para sus colegas.
¿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.