Los años de experiencia no mejoran a los programadores
Abraham
Parece lógico: cuantos más años de experiencia tengas haciendo algo, mejor harás esa cosa. Sin embargo, 8 estudios diferentes realizados a lo largo de los últimos 30 años afirman lo contrario. Tener más años de experiencia desarrollando software no está correlacionado con ser un mejor desarrollador.
Estos estudios sí que muestran claramente que hay diferencias abismales en la productividad de diferentes programadores. Uno de estos estudios afirma que para desarrollar la misma funcionalidad hay esarrolladores que requieren hasta 20 veces más tiempo que otros, el tiempo para depurar esa funcionalidad puede variar de un programador a otro hasta un factor de 25, el programa resultante puede llegar a ejecutarse hasta 10 veces más rápido si ha sido escrito por un buen programador, y el programa puede tener un tamaño (en líneas de código) que varía hasta en un factor de 5.
Aunque todos los estudios concuerdan en que existen estas diferencias abismales, pudiendo decirse que es un consenso que hay programadores que llegan a ser literalmente un orden de magnitud más productivos que otros, ninguno de los estudios ha encontrado correlación entre los años de experiencia del programador y su productividad.
Por otro lado, si parece ser que hay consenso en que un programador puede llegar a ser un orden de magnitud más productivo que otro ¿No debería de cobrar también un orden de magnitud más? ¿Hay algún tipo de correlación dentro del mundo del desarrollo de software entre productividad y salario?
Las conclusiones de estos estudios desafían el sentido común e, incluso, me atrevería a decir, mi propia experiencia. Yo estoy de acuerdo en que entre la productividad de diferentes programadores hay diferencias abismales (que podrían llegar a ser de un orden de magnitud). Pero me parece increíble que uno no mejore con la experiencia, al menos si uno tiene interés y trata activamente de ser un poco mejor cada día. Yo al menos creo que sí he mejorado con los años.
¿Estás de acuerdo con los resultados de estos estudios?
Reader Comments (39)
Solo con el título ... va a arder troya...
Como todo en la vida, siempre habrá gente que mejore y gente que no lo haga ;)
Por muchas veces que repitas algo, si nadie te enseña a hacerlo mejor fallarás. La experiencia sin buena formación es un desperdicio.
Un saludo
Personalmente me resulta difícil de creer que con la experiencia no mejore la calidad del programador. Existe una teoría, las de las 10.000 horas de vuelo, que viene a decir algo así como que para que alguien sea experto en algo necesita 10.000 horas de experiencia práctica en la materia, que redondeando viene a ser como trabajar 40 horas por semana durante 5 años.
En realidad la calidad de un programador es extremadamente muy difícil de medir, es un concepto muy abstracto donde existen demasiadas variables a tener en cuenta y no creo, sinceramente, que los resultados de cualquier estudio en este tema puedan ser concluyentes.
la experiencia con seguridad mejora a todos los programadores. lo que pasa es que la experiencia te puede mejorar un porcentaje sobre tu base. cuando hablamos de programadores un orden de magnitud más eficientes que otros no hay experiencia capaz de rellenar ese gap, igual que por más partidos que yo juegue no voy a llegar a ser la mitad de bueno que Rafa Nadal. si hablamos de salarios...pues no, no existe correlación desgraciadamente
Lo he leído muy en diagonal, pero me parece que lo que dice es que no por tener muchos años de experiencia vas a ser mejor que otro. Pero no dice nada de que con los años la gente no mejore. Si que es cierto que hay gente que con los años no mejora y hasta puede empeorar, pero mi experiencia me dice que eso no es lo más normal.
Respecto la pasta, en España para que los programadores super eficientes estemos :P un orden de magnitud por encima, seguro que lo que hacen es bajar el sueldo a los menos eficientes.
Depende de a que te dediques con los años si a cubrir el minimo y calentar la silla o a esforzarte en mejorar
Es sencillo, debes cometer tus 1000 primeros errores antes de aprender bien a hacer algo. Para nada de acuerdo con el estudio. Tal vez se pueda argumentar que si no aprendes a ha cer bien algo, terminaras repitiendo una y otra vez las mismas faltas. Sin embargo, para los que amamos el desarrollo, es inconcebible seguir haciendo siempre de una misma forma las cosas, ya que siempre estamos aprendiendo e intentando mejorar. Llegara un punto limite desde el cual la experiencia no te hara mejor desarrollador, pero el haberte enfrentado a muchos problemas antes podra darte luces sobre como enfocarte y sabras los caminos que, por ejemplo, no llevan a ningun lado.
mi muy humilde opinion
En general estoy de acuerdo, lo que sucede, es que es asumir que "años de experiencia = conocimiento", es una simplificación muy fácil habitual para la búsqueda de personal, pero que no se corresponde siempre con la realidad. A veces si, a veces no.
Hay programadores (y se puede aplicar a cualquier disciplina, no tiene porqué ser informática) que pasan años y años haciendo exactamente lo mismo, sin mejorar en nada sustancialmente. Suelen ser los que buscan una situación de conformidad. Mientras otros, más "inquietos", no paran de aprender, buscan retos, y todo el tiempo están buscando nuevas formas de hacer mejor su trabajo.
Por eso, no basta con mirar años de experiencia, edad, etc., mejor hay que buscar habilidades comprobadas.
Los buenos programadores, viejos y jóvenes (y como todo en la vida) son los menos.
No se puede armar un equipo con todos Messi (o Maradona), pero qué bueno es tener a alguno de ellos en el equipo, aunque sea para llevar el ritmo y resolver con éxito lo que el promedio no puede.
@Javier J. te ha faltado añadir la autoformación, la investigación y el aprendizaje ensayo y error (y las que no se me han ocurrido). Hay muchas formas para conseguir esa mejoría con los años.
Es simplemente un tema de profesionalidad y actitud.
El desarrollo es una artesanía y esto requiere aprender con el tiempo y mucha gente simplemente no lo hace, no realimenta su conomcimiento.
También hay zapateros zoquetes y zapateros de élite.
Simplemente hay que pagarlo.
Pasa que no es lo mismo tener 10 años de experiencia que tener 1 año de experiencia 10 veces, eso lo resume todo.
Pues a mi no me extraña nada y viene a confirmar mi opinión de siempre. Un programador lo puedes "hacer", pero los buenos programadores no se hacen a base de horas, cursos ni nada. Lo que distingue a unos de otros no es algo mesurable ni se vende en tiendas. Y por supuesto, que uno tenga el potencial no quiere decir que lo aproveche, así que que no se entienda que uno nace ya con el teclado bajo el brazo.
Así que para mi, "clavao".
como "computer scientist" mi mejor momento fue 2006. Desde entonces he bajado mi nivel para hacer algoritmos complejos. Ahora, he mejorado en muchas otras áreas. Es díficil hacer un estudio concluyente con algo tan complejo
Creo que todo depende de la motivación con la que afrontes todos y cada uno de los días en los que estés desarrollando, si lo haces por hacer, el tiempo no te hará mejorar pues te conformaras con que funcione y no buscaras perfeccionar el código, en cambio si te motiva, tu mismo buscaras la manera de averiguar como podías haberlo hecho mejor, y con ayuda de compañeros ,gente experta, libros, etc, con los años tu manera de desarrollar lógicamente se vera mejorada con creces. Resumiendo, el tiempo te ayudara si tu quieres que te ayude.
Un estudio chorras mas. La gente mejora con la experiencia. Pero eso no quita para que haya un tio con 1 año de experiencia mejor que uno con 10. Como en todas las profesiones, vamos.
Creo que es algo muy subjetivo. Cuando miro el codigo que hacia hace 5 años atras, me dan ganas de tener una máquina del tiempo para viajar al pasado y golpearme a mi mismo.
La programacion tiene tanto de arte como de técnica y todo artesano mejora con el tiempo. Al fin y al cabo, el programa es una extensión del pensamiento y la experiencia da madurez... bueno, en la mayoría de los casos.
Yo creo que si algo se te da bien te gusta y viceversa. A partir de ahi, si algo te gusta tiendes a profundizar mas en el y a superarte, de otra forma solo te dedicas a cumplir.
Cuando hay competencia, aunque sea contigo mismo, es cuando se mejora. Por eso cuando ha habido guerras, ha progresado tanto la ciencia. Si no compites contra ti mismo por hacer las cosas mejor, te quedas estancado y te da lo mismo cuantos años pasen.
Mi interpretación del estudio no es que no mejoremos con el tiempo. Claro que mejoramos con el tiempo. Lo que pasa es que lo que mejoramos no es tan importante como la diferencia abismal que hay entre un buen y un mal programador. Para que todo el mundo lo entienda, comparemos con el fútbol:
* ¿Messi es mejor ahora o en su primer año en el Barça?. AHORA
* ¿Messi en su primer año en el Barça era peor que un jugador de Segunda B con muchos años de experiencia? NI DE COÑA! ¿Que uno de Segunda? TAMPOCO ¿Que uno de primera?... salvo contadas excepciones, ¡TAMPOCO!
Esto para mi tiene una lectura muy importante. Lo que desmiente, sobre todo, es la visión de la programación como una "ingeniería", cuando en mi opinión tiene mucho de ARTE.
(tampoco dice mucho bueno de lo que se aprende en nuestras empresas...)
Como todo en la vida, una cosa es experiencia y otra años de trabajo, se amprende y mejora con nuevos retos que aportan conocimiento a nuestras carreras, por el contrario si no salimos de nuestra zona de confort no importa cuantos años trabajemos no acumularemos experiencia.
Pues yo llevo unos 16 años haciendo software profesionalmente y otros pocos más de forma autodidacta y es ahora cuando últimamente estoy empezando a creer que domino algo, debe ser que algunos son unos cracks con 1 año y otros necesitamos 15 y aún así intuimos que nos queda mucho para llegar ...
A LA EXCELENCIA
:)
En mi opinión el articulo dice unas burradas tremendas de una forma sensacionalista que me parece hasta peligrosa. Eso de que "no experience is necesary..." manda narices....
Lo que ya me parece de chiste es proponer PSP/TSP, métodos basados en procesos, como solución para un problema de talento. Si como el propio articulo afirma las diferencias son de talento, es incongruente buscar la solución es un proceso. ¿La experiencia no aporta pero seguir un proceso paso a paso si?, si el problema es la ausencia de talento eso no lo arregla ni la experiencia ni los procesos,.
Sólo puedo coincidir en una cosa, la experiencia no es garantia de un buen programador. Pero sin trabajo y experiencia, salvo casos milagrosos, no hay buen programador posible.
Yo consideró al desarrollo de software mucho más cercano a la artesanía que a cualquier otra ingeniería. En este contexto se habla de lo que comentaba un compañero, las 10.000 horas, pero ojo, no son 10.000 horas de trabajo como programador, son 10.000 horas de practica deliberada. Entendiendo practica como ejercicios controlados donde el objetivo sea el aprendizaje en si mismo y no la construcción de algo. Se trata de programar con foco en la técnica y no en los resultados. Por supuesto también se aprende programando con un objetivo, pero eso no es practica deliberada y eso no es a lo que se refieren con las 10.000 horas, no confundirse.
Por otro lado, poniendome un poco filosofico, hay dos terminos japoneses que me gustán mucho:
- el kaizen, que resumiendo mucho dice que la maestria sólo se logra a través de la repetición y la mejora continua. Es decir, practicar y cuestionarse como mejorar continuamente, se puede ser talentoso, pero sin practica y autoexigencia no hay maestría posible.
- el shu-ha-ri, este me gusta mucho jeje, son los niveles de aprendizaje, siendo:
-- shu: seguir las reglas y aprender los fundamentos.
-- ha: cuestionarse y romper las reglas.
-- ri: definir las nuevas reglas.
La experiencia/tiempo es lo que te hace avanzar de una fase a otra, no se puede uno platear romper las reglas (por ejemplo saltarse alguna norma basica de OO, que se yo, la encapsulación poniendo un get mismo :P) si antes no domina completamente estas reglas. ¿Cuantos años, por muy listo que uno sea, hace falta para dominar la inmensa cantidad de reglas que tienen que dominar un programador?.
MUCHOS años hacen falta para dominar sólo lo básico, más años aún para cuestionarse lo establecido, y una vida para liberarse y definir las nuevas reglas.
Yo llevo en esto casi 14 años, no soy malo, y me faltan unos cuantos años todavía para superar el "shu" y no creo que tenga el talento necesario para llegar al "ri". Decir que la "experiencia no es necesaria" es una falta de respeto a la profesión y una tremenda idiotez, una cosa es que el ingrediente del talento sea necesario, otra muy distinta que no sea imprescindible cultivarlo.
Estoy de acuerdo en parte. El que es bueno, es bueno, y el que es un paquete, por muchos años que lleve lo seguirá siendo. Pero la experiencia es necesaria, la experiencia te enseña como no tienes que hacer determinadas cosas y cuando terminas un proyecto y empiezas otro, seguro que a muchas cosas le das otro enfoque.
8 estudios... jejeje yo llevo más de 20 años programando y cada día aprendo algo, programo mejor y además disfruto haciendolo... me presto voluntario para que me estudien... ;)
Yo opino, al igual que Legolas y Gorlok, que la formación es una parte fundamental del proceso de mejora. La experiencia consolida malas prácticas y puede llevarte a cambiar alguna de ellas hacia alguna buena práctica, pero sólo el tiempo extra dedicado a ese tan manido acrónimo I+D+i que se concreta en formación es la que acaba marcando la diferencia en la mejora de los programadores.
En las empresas la formación se relega a un enésimo plano, y al final una de dos, o te autoformas en tu tiempo libre o quedas como estás. Lamentablemente es así, las empresas no acaban de entender que la inversión en formación suele recuperarse en forma de mejores ratios de beneficio.
Nota: perdonar mi lenguaje directo y mis tacos (que en Latinoamérica no tendrán mucho valor) pero me resultan muy útiles para ser "pedagógico" :)
La verdad es que me gustaría echar un vistazo a los supuestos "estudios" porque cuando lees cosas como:
PSP can raise productivity by 21.2% and quality by 31.2%
TSP can raise productivity by 20.9% and quality by 30.9%
piensas en el principio de incertidumbre de Heinsenberg: la acción de medir cambia el resultado de lo que medimos.
¿Cómo coño podemos medir que "algo" mejora "algo" en el contexto de desarrollo software?
Vamos a ver es "pura ciencia":
El equipo A aplica el proceso X y el equipo B aplica el proceso Y, el equipo A termina antes y tiene menos errores aplicando el proceso X, luego el proceso X "mola mazo" "parte la pana" "es el mejor invento desde el pan de molde"... WTF ¡¡PERO SI EL EQUIPO ES DIFERENTE!! ¡¡¿¿NO TENDRA ALGO QUE VER??!!
Vale fijemos el equipo, el Equipo A (liderado por Hannibal) hace lo mismo primero con el proceso X y luego con el proceso Y...
Si el equipo A tarda menos y con menos defectos usando el proceso X que con el proceso Y, lo único que podemos concluir no es que el proceso X sea mejor que el Y sino que el PROCESO Y ES UNA ABSOLUTA MIERDA, porque en teoría el equipo A una vez hecho el proyecto por primera vez, la segunda vez tendría que haberse hecho al menos en significativo menor tiempo y mejor calidad da igual la metodología usada (en otras palabras "con la gorra").
Si a esto añadimos que la web del Team Software Process está lleno de links en plan "dame la pasta (=dinero) y te enseño el proceso mágico que te permite hacer el mejor software posible en el tiempo que tardas en tomar el café usando monos sin experiencia alguna", pues como para fiarse de ciertos "estudios sobradamente probados".
Yo es que cuando leo frases como "done on time" es decir "en el tiempo establecido" es que se me quitan las ganas de leer porque me empieza a oler a teletienda, y pienso ¿quién narices ha calculado ese tiempo "canónico"? ¿Dios? ¿James Gosling? porque si en obras públicas y arquitectura de casas/edificios los tiempos y los presupuestos se suelen disparar respecto a las previsiones (excluyendo la corrupción que es casi inherente a estas actividades) el dichoso software es un "poquito" más imprevisible ¿no?.
Alfredo Casado: "Se trata de programar con foco en la técnica y no en los resultados"
Yo la verdad es que no encuentro ninguna diferencia, si la técnica X no me sirve para obtener "mejores" resultados pues ¿para que?, otra cosa es experimentar diferentes enfoques con el único fin de experimentar, ahí vale :)
Respecto a la experiencia, el talento innato y similares hierbas, como decía alguien por ahí:
"si te crees el mejor es que no conoces a mucha gente",
yo añadiría:
"y llevas muy poco tiempo trabajando en ésto, demasiado poco para no avergonzarte de tu mediocre pasado y demasiado poco para no avergonzarte de lo mediocre que todavía eres".
pero como exceptuando a Alfredo Casado y yo que somos un poco conscientes de nuestra mediocridad porque los años nos lo ha enseñado, casi nadie suele ser consciente de ello porque suele cambiar pronto de profesión, o de actividad o sencillamente "le cambian", por ello muchos dejan esto sintiéndose "los putos amos" y suelen también acabar transmitiendo la idea de que "esto está chupao y lo puede hacer hasta un mono recién traído de la selva si hasta lo hacía yo" y por eso seguimos teniendo estos estúpidos debates sobre el sexo de los ángeles :)
Además de lo que menciona Jmarranz, el intentar medir los incrementos de productividad o calidad, tiene un problema adicional: el Efecto Hawthorne. Básicamente, al hacer un estudio, el equipo observado altera su conducta (generalmente a mejor) por el mero hecho de que saben que están siendo evaluados.
Por lo demás, coincido con la opinión general. La experiencia tiende a hacerte mejorar, pero no es una garantía. Tienes que ser crítico contigo mismo y preguntarte si hay una manera mejor de hacer las cosas. Si no, puedes terminar teniendo mucha experiencia en cómo hacer algo mal (y además, creyéndote que lo haces bien).
jose maría: son dos formas diferentes de aprendizaje, cuando se habla de práctica deliberada te centras tanto en la técnica que incluso cuando terminas el código que has escrito lo tiras a la basura. No es importante el resultado, es importante la técnica y el proceso. Por ejemplo las coderetreat (http://coderetreat.org/) se hacen siempre de este modo.
Cuando te centras en el resultado puedes tomar atajos, tienes (a veces) tiempos que respetar,tienes restricciones tecnologicas. Esto también es importante claro esta, pero es otra forma de aprendizaje cuando "te liberas" de estas restricciones y te centras sólo en la técnica y el proceso.
Para mi son dos formas complementarias de aprender con distintos enfoques, y las dos son importantes.
Coutemeir: Esta claro que muchas empresas no hacen nada para fomentar la formación de sus programadores. Sin embargo es muy mala idea dejar algo tan importante como tu formación y tu carrera profesional en manos de terceros, para mi, independientemente de lo que mi empresa haga o deje de hacer, es una responsabilidad individual.
Sobre estudios y tal, coincido totalmente en la poca validez que se le pueden dar a estas cosas, quizás de lo más serio que he visto en este sentido (estudios sobre productividad de programadores) sean los que realizaron, hace muchos años eso si, los autores de Peopleware (http://www.amazon.com/Peopleware-Productive-Projects-Teams-Second/dp/0932633439). Aunque quizás les doy más valor subjetivamente por que este es uno de los libros que cambio mi perspectiva sobre la profesión, un clasico!.
¿Podéis por favor, señalarme las líneas exactas de los estudios originales en los que se dice que no hay relación entre la productividad de los programadores y su experiencia?
Me he leído ya 4 y no he encontrado ni una sola mención al tema. Y la verdad es que me gustaría ver como está estructurado el estudio para ver cuanto sentido tiene.
Con lo que he leído hasta ahora sólo puedo decir que tenéis razón: No se ha encontrado ninguna relación entre la productividad y la experiencia. Entre otras cosas PORQUE NO SE HA BUSCADO
alfredocasado. Yo no entro en si es buena o mala idea dejar la formación en manos de terceros, me limito a señalar la realidad que veo a mi alrededor. Personalmente mi formación queda en mis propias manos, por cabezonería propia y por la experiencia de no haber aprendido nada en algún curso al que he asistido.
Coutemeier (leñe que difícil de escribir tu nombre jeje): Si estoy de acuerdo contigo, esta claro que muchas empresas no tienen esa cultura y no hacen nada por formar a sus empleados. Al igual que tu yo tengo claro que mi formación esta en mis manos.
Sin embargo, yo si entro a valorar si es buena o mala idea dejar tu formación en manos de terceros, es una idea horrible, el que lo haga, y perdona si pensabas que me referia a ti que no era la intención sino reflejar también la realidad de lo que veo, que se atenga a las consecuencias que supone dejar tu vida profesional en manos de otros. Estoy aburrido de ver gente llorando por aquello de "la empresa no me da formación" que no son capaces de asumir su responsabilidad en cuanto a su formación, y reitero, no va por nadie de este post sino en general por nuestro sector donde veo muchas criticas hacia otros (las empresas, el gobierno, el mundo en mi contra...) y muy poquita autocritica.
Nosotros intentamos en mi empresa hacer cosas para la mejora continua, como por ejemplo promover la asistencia a charlas/eventos, reuniones semanales de revisión de código colectivo (con sonar y proyector), charlas internas donde alguien se prepara un tema y lo explica al resto, a ver si conseguimos reservar un tiempo de forma periodica para hacer algún "hack day" donde cada cual haga lo que le de la gana enfocado a mejorar nuestro producto etc,etc. Pero aún así, por mucho que hagamos por fomentar esto, la responsabilidad sigue siendo individual, cada cual tiene que tener su propia iniciativa y su propio camino para mejorar como profesional. Una empresa que ponga los medio y cree la cultura adecuada ayuda, pero la necesidad nace de uno mismo no se puede imponer desde fuera. Es esto de la motivación intrinseca frente a la extrinseca, en nuestra profesión, el que no tiene su propia motivación esta jodido y condenado a ser un mediocre.
Si un desarrollador no mejora con la experiencia puede deberse a dos cosas:
- una : que es un zote
- dos : que es un zote
Esto es la vida misma. extrapolemos......
A mi para lo que mas me ha servido la experiencia, mas que para escribir mas lineas de codigo por hora, es para escribir codigo mas limpio, elegante, testeable, desacoplado, mantenible y casi sin bugs. Esto es muy dificil de medir, y para mi es mucho mas importante que aprender a usar 50 frameworks o escribir codigo rapido. Productivo no es aquel que termina antes, es aquel que lo hace mejor (dentro de un limite obviamente)
Y si, cuanto mas aprendo, mas me doy cuenta que me queda muchisimo todavia...
Respecto al artículo, creo que solo es aplicable a un tipo de profesional.
Yo, en todo tipo de profesión distingo a dos tipos de profesionales:
1) Por oficio
2) Por devoción
Los primeros hacen su trabajo, y punto, la calidad/productividad/eficiencia/belleza de lo que hacen se rigen por los parámetros del mínimo esfuerzo, y eso hay que esperar. No mejoran con el tiempo, incluso pueden empeorar por el hastío que provoca hacer siempre lo mismo. No solo los informáticos adolecen de contar con este tipo de profesionales, mecánicos, cocineros, camareros, albañiles, abogados, jueces, administrativos, pintores... Las consecuencias pueden llegar a ser desastrosas....
Los segundos son otro cantar, son aquellos a los que les gusta lo que hacen, que eligieron algo que siempre les ha gustado/interesado/motivado y siempre buscan meter la mano de una manera u otra en otras variantes de su oficio, y que incluso buscan como interoperar diferentes técnicas para ver que xxxx sale de la mezcla, como si de alquimistas se tratara. Muchas veces esa 'alquimia' se refleja en soluciones que algunos considerarían audaces o arriesgadas, aunque el que las ha confeccionado las vea como la consecuencia o evolución lógica de lo que hace.
Aún así, si el trabajo es lo suficientemente malo, o está lo suficientemente mal retribuido, un 'profesional por devoción' puede acabar como un 'profesional por oficio', esto lo he visto en muchas ocasiones, lo que nunca he visto es el paso contrario.
Como decía al principio, el artículo solo lo veo aplicable a un tipo de profesional, el de 'por oficio', el de 'por devoción' mejora día a día, y siente dentro de el un cosquilleo cada vez que una de 'sus trastadas' no solo funciona, si no que lo hace mucho mejor de lo que habría considerado posible.
No es lo mismo 20 años de experiencia que 1 año repetido 20 veces.
La verdad es que yo he visto ambos casos, y pareciera que la mayoría son del primer tipo (como dice wurlde "por oficio"). Y en línea con los estudios, parece que sólo se mejora cuando hay ganas de mejorar, y el entorno te lo permite, es decir, si el "jefe" o los "compañeros" no te ayudan, es dificil que puedas mejoras e inclusive que te interese mejorar.
Oscar: "Esto es muy dificil de medir, y para mi es mucho mas importante que aprender a usar 50 frameworks o escribir codigo rapido. Productivo no es aquel que termina antes, es aquel que lo hace mejor (dentro de un limite obviamente)"
Oscar me temo que la "industria" por mucho agilismo y por mucho craftmanship está MUY lejos de entender esto, la "industria" te va a evaluar por tus "conocimientos", por el número de APIs que hayas llamado, pero casi nunca por tus "habilidades"... Yo personalmente prefiero a un GRAN artesano del código que a un pica-frameworks, pero la realidad que dicta el "mercado" es otra.
En fin, muy triste.
jmarranz: "pero la realidad que dicta el "mercado" es otra"
Yo anadiria espaniol, detras de mercado ;) Como dices, una pena.
en una entrevista observas el gesto que dice "no tiene experiencia en x", como le explicas que si me das un ratito te hago un x de esos?