Portada
mis comunidades
otras secciones
#16:
#10 Las "code review" son una de tantas cosas que surgen como un buen propósito, una promesa de algo mejor, pero al final se convierten en algo totalmente opuesto a lo prometido.
Resumen pensado para profanos en la programación. Hace ya bastantes años que el código de los proyectos no se guarda en los ordenadores. Un estropicio, y adiós proyecto. Por eso el código se sube a repositorios, ya sean en un servidor privado de la empresa, o uno externo. En cualquier caso, fuera de los ordenadores individuales de los programadores.
Al picar, se tiene (o debería tenerse) una rama principal, y N secundarias donde cada programador va subiendosus mierdas sus desarrollos. Cuando considera que ya está su tarea, añadido, arreglo, o lo que sea, terminado y preparado, cursa una petición para integrar sus cambios en la rama principal.
Ahí entran en escena las revisiones, miran los cambios los compañeros y el "jefe" del equipo, el (supuestamente) programador más experimentado. Y lo que tendría que ser una revisión entre pares para cubrir gazapos (cuando llevas muchas horas con el mismo código uno empieza a poner el piloto automático y dejar de fijarse), e incluso aprender unos de otros, se convierte en una guerra de egos y un concurso de a ver quién mea más lejos.
¿Suficiente o me extiendo más?
Resumen pensado para profanos en la programación. Hace ya bastantes años que el código de los proyectos no se guarda en los ordenadores. Un estropicio, y adiós proyecto. Por eso el código se sube a repositorios, ya sean en un servidor privado de la empresa, o uno externo. En cualquier caso, fuera de los ordenadores individuales de los programadores.
Al picar, se tiene (o debería tenerse) una rama principal, y N secundarias donde cada programador va subiendo
Ahí entran en escena las revisiones, miran los cambios los compañeros y el "jefe" del equipo, el (supuestamente) programador más experimentado. Y lo que tendría que ser una revisión entre pares para cubrir gazapos (cuando llevas muchas horas con el mismo código uno empieza a poner el piloto automático y dejar de fijarse), e incluso aprender unos de otros, se convierte en una guerra de egos y un concurso de a ver quién mea más lejos.
¿Suficiente o me extiendo más?
#36:
#16 Llevo ya varios años en los que reviso y revisan mi código, y francamente no ha habido un simple roce. Cuando se te escapa algo y te lo indican sen dan las gracias y cuando encuentras algo revisando te las dan. He aprendido mucho tanto revisando código como a través de los comentarios en las revisiones, quiero pensar que también algo bueno he transmitido.
Como parte de las revisiones también incluimos a la gente de QA, que se les da bastante bien encontrar bugs y dar el visto bueno en cuando al funcionamiento de la PR.
No me iría a ningua empresa en la que no haya revisión de código...
cc #21 #22 #24
Como parte de las revisiones también incluimos a la gente de QA, que se les da bastante bien encontrar bugs y dar el visto bueno en cuando al funcionamiento de la PR.
No me iría a ningua empresa en la que no haya revisión de código...
cc #21 #22 #24
#2:
El alterego del admin menéame sin vida. Pero sabiendo hacer algo.
#7:
Tengo un compañero que metieron enchufado completamente inútil, siempre tomando la peor decisión posible y convirtiendo lo fácil en dificil. Por su ineptitud yo acabo haciendo su trabajo además del mío.
Esos parásitos no me dan ninguna pena.
Esos parásitos no me dan ninguna pena.
#37:
#28 Eso también. La programación no es (o no debería ser) aguantar jurados con Risto como presidente. Entre otras cosas porque como comenta el articulista, uno se acaba convirtiendo en otro amargado como los del "jurado".
La programación a menudo se convierte en la carrera de las ratas. Incluso sacrificando tu vida personal, que ya hay que tenerlos cuadrados para eso, ni así dominarás los N frameworks que salen cada poco tiempo. Tanta información en la cabeza, además de que a menudo incluye ruido, acaba siendo contraproducente y distrayendo de lo que realmente es importante. Tu puta vida para empezar.
Hay un detalle que puede distinguir al que de verdad está curtido en mil fregados de los demás: a tomar por culo el hype. La mayoría de cosas que salen nuevas, pasadas un año o dos están en el cubo de la basura. En diez años uno ya ha tenido que ver fiascos de todos los colores. Al final uno acaba diciendo "me quedo con los cuatro principios que han demostrado ser ciertos todo este tiempo, y todo lo demás, o tiene un propósito y me resuelve problemas en vez de crearlos, o se va al cubo de la basura".
La programación a menudo se convierte en la carrera de las ratas. Incluso sacrificando tu vida personal, que ya hay que tenerlos cuadrados para eso, ni así dominarás los N frameworks que salen cada poco tiempo. Tanta información en la cabeza, además de que a menudo incluye ruido, acaba siendo contraproducente y distrayendo de lo que realmente es importante. Tu puta vida para empezar.
Hay un detalle que puede distinguir al que de verdad está curtido en mil fregados de los demás: a tomar por culo el hype. La mayoría de cosas que salen nuevas, pasadas un año o dos están en el cubo de la basura. En diez años uno ya ha tenido que ver fiascos de todos los colores. Al final uno acaba diciendo "me quedo con los cuatro principios que han demostrado ser ciertos todo este tiempo, y todo lo demás, o tiene un propósito y me resuelve problemas en vez de crearlos, o se va al cubo de la basura".
#19:
Hay que tener mucho tacto y cuidado con las code reviews:
- Lo que un desarrollador hace se pone en público a los demás, como una intervención quirúrgica decimonónica en color sepia donde se metían tajazos a un cuerpo enfrente de un montón de sabiondos mirándote con monóculo.
- Cualquier cosa que se diga por escrito suena en nuestras cabezas de forma bastante antipática. La introducción de los emoticonos y emojis no es sino un síntoma de ésto, a la vez que un intento de medicina.
- Cada persona es un mundo. Hay gente que comenta sin pensar mal de la otra persona. Otros se indignan por no alcanzar un estándar que tienen en mente. Otros, simplemente, aprovechan para aliviar su inseguridad personal mostrándose como una supermente mientras es implacable. Y así, miles de casos.
Al final, hay que meter mucho énfasis en la personalidad de la gente en las entrevistas de trabajo, y esto es casi o más importante que lo técnico, pues partiendo de una base todo se puede aprender, pero la personalidad no se amolda tan facilmente.
Prefiero en mi equipo a gente mediocre con ganas de aprender, pero buenas personas, que genios incapaces de relacionarse con los demás y que, de seguro, amargan el día a cualquiera.
Aunque claro, mejor genios buenas personas, puestos a pedir .
- Lo que un desarrollador hace se pone en público a los demás, como una intervención quirúrgica decimonónica en color sepia donde se metían tajazos a un cuerpo enfrente de un montón de sabiondos mirándote con monóculo.
- Cualquier cosa que se diga por escrito suena en nuestras cabezas de forma bastante antipática. La introducción de los emoticonos y emojis no es sino un síntoma de ésto, a la vez que un intento de medicina.
- Cada persona es un mundo. Hay gente que comenta sin pensar mal de la otra persona. Otros se indignan por no alcanzar un estándar que tienen en mente. Otros, simplemente, aprovechan para aliviar su inseguridad personal mostrándose como una supermente mientras es implacable. Y así, miles de casos.
Al final, hay que meter mucho énfasis en la personalidad de la gente en las entrevistas de trabajo, y esto es casi o más importante que lo técnico, pues partiendo de una base todo se puede aprender, pero la personalidad no se amolda tan facilmente.
Prefiero en mi equipo a gente mediocre con ganas de aprender, pero buenas personas, que genios incapaces de relacionarse con los demás y que, de seguro, amargan el día a cualquiera.
Aunque claro, mejor genios buenas personas, puestos a pedir .
#28:
#c-21" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/21">#21 Trabajó duramente para ser el mejor tras sufrir comentarios en comunidades de gente más experimentada que odiaba y, tras conseguirlo, se ha convertido en esa gente a la que odiaba.
Hay un párrafo bastante representativo que dice algo así como : "Mientras yo pasaba mis noches aprendiendo F#, mi hija empezaba a llamar a todo el mundo alrededor "papá" y este tío (al que despidieron), en vez de hacerse mejor en su trabajo, iba a casa con sus hijos, y yo quería castigarlo por ello".
Hay un párrafo bastante representativo que dice algo así como : "Mientras yo pasaba mis noches aprendiendo F#, mi hija empezaba a llamar a todo el mundo alrededor "papá" y este tío (al que despidieron), en vez de hacerse mejor en su trabajo, iba a casa con sus hijos, y yo quería castigarlo por ello".
#24:
#21 Una leche en los mundos de Yupi. Hay una minoría ridícula de sitios donde las revisiones por pares se intentan hacer bien y con criterio. El resto del mundo se divide en control cero y subir el zurullo como dices, que mientras que no reviente nadie lo va a mirar, y una guerra de egos, una microgestión, un "te abronco por no indentar bien el código" o cualquier trivialidad, mientras el supuesto "lead developer" se deja llevar por el hype mientras comete errores básicos.
#4:
Corrigiendo un par de palabras y voila, les entrego la descripcion de internet (o el mundo moderno, o meneame);
Finally, I became the exact thing I hated: a toxic asshat throwing his skills around like fists. I don’tdo code review for the business, I just like showing the rookies others their place. This behaviour begets a vicious cycle that produces not professionals humans, but toxic asshats.
My personality today isn’t my disease. It’s a disease of the industry internet. Our mentality is predicated on the cult of power and superiority. And that’s what we need to fix: just stop being that.
Finally, I became the exact thing I hated: a toxic asshat throwing his skills around like fists. I don’t
My personality today isn’t my disease. It’s a disease of the
Comentarios
#10 Las "code review" son una de tantas cosas que surgen como un buen propósito, una promesa de algo mejor, pero al final se convierten en algo totalmente opuesto a lo prometido.
Resumen pensado para profanos en la programación. Hace ya bastantes años que el código de los proyectos no se guarda en los ordenadores. Un estropicio, y adiós proyecto. Por eso el código se sube a repositorios, ya sean en un servidor privado de la empresa, o uno externo. En cualquier caso, fuera de los ordenadores individuales de los programadores.
Al picar, se tiene (o debería tenerse) una rama principal, y N secundarias donde cada programador va subiendo
sus mierdassus desarrollos. Cuando considera que ya está su tarea, añadido, arreglo, o lo que sea, terminado y preparado, cursa una petición para integrar sus cambios en la rama principal.Ahí entran en escena las revisiones, miran los cambios los compañeros y el "jefe" del equipo, el (supuestamente) programador más experimentado. Y lo que tendría que ser una revisión entre pares para cubrir gazapos (cuando llevas muchas horas con el mismo código uno empieza a poner el piloto automático y dejar de fijarse), e incluso aprender unos de otros, se convierte en una guerra de egos y un concurso de a ver quién mea más lejos.
¿Suficiente o me extiendo más?
El alterego del admin menéame sin vida. Pero sabiendo hacer algo.
Tengo un compañero que metieron enchufado completamente inútil, siempre tomando la peor decisión posible y convirtiendo lo fácil en dificil. Por su ineptitud yo acabo haciendo su trabajo además del mío.
Esos parásitos no me dan ninguna pena.
#16 Llevo ya varios años en los que reviso y revisan mi código, y francamente no ha habido un simple roce. Cuando se te escapa algo y te lo indican sen dan las gracias y cuando encuentras algo revisando te las dan. He aprendido mucho tanto revisando código como a través de los comentarios en las revisiones, quiero pensar que también algo bueno he transmitido.
Como parte de las revisiones también incluimos a la gente de QA, que se les da bastante bien encontrar bugs y dar el visto bueno en cuando al funcionamiento de la PR.
No me iría a ningua empresa en la que no haya revisión de código...
cc #21 #22 #24
#5 pero el sonar no te dice si hay algo mal o si se puede hacer mejor, simplemente que este bien escrito y que cumpla unos estándares.
#8 Hay muchos motivos por lo que una persona puede no hacer bien su trabajo, y no todos son responsabilidad del afectado.
#10 Que el que revisa el código se ha dado cuenta que es un capullo y un amargado y que lo siente.
Hay que tener mucho tacto y cuidado con las code reviews:
- Lo que un desarrollador hace se pone en público a los demás, como una intervención quirúrgica decimonónica en color sepia donde se metían tajazos a un cuerpo enfrente de un montón de sabiondos mirándote con monóculo.
- Cualquier cosa que se diga por escrito suena en nuestras cabezas de forma bastante antipática. La introducción de los emoticonos y emojis no es sino un síntoma de ésto, a la vez que un intento de medicina.
- Cada persona es un mundo. Hay gente que comenta sin pensar mal de la otra persona. Otros se indignan por no alcanzar un estándar que tienen en mente. Otros, simplemente, aprovechan para aliviar su inseguridad personal mostrándose como una supermente mientras es implacable. Y así, miles de casos.
Al final, hay que meter mucho énfasis en la personalidad de la gente en las entrevistas de trabajo, y esto es casi o más importante que lo técnico, pues partiendo de una base todo se puede aprender, pero la personalidad no se amolda tan facilmente.
Prefiero en mi equipo a gente mediocre con ganas de aprender, pero buenas personas, que genios incapaces de relacionarse con los demás y que, de seguro, amargan el día a cualquiera.
Aunque claro, mejor genios buenas personas, puestos a pedir .
#c-21" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3085323/order/21">#21 Trabajó duramente para ser el mejor tras sufrir comentarios en comunidades de gente más experimentada que odiaba y, tras conseguirlo, se ha convertido en esa gente a la que odiaba.
Hay un párrafo bastante representativo que dice algo así como : "Mientras yo pasaba mis noches aprendiendo F#, mi hija empezaba a llamar a todo el mundo alrededor "papá" y este tío (al que despidieron), en vez de hacerse mejor en su trabajo, iba a casa con sus hijos, y yo quería castigarlo por ello".
#28 Eso también. La programación no es (o no debería ser) aguantar jurados con Risto como presidente. Entre otras cosas porque como comenta el articulista, uno se acaba convirtiendo en otro amargado como los del "jurado".
La programación a menudo se convierte en la carrera de las ratas. Incluso sacrificando tu vida personal, que ya hay que tenerlos cuadrados para eso, ni así dominarás los N frameworks que salen cada poco tiempo. Tanta información en la cabeza, además de que a menudo incluye ruido, acaba siendo contraproducente y distrayendo de lo que realmente es importante. Tu puta vida para empezar.
Hay un detalle que puede distinguir al que de verdad está curtido en mil fregados de los demás: a tomar por culo el hype. La mayoría de cosas que salen nuevas, pasadas un año o dos están en el cubo de la basura. En diez años uno ya ha tenido que ver fiascos de todos los colores. Al final uno acaba diciendo "me quedo con los cuatro principios que han demostrado ser ciertos todo este tiempo, y todo lo demás, o tiene un propósito y me resuelve problemas en vez de crearlos, o se va al cubo de la basura".
Corrigiendo un par de palabras y voila, les entrego la descripcion de internet (o el mundo moderno, o meneame);
Finally, I became the exact thing I hated: a toxic asshat throwing his skills around like fists. I don’t
do codereview for the business, I just like showingthe rookiesothers their place. This behaviour begets a vicious cycle that produces notprofessionalshumans, but toxic asshats.My personality today isn’t my disease. It’s a disease of the
industryinternet. Our mentality is predicated on the cult of power and superiority. And that’s what we need to fix: just stop being that.#16 se convierte en una guerra de egos y un concurso de a ver quién mea más lejos
Efectivamente.
Y lo peor es cuando el que supuestamente es jefe de equipo es un capullo con menos experiencia que algunos de los desarrolladores y acaba imponiendo su mierda
#71 Pensaba que lo decías sarcásticamente.
El cliente ve el resultado final, pero cuando el cliente te dice que el resultado final ya no es suficiente, ya sea porque falla o porque quiere ampliar, te encuentras con que el programador que hizo todo por su cuenta y sin seguir estándares ha programado algo donde cada vez que tocas algo te cargas otra cosa.
En el ejemplo del albañil, sería que el cliente necesita una bodega pero cada vez que tocas el suelo tiemblan los cimientos. El resultado final anterior tal vez se cumplió, pero el nuevo es imposible de cumplir si no derribas la casa.
El Risto Mejide de los bits.
#21 Una leche en los mundos de Yupi. Hay una minoría ridícula de sitios donde las revisiones por pares se intentan hacer bien y con criterio. El resto del mundo se divide en control cero y subir el zurullo como dices, que mientras que no reviente nadie lo va a mirar, y una guerra de egos, una microgestión, un "te abronco por no indentar bien el código" o cualquier trivialidad, mientras el supuesto "lead developer" se deja llevar por el hype mientras comete errores básicos.
#7 Exacto! Todas las multinacionales Españolas necesitan un tio como este.
#23 "..escribirlos de forma que el programador nunca se sienta atacado.."
Linus Torvalds Seal of Approval!
#65 No veo ninguna incoherencia en #41
La code review se hace en parte para garantizar la calidad del código y en parte para que todo el equipo, o mejor dicho todos los equipos, programen de una determinada forma, consiguiendo que todo el código sea lo suficientemente homogeneo para que cualquiera pueda coger cualquier parte del código y entenderlo rápidamente. El objetivo es colaborativo, el equipo se ayuda a mejorar el código. Si haces comentarios destructivos, las code reviews se van a convertir en una batalla a ver quien es mejor y a ver quien puede imponer sus criterios, y al final va a ocurrir que estas guerras bloqueen el proceso productivo o incluso que "los perdedores" de la batalla dejen de contribuir y se limiten a hacer lo justo, porque saben que todo lo que hagan de más va a pasar por alguien que va a hacer lo posible para dejarles en mal lugar y todos los errores van a ser pagados.
En Internet no le estás enseñando nada a alguien a quien no conoces, realizas tu crítica y te da igual que esta persona aprenda o no.
#43 Me lo he leido entero, y el final todavía me parece peor. Dice que, antes que hacer comentarios destructivos, prefiere no decir casi nada. Eso es cargarse el proceso de code review, para eso mejor que quiten el proceso por completo.
A poco que te llegue suficiente oxígeno a la azotea en un par de meses de formación en la empresa y con algo básico de conocimientos puedes tirar millas en un 90% de las empresas que gastamos por estos lares.
#14 Le he dado crédito hasta que ha dicho que sus comentarios son pasivos agresivos.
Lo primero que te dicen cuando aprendes a hacer revisiones de código es que tus comentarios han de ser constructivos y has de escribirlos de forma que el programador nunca se sienta atacado. Si reconoce que sus comentarios no estaban a la altura, tal vez el problema no sea que el novato no sabe escribir código, sino que el revisor no sabe rectificarlo y explicar el problema de forma que el novato aprenda.
He visto por ahi gente que dice que es exagerado. Pues yo he vivido esa situación, de llegar a una empresa tan feliz conmigo mismo y salir de ella sin autoestima. Y no porque fuese malo, cualquiera del gremio sabe que hay varias formas de hacer una misma cosa. Pero por ahi hay muuuucho hijo de la grandisima puta que solo quiere quedar por encima a cualquier precio, aunque este diciendo barbaridades. Me costo entender porque si se suponia que era tan malo, la compañia no queria dejarme marchar.
Por si alguno me lee, aun me acuerdo de vosotros y ya ajustaremos cuentas.
Bueno, el artículo es una muestra de cómo no es el proceso de Code Review.
- El proceso de Code Review no es una muestra de superioridad técnica, que es lo que sugiere el autor
- El proceso de Code Review no es una evaluación de la competencia del revisado, que es lo que sugiere el autor
- El proceso de Code Review no es una batalla contra el developer
Lo que saco en claro del artículo es que el autor tiene un ego que no le cabe en el cuerpo, y una carencia del conocimiento de qué es un code review, y carencia de empatía. Tras revisar su github, puedo confirmar que también tiene carencias en lo técnico. Así que es alguien que ha escrito un artículo aprovechando la libertad que hay de publicar cualquier cosa, y aquí se le ha meneado.
En mi empresa cada PR debe ser aprobada por dos personas mediante Code Review. Esas dos personas pueden ser o no de su equipo. Esas dos personas pueden ser o no mejores técnicamente que el que ha subido el código. Y sobre todo, nadie está exento de ello, ni siquiera el mejor, si es que existe. En los proyectos Open Source, este proceso de Code Review es más global y hay más ojos, por ejemplo para que te acepten una PR en Node que toca el core, os aseguro que fácil fácil no es
La finalidad del Code Review es:
1. Que más personas comprendan los cambios que se están realizando y por qué
2. Que más personas puedan ver los cambios y entender el impacto
3. Que los que revisan puedan identificar posibles mejoras o cambios, con lo cual el revisado aprende
4. O incluso al revés, que el revisado esté subiendo algo con patrones o técnicas que los revisores no conocían, y así las aprenden
5. Cuestionar siempre el código, al menos un chequeo, incluso planteando cuestiones para verificar que es suficientemente bueno
6. Chequear que se cumplen ciertas prácticas o normas no revisadas por los pre-commits o el CI.
Así que, lo siento, pero como artículo solamente me parece un ejemplo de lo que no se debe hacer y de cómo no debe ser el comportamiento de un programador.
#8 ya lo de ayudarles y dejarles que aprendan... qué mierda de futuro nos espera con gente con esas ideas.
Yo soy revisor de código, entre otras funciones, donde trabajo. El autor del artículo es un poco exagerado y dramático, o tal vez yo tenga la suerte de estar en un equipo con buena empatía.
#8 Eso, que enseñar a la gente a trabajar mejor y hacer críticas constructivas es rebajarse.
El principal problema que le veo al code review es que puede ser un sistema muy perverso y para los empleados puede ser una losa bestial en el plano psicológico.
No deja de ser un proceso en el que se cuestiona día a día todo el trabajo que realizas, lo hacen tus compañeros que no dejan de ser tus competidores por un puesto de trabajo y encima se supone cierto nivel que puede que no tengas porque el límite pueda ser demasiado alto en lineas generales (aquí entraría el famoso talento y la exigencia irreal de este sector).
Es algo que pasa inadvertido porque se da en el mundo IT, que no dejan de ser "técnicos", y en el que generalmente se pisotean bastante los derechos laborales por la gloria de la tecnología y de los egos. Siempre me ha parecido un sector en el que "como trabajas con máquinas aceptas que te traten como una máquina y no como una persona".
De ser algo que se hubiera implantado en otra rama como la medicina, no dudo en que estaría hasta regulado por ley. A ver qué médico tolera profesionalmente que cada diagnóstico y cada prueba solicitada a sus pacientes fuese revisada, evaluada y corregida por otro grupo de médicos... Para el paciente sería bueno, pero el desgaste psicológico me parece altísimo para el médico y la probabilidad de que se sienta atacado inmensa.
Evidentemente esto no es la norma general ni mucho menos, y hay muchas empresas que lo llevan muy bien y hay mucha gente top muy respetuosa con los compañeros y que se preocupan por su desempeño, pero es muy susceptible a los cretinos. Y cuando dejas en una habitación a un abusón con dos pringados, generalmente el abusón acaba dándoles collejas a los pringados.
Así como el pair programming me parece excelente, el code review todo lo contrario...
#7 No solo que no dan ninguna pena, sino qué hay que organizarse para sacarlos del equipo de turno.
Cero respeto para aquellos que no hacen su trabajo y terminan perjudicando al resto.
Para gozo mio, su trabajo lo hace Sonar últimamente y él es el siguiente en ser despedido.
#7 Rémoras laborales, parásitos infectos que cuando te tocan como "compañero de trabajo", te hacen trabajar el doble. Incompetentes hijos de la gran puta que habría que eliminar de la faz laboral.
Hace unos años me tocó sufrir unos cuantos, alguno de ellos manager, pues hace un par de meses, parado con mi coche en un paso de cebra lo vi pasar delante mio, iba con una gorda arrastrando un carrito de bebé y su triste vida por la tierra. Su cara era la de un funeral.
A mi si que me dio pena, pena que fueran las 3 de la tarde en el centro de barcelona y la calle estuviera llena.
Lo que te vengo a decir con esto, es que no te ralles, que tarde o temprano a todos esos cerdos les llega su san martin y entonces, solo hay que sentarse y disfrutar de su agonía.
Programadores e informaticos con graves trastornos del autoestima y rasgos sociopaticos claros.
Pues lo de siempre vaya.
#15 Yo he tenido compañeros así, que entraban sin tener ni zorra, pero por lo general no duraban mucho, y menos un año y medio. Y también he tenido compañeros por los que de entrada no daba un duro por los mismos motivos, pero que en muy poco tiempo demostraron ser unos cerebros y/o aprendieron nuevas tecnologías a velocidades asombrosas. Incluso he tenido becarios en el departamento que me dejaron con la boca abierta, como uno que "parecía" ser más de pueblo que las amapolas y no tenía ni zorra de software, pero como decía tener algo de experiencia en hardware, el primer día le dimos una montaña de 15 portátiles desahuciados por los técnicos de la empresa. Nunca olvidaré entrar al taller, ver todas las piezas de los portátiles tiradas por la mesa, y pensar que menos mal que estaban para tirar porque no iba a ser capaz ni de volver a montarlos. Pues al final del día nos enseñó los equipos arrancados y funcionando y nos tuvimos que quitar el sombrero con él. Hizo andar 10-11 de ellos intercambiando piezas (eran del mismo modelo) montados perfectamente. Estas y otras experiencias me han llevado a dar primero una oportunidad a la gente que empieza (hablo de puestos "junior"). Otra cosa es cuando pides a alguien con experiencia y te viene un zote, que no debería de entrar nunca a plantilla porque buscas rendimiento "para ya".
No big deal if the code’s not good, I can fix it myself it I need to.
Para correrle a collejas.
Si el código es una puta mierda y no sigue buenas prácticas, me veo en la obligación moral de anotarlo. Que luego decida el technical lead si la calidad es buena o no y lo apruebe él.
Si mis senior en su día no hubiesen hecho conmigo, no hubiese aprendido absolutamente nada. Otra cosa es que las code review tenga borderías, gracietas o sarcasmos, eso sobra siempre.
En cuanto a esto:
I’m a better developer, therefore I’m right.
No. No tienes razón cuando eres mejor. Tienes razón cuando apuntas a malas prácticas o inconsistencias y eres capaz de argumentar o aportar enlaces que corroboran lo que dices. Mi technical lead me barre como desarrollador y en casi cualquier code review le hago comentarios de cosas que creo que no están bien.
#21 Yo no se como es en otros lugares, pero donde curro yo (departamento de proyectos y tecnologia de una petrolera holandesa) todos los pull-request necesitan como mínimo dos revisores (normalmente uno es el compañero, y el otro es el jefe). Y como pongas mierda, a la segunda que ocurra ya te vendrán a preguntar si necesitas un curso de diseño de software, o de programación, o qué... y, sinó, largo.
#14 Supongo que la gente normal hace las reviews, indica los fallos y cómo mejorarlos para que el que lo escribió mejore... los tarados como el del artículo indica los fallos con comentarios hirientes para que larguen al programador en cuestión soltando un "eres mierda yo soy mejor que tu"
#24 La mayoría de esas revisiones se convierten en un "como no entiendo tu codigo o tu forma de trabajar quiero que reescribas el código a cómo yo lo haría"
Revisar código es como mirar una obra. El trabajo de los milenials como nosotros cuando nos jubilemos.
Es muy duro hasta que ves que es desarrollador de .net
No se como hará este hombre las revisiones de código pero a mi nunca me ha dicho nadie que le haya "dolido" una revisión mia.
Me parece exageradísimo lo que cuenta.
Tambien suele ser una buena practica que gente con poca experiencia revise código escrito por gente con mucha experiencia para que aprendan viendo ejemplos de código bueno.
#60 será divertido, porque entonces la gente que se comporta como seres superiores, como alguno que ha escrito aquí, se encontrará con una revisión fría de su trabajo y sin remordimientos. Igual que harían ellos, pero sin tener la excusa de ser una máquina. Y tendrán que hacer su trabajo de una forma rígida, sin aprender ni aportar.
#140 no la necesito.
Pero gracias por preocuparte por mí. Es un detalle que pierdas tanto tiempo.
Besis.
Leyendo los comentarios, es como si nadie se hubiese leido el articulo hasta el final, y se hubieran quedado en el titular, o como mucho en la entradilla.
Pero esto es meneame, no es posible verdad?
#97 nombre de la consultoria? Lo de que no controlan ni horas, ni vacaciones...
#6 Efectivamente. Y además, se pasa el día pitando: Piiiii. Piiiii. Piiiii.... Y así.
ANTIPATTERNS
#48 Te ha faltado acabar como David Broncano, con un "os rajo cabrones!"
#41 Resulta curioso que critiques la actitud del autor del articulo (y razon no te falta por lo poco que entiendo) y luego tengas la misma actitud en #56 tratando de humillar a otro usuario con tu superioridad tecnica
#39 #51 que aprendan en su tiempo libre. Otra cosa es que sean tus subordinados, pero a igualdad de escalafón que asuman sus fallos.
#60 a ver si llega ya.
#77 no señor, si la empresa los contrató sabiendo su nivel es responsabilidad de la empresa el formarlos. No es culpa de ellos si la empresa rehuye de su responsabilidad.
#8 Es que si ha pasado de 200 comentarios a 2, en un código de 1000 lineas... igual el tipo sí estaba haciendo bien su trabajo, y el que era un tocahuevos era el revisor ;-).
#16 Vives en un entorno muy tóxico. Cambia de empresa.
Es un poco exagerado.
Alguien me hace un resumen?
#68 Es que ser un "C-Level" no es la panacea. O estás dentro del círculo de amiguetes del jefazo (y los inversores), o casi es mejor volar debajo del radar y ser un currito. Los que quedan entre Pinto y Valdemoro están sometidos a un estrés brutal, tienen que pisar cabezas en parte por su propia supervivencia. Y si la cagan, pues más de uno acaba avergonzado en el "Hall of Shame" de forma pública antes de recoger sus tiestos.
Por eso me da la risa floja cuando veo a un payaso jefe-wannabee de éstos intentando trepar y comer más de lo que pueden cagar. Me descojonaría abiertamente de ellos si no fuese porque cuando caen, suele descubrirse el reguero de cadáveres que han dejado.
#121 Yo en su día ya cambié de empresa. No sufras por mí.
Y tampoco me quejo tanto de haber estado en empresas malas. Como diría Groucho, sirven de mal ejemplo. Incluso te diría que hoy día me son útiles. Retienen dentro a "elementos" con los que no me gustaría trabajar.
Sitios así son útiles un año o dos cuando tienes poca experiencia y tienes que curtirte. Especialmente para aprender lo que no se debe hacer. Cuando uno ya está rodado, no aguanta mucho tiempo en sitios así. Como diría el dicho manido, si estás a gusto en un mal sitio, tú no estás bien. Pasados los años ahí quedan los cobardes que no son capaces de probar otra cosa, los que ya tienen la actitud sectaria grabada a fuego, etc. Por supuesto, también el círculo de amiguetes del jefe, pero eso pasa en todas partes.
Su trabajo es revisar el trabajo de otros y sacar defectos, nunca es agradable que critiquen tu trabajo pero es muy importante para saber que haces mal y poder mejorar, nadie comete errores a propósito. Se supone que como adultos podemos dar y recibir opiniones, no siempre positivas mientras estén hechas de forma educada. Espero que esta persona no esté encargada de supervisar el código de algo crítico de lo que dependan vidas, porque en su afán de no herir sentimientos igual acaba hiriendo de verdad personas.
Imaginad que se cae un puente porque el encargado de revisar los cálculos estructurales tiene miedo de sacar los defectos por si ofende o hiere los sentimientos de alguien.
Esto tiene poco que ver con programacion y mucho con cierto tipo de personalidad toxica que desgraciadamente campa y medra a sus anchas en grandes y pequeñas empresas.
El primer interesado en una revision de codigo estricta es el propio programador. Los buenos, buenos de verdad, revisan el codigo que ellos mismos han escrito años antes. Cuando puedas ver ese codigo con admiracion y una cierta envidia de quien lo ha hecho, cosa totalmente posible ya que la memoria merma con los años, entonces, y solo entonces te puedes dar cuenta de que realmente sabes muy poco y te queda mucho que aprender. Programar es un arte, un estilo de vida y puede darte muchas alegrias o hundirte definitivamente en el fango.
Mirar el código no es práctico, el usuario solo ve el resultado final.
#49 Ese es precisamente el error en el que cae la gente cuando habla de programación. Da igual si el albañil ha usado una pala y un cubo o una escabadora. La gente solo ve el acabado; el resultado final.
#56 Pues que la casa del abuelo cebolleta que la construyó él mismo con cero conocimientos de arquitectura le puede dar por culo a Calatrava.
#16. Creo que no se puede explicar mejor.
#82 Ese caso "longevo" que me comentas lo he sufrido, pero por ser un ENCHUFADO así en mayúsculas, que entraba porque su papá trabajaba en un gran banco y tenía amistad/contacto con el dueño de la empresa. Pero en cuanto levantamos la perdiz ante el jefe, se fue a la calle porque no solo no hacía su trabajo sino que no nos dejaba trabajar a los demás. Eso sí, 3 meses estuvo cobrando un pastón como si controlase de verdad.
#87 Le deberíais haber remitido a Stackoverflow desde el primer día.
Y ahora se irá colgando la medalla de haber currado un año y medio ahí, presuponiendo que algo sabrá
¿Cómo ha llegado esta bazofia a portada?
Algo parecido pasa con los fotografos. Uno se cree bueno por ser el mejor de su promoción de FP, o por ganar algun premio local, ect... Luego sales al mundo (osea te comparas con buenos fotografos, acudes a festivales con buena seleccion), o te registras en OJODIGITAL y... bueno.... ahi descubres lo que es la destruccion, lo que son comentarios directos de que tu foto es una copia de X autor, o que tu procesado es horroso, o que te has dejado una mascara mas recortada en tu fotomontaje. Ahí es cuando realmente aprendes lo que es dolor... lo que te queda por aprender....
#35 No has entendido el artículo, él habla de si mismo como un amargado y de su afán de dejar comentarios agresivos para alimentar su ego en vez de ayudar a mejorar con el código con comentarios constructivos.
#21 Pensaba que ibas de sobrado y en realidad no sabías de que hablabas... Hasta que he leído
sus mierda, solo con eso ya estoy seguro que has tirado unas cuantas líneasPero el ansia por tener razon vendrá de algún problema de autoestima, no es simplemente que copió lo que le hicieron a el.
En meneame los "moderadores" o "admins" anonimos y sus clones hacen lo mismo con los envios que hacen los demas a su "comunidad". (iba a decir nuestra comunidad, pero no, es su escatergories y si quieren se lo llevan, pero despues que no vayan diciendo el "unete")
#80 En el término medio está la virtud, my friend. Tampoco hablamos de contratar a tipos como el Dr. Nick .
Pero que un tipo pueda poner piedras en la consecución de objetivos por exceso de ego (que no de celo) es algo muy común en IT.
#81 Todos somos mediocres en este mundillo. Lo que hoy sabes de sobra y eres un genio, es posible que mañana no valga para nada y tengas que actualizarte.
Es más, mucha gente no ha tenido la oportunidad de adaptarse tras dedicar todas sus energías y más horas de las debidas en cárnicas de mierda, donde se les nubla, satura y entumecen. Los que quieren salir de ahí y ponerse las pilas merecen todo mi respeto.
Luego están los mediocres intencionados. Los pasotas que no quieren aprender ni actualizarse y, en general, desean estar en un letargo intelectual y laboral hasta su jubilación.
#89 No podría explicarlo mejor. Pero vamos, los equipos deberían tener la capacidad de amonestar a gente que va a hacer daño. Y en el pair programming también puede ocurrir lo mismo que en las reviews, aunque en menor medida.
#2 Sabiendo hacer algo...
Mucho decir es eso.
#8 Estas revisiones, y pronto los desarrollos, no falta mucho para que las haga una IA,
#77 Eh, no. Yo en mi tiempo libre no cojo el móvil, no respondo correos, no estudio casi nunca cosas laborales (que al final siempre cae algo, pero más por curiosidad que por responsabilidad profesional). Si quieren que aprenda algo nuevo, que me manden a un curso o me liberen de otras tareas (como hacen). Ellos me pagan por mis horas de trabajo, no por mi tiempo libre.
En cualquier caso los adultos podemos darnos entre nosotros feedback positivo gastando el mismo esfuerzo que dándonos wow tremendos zascas omg como si tuviéramos 12 años. Si un compañero mete la pata, se lo explico a él y/o a los afectados sin sobrarme y sin tratar de demostrar que soy el más listo y el más Dr. House. Cuando yo la cago, espero lo mismo de mis compañeros y de mis superiores.
Si alguien no es capaz de sacar adelante su trabajo de ninguna manera pues evidentemente habrá que echarle porque las empresas son empresas y no ONGs, pero hay muchas razones por las que alguien puede no hacer bien su trabajo que son fáciles de solucionar.
#16 te recomendaría que te cambiaras de empresa. Hay otras cosas ahí fuera.
#7 vaya.. te pareces un poco al autor del artículo. :D:D
#119 Por que das a entender que lo normal que te ha pasado estos años es eso. Y no es lo normal. Si ocurre eso es que estás rodeado de compañeros tóxicos y lo mejor es que busques un mejor trabajo, como parece que has hecho. Así que se puede inferir que esos comentarios no están desencaminados por tu propia experiencia
#9 eso suele ser poco habitual.
Evidentemente si el equipo no le funciona, pues no será cosa suya. Pero en general...
#19 totalmente de acuerdo, prefiero la calidad humana y la actitud constructiva al talento tóxico. Un tío muy bueno con mala actitud puede cargarse a un grupo entero, en cambio una persona con pocos conocimientos pero buena actitud aprenderá y dejará de ser un problema rápidamente. Me ha tocado enseñar en mi equipo a muchos de los segundos y siempre se han convertido en profesionales competentes, de los primeros he conocido dos o tres y han durado poco, afortunadamente.
#93 Evidentemente si quieren que aprendas algo NUEVO es como dices, que sea en horas de trabajo. El problema es si no eres capaz de haver el trabajo por el que se te contrata.
hay muchas razones por las que alguien puede no hacer bien su trabajo que son fáciles de solucionar.
Y cuando no lo son a la puta calle.
Precisamente hoy estaba realizando un estudio de efectividad de los técnicos... Hay uno de otro equipo que da pena, ya tenía la impresión pero los datos me lo corroboran. Si dependiera de mí estaría en la calle.
#78 la empresa te contrata para un trabajo que se supone que debes saber hacer. SI no sabes pues te echan, no son ONG. LO de formar porque eres un inútil como que no.
#100 esa no es la realidad, al menos en las empresas en las que he estado. La realidad es que las empresas contratan gente con poca experiencia para no pagar mucho en salario y esperan que aprendan de los compañeros.
#109 sigue sin ser responsabilidad de los compañeros.
#111 yo he dicho que es de la empresa por lo tanto lo de despedirlo no aplica.
#126 tengo 40, dudo que se me pueda calificar como cachorro. Y probablemente (y lamentablemente) he echado a más gente a la calle en la vida de lo que puedas imaginar. Gente que se lo merecía y gente que no, que sólo se despedía por cuadrar el número. A nadie por motivos espúreos, debo decir.
Y según la abogada de mi empresa, se me da bastante bien.
#128 Si se lo merecen no tengo ningún problema en echarlos. ¿Donde ves la disonancia?
Y no fantaseo, lo hago si tengo que hacerlo.
#130 ni tú capacidad de expresión.
Sigo sin ver la disonancia entre lamentar despedir a alguien que no se lo merece y querer despedir a alguien que Sí lo merece.
#132 vale, entonces tienes un problema de capacidad lectora. En todo momento he dicho que el que no sirva a la puta calle. Para mi no servir es un despido merecido. Y a la puta calle lo define muy bien.
#134 entonces hay que echar también a quien ha hecho la selección.
Que obsesión con mantener a inútiles trabajando.
#136 no, con tener gente competente y no mediocre.
Tu estás obsesionado con defender al incompetente.
#137 Claro que sí, campeón. Por eso he explicado que una empresa no es una ONG y tal.
Un saludo y que sigas igual de bien.
#138 pues si no es una ONG al que no funcione a la puta calle, veo que estamos de acuerdo.
Besis.
#139 Las cosas de mayores son un poquito más complicadas que funcionar/no funcionar. Te diría que ya las entenderás, pero me temo que ya has cumplido suficientes años... Así que te deseo mucha suerte.
Es un flipado.
#36 No, si las revisiones de pares, bien hechas, son muy útiles. Nunca he dicho otra cosa. El problema de esas revisiones es que mal hechas se convierten en una distracción total. E incluso despidos, eso lo he vivido de cerca.
Hace algún tiempo cayó en mi empresa un ex CTO de otro sitio (donde tuvieron que contenerse para no hacer la fiesta de "despedida" con demasiado descaro). El pollo se puso a revisar los repositorios casi desde el primer día, y pocos meses más tarde unos cuantos acabaron en la calle. Que no eran precisamente malos. Eso sí, la formación, los cursos, y mejorar la documentación precisamente como refuerzo para que esos programadores "solucionasen sus deficiencias", ya tal.
Poco después el figura éste se fue antes de que le echasen a él.
#40 Es que parte de la responsabilidad de revisar código es ofrecer soluciones. Si como CTO identificó problemas pues hay que ofrecer unas soluciones y decir: "vamos a empezar a incorporar esta serie de procedimientos al equipo para evitar todo esto".
Es fundamental ser constructivo en las revisiones....
#46 Claro claro... Oye mira, dame 300.000 euros para hacerte una casa, pero no te preocupes por las calidades o los acabados, lo que importa es la fachada hombre.
#53 ¿Sí? Cuéntame más. Como si yo no fuese profesional de esto, por favor, hazme un buen mansplaining
#47 No fue el caso de este pájaro. Él siguió a rajatabla el viejo truco de cortar un par de cabezas para acojonar al resto... y tirar una bomba de humo para huir él cuando la cosa no mejoró sensiblemente después. Hasta el jefazo más lerdo es capaz de decir "has echado a varios y seguimos igual o peor, ¿no serás tú el Mourinho de turno?"
Hay muchas cosas como las revisiones por pares, las "metodologías ágiles", y mil mierdas más que son postureo, o se hacen para dárselo mascadito al jefazo que no tiene ni puta idea. Cuando el equipo está bien engrasado y todos saben de lo suyo, desde el CTO al junior recién salido de la facultad, esos "protocolos" se limitan al máximo. Las reuniones son como el colesterol, en su justa medida son muy útiles pero no pasan de ser un complemento. Más allá de esa pequeña cantidad llevan a la esclerosis.
#63 LP.
L: si me reconoces, te jodes.
#65 No he dicho que sea técnicamente superior a él, sino que sé cómo funciona la programación. Igual que él, igual que millones de personas que se dedican a ello. Sobre todo cuando se a apoyado en una verja, con un palillo en la boca, a decir "sabrás tú desto".