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
El alterego del admin menéame sin vida. Pero sabiendo hacer algo.
#2 Sabiendo hacer algo...
Mucho decir es eso.
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.
#7 Exacto! Todas las multinacionales Españolas necesitan un tio como este.
#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.
#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.
#7 vaya.. te pareces un poco al autor del artículo. :D:D
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 .
#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.
#19 #61 Que los mediocres monten sus empresas entre ellos y así no se se dedicarán a aprovecharse y explotar a otros a base de "ser buenas personas"
#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.
#90 No señor, todo el mundo tiene carencias de algún tipo pero eso nadie lo ha negado en ningún momento, dejad de montaros la película de que nos creemos infalibles.
Hay gente con un intelecto muy limitado que por mucho que se esfuerce y mucho que se invierta en ellos, nunca llegarán.
Esa gente no llega al nivel que su categoría requiere y "compensan" siento simpáticos o dando pena, pero el volumen de trabajo nos lo acabamos comiendo los que tenemos la mala suerte de compartir categoría con ellos.
#19 O sea, que para ti la actitud es más importante que la aptitud. Que sepas que me la guardo para nuestras interminables charlas en el Hangouts.
Yo, la verdad, para bien o para mal hace tiempo que no paso por el postureo de las revisiones por pares. Vistas con perspectiva, hacen más mal que bien, no las echo de menos. Es una de esas cosas que bien usadas es algo estupendo, pero abunda mucho más el mal uso.
#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.
#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.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.
#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
#36 A mi me gustaria ver a gente que documenta los cambios, mas alla de iniciales y fecha, que hace una funcion, que no declara todo variable global...
#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....
#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.
#59 Ostrás, iniciales que ese me suena!
#63 LP.
L: si me reconoces, te jodes.
#66 LP el ex-CTO? Entonces no. Se ve que es habitual en el mundillo
#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.
#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"
#62 Hace tiempo que en entrevistas de trabajo (la mayoría por puro zorreo laboral) utilizo esa técnica contra ellos mismos. En vez de pasar por absurdas pruebas técnicas (que suelen consistir en el mismo ejercicio copiao unas empresas de otras, y con cuatro cambios), enseño muestras de mi trabajo, y dejo clara una cosa. Por las buenas, soy un santo. Pero a mí no me mea ni Dios. No con esas palabras obviamente. Pero suele ser bastante efectivo, las reacciones suelen polarizarse entre "éste lo quiero ya" y que no vuelvan ni a contestarme.
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.
#11 Yo te puedo decir de un tio que lleva año y medio y no sabe programar ni un IF.
Un mentiroso compulsivo que decia saber programar y se le veia al primer dia que no sabia hacer la O. Es mas, hasta a un curso lo enviaron unos dias a hacer diagramas de flujo. Aparte de eso, es que es inutil.
Pues el jefe, de bueno es tonto o no se que pensar.
#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".
#79 Bueno, si yo nunca me he encontrado un caso asi.
Este, para mi, es un tio que se ha pasado la vida "tirando cable" y con 40 y pico años y seguramente mas intentos (de programar), ha oido que en esto de programar se puede "ganar pasta" y hasta trabajar desde casa como su colega el que tiene una consultoria etc..
Pero al final, te das cuenta que miente (era verlo perdido en el entorno de desarrollo, no saber escribir ni una sentencia), no piensa y es mas se cree que sabe, que es su problema.
Imaginate un lerdo que mete los morros en el PC donde 2 compañeros estan mirando un marron y se te pone a decir "decidme a mi eh, que yo lo se buscar, a ver, mira por ahi, mira por alla"... (sin entrar en jerga tenica, como el que te dice si has mirado el aceite, si tiene gasolina.., si es el motor... y al final "ves, por donde yo te decia!".
Para que te hagas una idea, le llevo un año saber arrancar el debugger, (a mi, solo a mi, me lo ha preguntado como 6 veces, como se arranca) ahora cuando esta con el culo algo apretado esta haciendo algo pero es imposible, sinceramente.
Creo que no esta en la calle por pena y porque se mantiene gracias a tareas de becario (procesar ficheros y mierdas asi).
En una empresa normal, en un mes estaba fuera, por inutil y mentiroso.
Al final su curro se lo han ido haciendo entre todos hasta que ha saltado la liebre de que todo el mundo estaba hasta los cojones. Lo peor como te digo, es que encima se cree que sabe algo, ahora igual se le han bajado un poco los humos, pero vamos.
#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.
#84 Este un paston no creo, pero desde luego mas de lo que merece. Un chaval recien graduado le da mil vueltas ya el primer dia, porque al menos algo sabe hacer y encima le pagarian una miseria, costa que este tio a mi me da que cobra un sueldo decente, por la edad que tiene no se hubiera venido sino. Este venia con la idea de aprender un poco y largarse. Ahora ni ha aprendido ni se puede largar porque se cae en la primera entrevista que le hacen.
Año y medio lleva ya. Yo empece a decir a la gente, no le escribais el puto codigo, que se tiene que caer que caiga, esto no le hace bien ni a el ni a los demas. Todo el puto rato se pasaba girando la cabeza, a ver a que mesa iba a "preguntar", pero de mesa en mesa te caia como un obus. Le hacias un trozo, a por otro, otro trozo y asi. Y hablar, eso si que sabe, mas que una cotorra.
Ah, y aguantale, que empieza a sulfurarse, dar patadas en el suelo, no tiene paciencia, no piensa no se para a ver una y otra vez... En resumen, que no le gusta esto, sinceramente.
Pero bueno, la culpa de los demas que no le enseñan, se piensa que esto es una academia.
#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á
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.
#48 Te ha faltado acabar como David Broncano, con un "os rajo cabrones!"
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.
#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
#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".
#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.
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.
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...
#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.
Programadores e informaticos con graves trastornos del autoestima y rasgos sociopaticos claros.
Pues lo de siempre vaya.
Para gozo mio, su trabajo lo hace Sonar últimamente y él es el siguiente en ser despedido.
#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.
#6 Efectivamente. Y además, se pasa el día pitando: Piiiii. Piiiii. Piiiii.... Y así.
#12 no todos los sonar suenan igual
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.
#92 departamento de proyectos y tecnologia de una petrolera holandesa y ahi ya pare de leer. Hablamos de españa, donde las multinacionales subontratan al personal y usan licencias piratas.
#94 No no, si yo soy de una subcontrata 😂 y, hasta hace 3-4 años lo que teníamos era lo del zurullo. Pero se restructuró la división en la que curro y se dijo que alé, a ser serios o a la calle... y la gente se puso las pilas.
#95 Pero entonces estas en holanda, estabas en una contrata de una empresa holandesa?
#96 La consultora es británica, pero no he pisado sus oficinas en Holanda en la vida. Lo mas cerca que he estado fué cuando llegué al aeropuerto de Amsterdam, donde tienen la oficina, y me fuí a trabajar a las oficinas del cliente (en La Haya) . A parte de eso, cada mes o así uno se descuelga para invitarme a comer, y no controlan ni horas facturadas, ni vacaciones, ni nada... desde ese punto de vista, lo que me dice la gente es que soy "un freelance con parásitos" (y seguridad social... claro).
#97 nombre de la consultoria? Lo de que no controlan ni horas, ni vacaciones...
#98 Seguimos por privado, te acabo de añadir como amigo.
#98 Las horas exactas es normal que no las controlen si estás con el cliente.
Las vacaciones es cosa de la empresa que te tiene en nómina por lo que a la empresa cliente le da un poco igual también.
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.
#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.
#23 "..escribirlos de forma que el programador nunca se sienta atacado.."
Linus Torvalds Seal of Approval!
#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"
#30 Lo habitual es indicar los fallos y porqué es un fallo. Dar una explicación para que el otro aprenda. Si el objetivo fuera corregir los fallos exclusivamente el revisor corregiría el código directamente no lo comentaria para el revisado.
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?
ANTIPATTERNS
Es un poco exagerado.
Alguien me hace un resumen?
#10 Que el que revisa el código se ha dado cuenta que es un capullo y un amargado y que lo siente.
#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?
#16 Esto es en los mundos de yupi no? Me refiero porque que yo sepa cada uno pone su zurullo y se va corriendo a casa.
El resumen que pedia era de que iba el texto un poco, que le pasaba al menda, si es que se quedó sin fresisuis y escribió semejante tocho y lo subio a github o que.
#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íneas#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
#16. Creo que no se puede explicar mejor.
#16 Vives en un entorno muy tóxico. Cambia de empresa.
#16 te recomendaría que te cambiaras de empresa. Hay otras cosas ahí fuera.
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.
#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.
#50 Efectivamente, pero se trata de una opinión personal.
Igual esos comentarios no son tan malos pero el no puede evitar sentirse subjetivamente mal por ellos. Por lo tanto el problema es que no es psicológicamente apto para el trabajo.
Mirar el código no es práctico, el usuario solo ve el resultado final.
#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.
#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.
#53 ¿Sí? Cuéntame más. Como si yo no fuese profesional de esto, por favor, hazme un buen mansplaining
#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.
#71 Es que el Code Review no va de superioridad técnica, tal y como explico en un comentario mío de este hilo. Es más, independientemente de lo bueno que seas, el Code Review se debe pasar igual. No es "yo sé más, esto lo haces mal", y si en tu empresa es así, cambia de empresa.
#73 Veo que no has entendido nada. Revisa tu comentario y reescribelo.
#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.
¿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....
Pero 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")
Es un flipado.
No sé si la mitad de los que comentáis habéis leído que el autor circunscribe está forma tóxica de revisar código a su industria en Rusia. Perfectamente me cuadra con la deriva del país de Putin: hay que ser muy machos y muy bordes y muy brutos y así todos seremos mejores y más machos y más bordes y más brutos etcétera.
Si no hace bien su trabajo, a la calle.
#8 Hay muchos motivos por lo que una persona puede no hacer bien su trabajo, y no todos son responsabilidad del afectado.
#9 eso suele ser poco habitual.
Evidentemente si el equipo no le funciona, pues no será cosa suya. Pero en general...
#8 Eso, que enseñar a la gente a trabajar mejor y hacer críticas constructivas es rebajarse.
#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.
#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.
#100 Uy, qué subidito el cachorro. Ya se te irá quitando esa facilidad para pedir que manden a la gente "a la puta calle" con los años, ya verás.
#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.
#8 ya lo de ayudarles y dejarles que aprendan... qué mierda de futuro nos espera con gente con esas ideas.
#8 Estas revisiones, y pronto los desarrollos, no falta mucho para que las haga una IA,
#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.
#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 ;-).