Portada
mis comunidades
otras secciones
#6:
#1 En el gremio hay mucha confusion entre ser "bueno" y ser "un puto borde de mierda"
Es dificil distinguirlos, pero en general, al que es "bueno" no solo levanta el trabajo si no que suele cohesionar al equipo, da soporte a los junior y ayuda a sus compañeros, no lo verás dando un chillido y su aportacion pasa casi desapercibida. Del "puto borde de mierda" escuchas hablar constantemente con frases tipo "el tipo es un fiera pero..." y la gente tiene miedo a preguntarle, luego pillas su codigo y es una guarrada desestructurada de arriba abajo y si le pides que te lo explique se pone nervioso y agresivo, si insites enumerará sus multiples años de experiencia multilenguaje, grado academico o demás flipadeces.
Y no sabes cuantas veces me he encontrado con el segundo perfil, el primero es oro en paño y muy dificil de encontrar.
Es dificil distinguirlos, pero en general, al que es "bueno" no solo levanta el trabajo si no que suele cohesionar al equipo, da soporte a los junior y ayuda a sus compañeros, no lo verás dando un chillido y su aportacion pasa casi desapercibida. Del "puto borde de mierda" escuchas hablar constantemente con frases tipo "el tipo es un fiera pero..." y la gente tiene miedo a preguntarle, luego pillas su codigo y es una guarrada desestructurada de arriba abajo y si le pides que te lo explique se pone nervioso y agresivo, si insites enumerará sus multiples años de experiencia multilenguaje, grado academico o demás flipadeces.
Y no sabes cuantas veces me he encontrado con el segundo perfil, el primero es oro en paño y muy dificil de encontrar.
#2:
He tenido una experiencia parecida, es muy importante que haya un buen jefe de proyecto que sepa gestionar este tipo de "genios".
Pueden ser muy utiles, pero como no saben trabajar en equipo hay que gestionar muy bien la comunicacion.
Si no se gestiona bien puede ocurrir que se conviertan en tiranos y en llave para todo lo que se haga y eso no es bueno para nadie.
Pueden ser muy utiles, pero como no saben trabajar en equipo hay que gestionar muy bien la comunicacion.
Si no se gestiona bien puede ocurrir que se conviertan en tiranos y en llave para todo lo que se haga y eso no es bueno para nadie.
#7:
#6 Es que hay mucha diferencia entre ser buen programador de cosas concretas, y ser buen trabajador en un equipo. Porque el código bueno no es sólo el que se ejecuta más rápido o el que se tarda menos en escribir. Eso quizá vale para el que uses en tu casa. En el trabajo, el código bueno es, además del que hace eso, el que es más fácil de entender, el que se modifica de forma sencilla, o el que son capaces de entender y modificar el resto de tus compañeros.
De nada sirve tener un código un 5% más rápido, si luego al primer problema hay que reescribirlo desde cero porque no lo entiende ni el tato. Eso no es buen código, y el que lo ha hecho no es buen programador.
De nada sirve tener un código un 5% más rápido, si luego al primer problema hay que reescribirlo desde cero porque no lo entiende ni el tato. Eso no es buen código, y el que lo ha hecho no es buen programador.
#22:
#6 Tengo que discrepar. Tras muchos años y muchas empresas nunca, pero nunca, me he encontrado un programador crack que sea antipático o poco asertivo.
Ojo, cracks de verdad. Gente que seguramente sea top100 en España. Gente que sabes que están a otro universo.
Otra cosa es que trabajen bien en equipo. Puede que no lo hagan, pero no por maldad sino porque tal vez trabajan tantísimo, solos, cuando los demás estamos haciendo algún otro hobby.
Programadores que se creen buenísimos por malinterpretar algunos libros de programación, siendo poco productivos, de esos, a patadas. Antipáticos y cretinos.
El crack de verdad no tiende a ser soberbio. No necesita alimentar su ego.
Edito: estamos diciendo lo mismo, salté tras leerte en vertical, perdones. Vuelvo a la cueva.
Ojo, cracks de verdad. Gente que seguramente sea top100 en España. Gente que sabes que están a otro universo.
Otra cosa es que trabajen bien en equipo. Puede que no lo hagan, pero no por maldad sino porque tal vez trabajan tantísimo, solos, cuando los demás estamos haciendo algún otro hobby.
Programadores que se creen buenísimos por malinterpretar algunos libros de programación, siendo poco productivos, de esos, a patadas. Antipáticos y cretinos.
El crack de verdad no tiende a ser soberbio. No necesita alimentar su ego.
Edito: estamos diciendo lo mismo, salté tras leerte en vertical, perdones. Vuelvo a la cueva.
#16:
Lo que puede que no te cuenten es que esa persona que hasta ahora arreglaba problemas estaba cansada de ver como sus jefes no le hacían ni caso a la hora de solucionar otros problema para que no todo dependiera de el y se apuntaban para si los buenos resultados que esa persona conseguia....es sólo una hipótesis....pero tampoco tan descabellada...además echarle la culpa a el de su propia inoperancia para no arreglar el problema de comunicación mucho antes no dice nada bueno del autor del artículo....
#1:
Según lo que dicen, yo no lo llamaría talento precisamente...
#4:
Típica historia. Se tiene a alguien bueno, hay quien tiene celos, se le presiona, se le crítica la reacción a esa presión y se le echa.
Hay empresas que no saben gestionar el talento ni la igualdad de trato.
Hay empresas que no saben gestionar el talento ni la igualdad de trato.
Comentarios
He tenido una experiencia parecida, es muy importante que haya un buen jefe de proyecto que sepa gestionar este tipo de "genios".
Pueden ser muy utiles, pero como no saben trabajar en equipo hay que gestionar muy bien la comunicacion.
Si no se gestiona bien puede ocurrir que se conviertan en tiranos y en llave para todo lo que se haga y eso no es bueno para nadie.
Vaya por delante que NO he leído el artículo. Pero, si va de algo parecido a lo que comenta AizKorri ( #2 ) decir que de un tiempo a esta parte, la figura de " el ìdolo " / tipo Jobs, ó cosas por el estilo / se ha reemplazado por la de " Equipo ".
Y, en este sentido, lo que no sepan jugar en equipo, más vale que se hagan autónomos cuanto antes. Así serán totalmente suyos.
Según lo que dicen, yo no lo llamaría talento precisamente...
#1 En el gremio hay mucha confusion entre ser "bueno" y ser "un puto borde de mierda"
Es dificil distinguirlos, pero en general, al que es "bueno" no solo levanta el trabajo si no que suele cohesionar al equipo, da soporte a los junior y ayuda a sus compañeros, no lo verás dando un chillido y su aportacion pasa casi desapercibida. Del "puto borde de mierda" escuchas hablar constantemente con frases tipo "el tipo es un fiera pero..." y la gente tiene miedo a preguntarle, luego pillas su codigo y es una guarrada desestructurada de arriba abajo y si le pides que te lo explique se pone nervioso y agresivo, si insites enumerará sus multiples años de experiencia multilenguaje, grado academico o demás flipadeces.
Y no sabes cuantas veces me he encontrado con el segundo perfil, el primero es oro en paño y muy dificil de encontrar.
#6 Es que hay mucha diferencia entre ser buen programador de cosas concretas, y ser buen trabajador en un equipo. Porque el código bueno no es sólo el que se ejecuta más rápido o el que se tarda menos en escribir. Eso quizá vale para el que uses en tu casa. En el trabajo, el código bueno es, además del que hace eso, el que es más fácil de entender, el que se modifica de forma sencilla, o el que son capaces de entender y modificar el resto de tus compañeros.
De nada sirve tener un código un 5% más rápido, si luego al primer problema hay que reescribirlo desde cero porque no lo entiende ni el tato. Eso no es buen código, y el que lo ha hecho no es buen programador.
#7 Yap pero supongo que fomentado por la flipadez de las peliculas, existe la idea platonica de que un programata puede permitirse el lujo de ser borde y asocial si es "listo".
Y meu... que gran cagada.
#8 puede permitirselo,porque el mercado esta jodido,hace falta gente por todos lados,y encontrar a un tío medio decente es una lotería.
#8 también es cuestión de formación.
"A programar se aprende programando."
El lema de la Facultad, se debe aprender sólo, y es un gran problema, porque es lo contrario a programar de forma colaborativa.
Para eso hace falta disciplina y metodología, y requiere mucho tiempo.
#6 vamos por partes:
1,tu que sabrás que programas en SAP.
Señoría,no hay mas preguntas.
#19
Vamos por partes:
El lenguaje de SAP es ABAP
Seguimos, a dia de hoy es ABAP Java y en menor medida HTML5 CSS y JS
Antes de eso era programata en Matlab y Oracle PL-SQL
Y antes VBA
Y he tocado/toco algunas otras cosas más (Phyton, C, Perl, Pascal, BASH, diferentes cacharros de codigo estructurado para automatas...) pero no diría que tengo idea, toco de cuando en cuando.
Vamos que si quieres putear haber dicho que cojones sabré yo que soy imbecil, que entonces te tendria que dar la razón, pero si vas a citar los lenguajes al menos se correcto
#23 la cosa es que te des por ofendido,SAP PO es básicamente Java(si no tengo entendido mal),pero la cosa es meter cizaña a los SAPeros.
#30 Ñiaaaa si y no y depende de version hay java o ABAP o ambas y todas son una puta mierda
#32 no hay nada peor que webdynpro,pase lo que pase,nada sera peor que esa basura.
#34 Bueno... hay universos de frontales de admision de ficheros en texto plano CSV que te reconcilian con cualquier tecnologia por deficiente que esta sea
#37 cuando el frontend supera el scroll de la consola del navegador,entonces solo entonces,sabes que vas a morir.
#19 Cuánta crueldad...
#28 le gusta duro,trabaja con SAP,que proporciona la peor UX del mercado.
#6 también los hay que tienen un código en apariencia anárquico y son capaces de explicartelo , aunque no termines de enterdeg el porqué así, son buenos en lo suyo, saben ayudar y se dejan ayudar
#21 Lo siento pero: no existe el concepto de "codigo anárquico bueno"
El codigo ha de ser facilmente interpretable para que sea mantenible y en un momento dado escalable, hay cientos de aspectos en mi vida que son anárquicos y desordenados, mi codigo no.
#29 Es una manera fácil de hacerte imprescindible.
#36 O de que te larguen del proyecto, yo te puedo asegurar que no soy muy permisivo para segun que cosas... Y existe un señor Skaworld que tiene muy mala ostia si te caza liando las cosas a proposito, nombrando las variables como la mierda, no comentando procesos complejos...
#40 #36 Que te larguen del proyecto o de la empresa.
Imprescindible, realmente, no hay nadie. ¿Pero alguien que no hace código con un mínimo de calidad?
¿Para qué sirve alguien que hace código que hay que tirar y rehacer?
Conozco una empresa que ni siquiera hacen PR. Se están yendo todos menos los que "se niegan a hacer PR". Si el director técnico tuviera algo de cerebro le habría obligado a trabajar como los seres humanos o le habría despedido.
#64 Di la empresa, por favor, para saber donde no echar mi CV.
#67 No puedo Es muy conocida en el sector biotecnológico, tengo a alguien muy cercano allí trabajando y de mi nick se atan cabos muy rápidamente si alguien trabaja en ella.
#77 No te preocupes, lo entiendo lo siento por él, en algún momento explotarán todas esas buenas artes.
#40 Vamos, que eres de los "buenos bordes de mierda"
#93 No no, yo soy solo un cabron violento que se ve obligad por las circunstancias a no poder repartir ostias a mano abierta
#94 Yo es que sigo la tactica de "Os voy a quitar el puto framework y vais a tiraros un mes programando en ensamblador con el notepad" ...
Yo soy de los de violencia gratuita, extrema y sadica...
#6 Tengo que discrepar. Tras muchos años y muchas empresas nunca, pero nunca, me he encontrado un programador crack que sea antipático o poco asertivo.
Ojo, cracks de verdad. Gente que seguramente sea top100 en España. Gente que sabes que están a otro universo.
Otra cosa es que trabajen bien en equipo. Puede que no lo hagan, pero no por maldad sino porque tal vez trabajan tantísimo, solos, cuando los demás estamos haciendo algún otro hobby.
Programadores que se creen buenísimos por malinterpretar algunos libros de programación, siendo poco productivos, de esos, a patadas. Antipáticos y cretinos.
El crack de verdad no tiende a ser soberbio. No necesita alimentar su ego.
Edito: estamos diciendo lo mismo, salté tras leerte en vertical, perdones. Vuelvo a la cueva.
#6 No jodas, ¿Has trabajado con Pablo Casado?
#39 Yo no me dedico a las redes neuronales de biotecnologia con base de cadenas de bloques grafenicas de conduccion autónoma en la nube 4.0.
ojalá
#42 También es una autoridad mundial en blockchain. No pretendas restarle méritos
#43 "blockchain" = "cadenas de bloques"
Como se nota que no has estudiado en Aravaca
#44 Claro, y "driver"="conductor" y no veo a nadie decir voy a instalar el conductor de la impresora. A ver si aprendemos a hablar con propiedad
#47 Nop, "driver" = "controlador" y seguro que has escuchado a alguien decir que va a instalr el controlador de la impresora.
#48 ¿Entonces Robert de Niro era un controlador?
#49 No, roberto era "Tasista", tambien fue "Torete correteando" y actuo en "Caló" o "Er cazadó de bambis"
#6 tengo a un metro mío a un "un puto borde de mierda", el problema es que sabe lo que hace , demasiado bien, pero denigra el trabajo de los demás, sólo hay una solución buena, la suya, la de los demás es una mierda y si no lo haces clavado a como lo hace él eres un técnico de muy bajo nivel (mis güevos, tiene alguna solución que para mi es una puta chapuza)
Incluso se ha llevado unas cuantas quejas del personal pero no lo echan, la empresa sabe que si se larga, a pesar de ser todos prescindibles, lo vamos a pasar mal intentando resolver incidencias que sólo el sabe como resolverlas. que ojo sabe como porque lleva años y se conoce la infraestructura al dedillo y porque tiene conocimientos de sistemas y de programación a la vez, lo cual le da mucha ventaja.
Bueno el caso es que yo sé de sobra que es prescindible y sí también lo he pillado en renuncios y chapuzas (como he mencionado arriba) aunque es verdad que son pocas. Por mi podrían largarlo mañana mismo
#46 Huye. Rápido.
Porque sus mierdas te las vas a acabar comiendo tú y encima serán tu culpa
#56 Na, si se jode algo le echo la culpa a el y a sus soluciones
#6 Por experiencia te digo que lo primero lleva inevitablemente a lo segundo si el contexto es el adecuado.
"su aportacion pasa casi desapercibida"
Precisamente ahi esta el problema, los mediocres se aprovechan de eso para destacar a la primera de cambio y eso acaba quemando enormemente.
#51 Se supone que tu labor como gestor de equipo deberia ser precisamente identificar eso, si no eres capaz de diferenciar el ruido del trabajo real.... pos la estas cagando.
CC #54
#53 En sectores donde los "gestores de equipo" no tienen formacion tecnica eso es pedir peras al olmo.
Por ejemplo en videojuegos, que es donde trabajo ahora, quien tiene la ultima palabra no tiene ni idea de tecnologias y la mediocridad entre programadores esta a la orden del dia (la mayoria se dedica a hacer politica para aparentar y convencer a otros de lo que molan y lo buenos que son).
La verdad es que ahora mismo estoy haciendo puntos para que me echen y no cae la breva, mi juego esta previsto para salir en Julio y saben de sobra que sin mi se va todo a la mierda.
#55 Bueno, te diria que hay otros sectores... yo soy ERPs (SAP) donde el concepto de mantenimiento y escalabilidad es critico y el margen de errores en pro se paga no con retrasos si no con posible demanda y divertidos juicios (ahi ahi sin presiones
) y ya te digo yo que la cosa cambia.
Y cuanto mas te acercas a software crítico la cosa cambia mas y mas.
#57 Yo he trabajado en videojuegos y de lejos es donde he visto más talento. Además, los directores eran antiguos programadores y el peor de ellos, se defiende.
Si el CTO se ponía duro en una charla técnica, le seguían solo uno o dos.
Recuerdo una charla de uno de ellos en una universidad. Era hilarante ver a cara de los pobres estudiantes. Reconozco que al final, las últimas diapositivas, ni yo mismo pude seguirles.
Conozco una empresa donde hacen software para secuenciar enfermedades del ADN humano, y el equipo de desarrollo y la metodología de trabajo es un desastre. Laboratorios de todo el mundo lo usan y nadie pondría la mano en el fuego porque vaya bien y saque los datos correctamente. Ni siquiera los que lo usan, por lo que hacen lo imposible para verificar los resultados.
No es por sectores, es por directores que saben o no saben lo que hacen.
#6 Cuando la aportación de alguien tan valioso pasa "casi desapercibida" es cuando esa gente se quema y, o se convierte en el tirano que hay que echar, o se va. Y si son difíciles de encontrar es sencillamente porque en realidad no se valora en el mercado lo suficiente como para que merezca la pena ir de experto-mártir-superhumilde.
#6 Yo lei este articulo hace tiempo (es viejuno) y tengo que romper una lanza por Rick: Lo que el articulo describe es básicamente el proceso de como QUEMAR a un empleado.
En mi opinion los de la empresa son MUY gilipollas. Es la labor de un buen jefe saber sacar lo mejor de cada uno de sus empleados. Si la única forma de que tu equipo funcione es que todos se lleven bien sin problemas en el mundo de la piruleta... entonces no me hace falta un jefe.
Entonces partimos de la base que tienes a Rick comiéndose la mierda de todo el equipo y sacando adelante su curro y el de los demás (el propio articulo lo admite en sus primeros parrafos). Primera alerta roja que me salta nada mas leerlo. Que mierda de jefe permite eso?
Luego que si el código no se entiende y no esta documentado. Segunda alerta roja! Donde cojones estaban el jefe y los compis durante todo el desarrollo? Nadie se ha puesto a revisar el código hasta que el barco se esta hundiendo? Tienes a un tio haciendo el curro de todo un equipo (bien o mal, da lo mismo) y te sorprende que no este documentado y este lleno de ñapas??
Y cuando Rick se empieza a quemar y su trabajo se empieza a resentir, entonces es cuando un buen jefe debe intervenir y FORZAR a repartir la carga de trabajo. Y si es necesario decirle "tomate una semana de vacaciones o te despido". Pero no, los jefes seguian sentados sin mover las posaderas mientras todo se iba a la mierda.
Y cuando deciden por fin hacer algo al respecto, que básicamente supone mandar a la mierda todo el curro que Rick ha estado haciendo en solitario... Rick explota y se le va la olla. A alguien en serio le sorprende???
Y cuando se le va la olla y se empieza a comportar de forma poco profesional (aunque no peor que sus jefes y compañeros durante todos los meses anteriores), su único recurso, lo único que se les ocurre, es despedirle. No le dicen "tomate un mes y luego vuelves", no le dicen "igual te conviene cambiar de proyecto", no le dicen "vamos a hablar con RRHH y el ombudsman a buscar una solución negociada". No. A la puta calle, Rick.
Resumiendo: Queman a un tio y cuando explota le despiden. Y van dando lecciones. Tocate los cojones!!!
#5 No estoy de acuerdo. #4 ha hecho la misma lectura entre lineas que hice yo cuando lo lei. Lo elaboro en #66 si te interesa una opinion discordante
#66 Pues tenemos conceptos muy diferentes de gestion:
Si la única forma de que tu equipo funcione es que todos se lleven bien sin problemas en el mundo de la piruleta... entonces no me hace falta un jefe.
Si, la principal labor desde mi punto de vista cuando gestionas personal es que todos esten a gusto, con una carga balanceada y acorde a sus habilidades de manera que el trabajo "fluya". Por misterios insondables de la gestion de personal, resulta que la peña es mas eficiente cuando no siente que le estan meando en su cara.
Entones partimos de la base que tienes a Rick comiéndose la mierda de todo el equipo y sacando adelante su curro y el de los demás (el propio articulo lo admite en sus primeros parrafos). Primera alerta roja que me salta nada mas leerlo. Que mierda de jefe permite eso?
No sabes como Rick llegó a esa situacion, pero Rick no es bueno, un tipo bueno, o lo que yo considero ser bueno, cuando me llega un marron es sentar al que te lo envia a tu lado y explicarle cual es el problema, y metodos eficientes de atajarlo, eso hace un analista senior con los junior, el tipo te va a pedir ayuda una vez, pero a la siguiente ya se apaña solo. Si Rick ha terminado haciendo el trabajo de media oficina me juego los dos huevos a que es porque A) no explica lo que hace y como lo hace ( con lo que seria un mal trabjador de equipo que no entiende como deberian funcionar las dinamicas con compañeros de diferentes niveles) o B) No quiere explicarlo bajo la entrañable premisa de hacerse imprescindible (con lo que seria un mal trabajador de equipo y ademas un puto cancer) y perdona pero por experiencia profesional, yo escojo la B), es muchisimo mas comun de lo que piensas.
#70 Y quien permite esa situación? Por qué no se corrigió en el minuto cero, bien por las buenas o despidiendole mucho antes?
Es labor de un buen jefe que el equipo sea productivo y sano. Hay veces que eso ocurre de forma natural y es estupendo. Pero un buen jefe es el que reconduce la situación cuando eso no pasa de forma orgánica.
#71 Por eso es importante en cuanto cazas a un tipo guarreando el codigo como parecia ser el caso para hacerse imprescindible y poder chulear, cascarle la bronca padre, y a la segunda estas fuera que es lo que vengo diciendo desde el principio.
No es una cuestion de reconducir, yo no puedo pasarme el dia auditando el codigo de todo el mundo, tarde o temprano si esa es la actitud te la van a colar, ahora bien eso es para mi criterio un comportamiento grave, muy grave y una vez te aviso pero dos ya no quiero currar contigo.
#70 #74 En lo de que Rick queria hacerse imprescindible puedes tener razon, pero eso por desgracia tambien lo hacen gente muy mediocre y las consecuencias pueden ser bastante peores. De hecho yo estoy contando los dias para acabar el proyecto por ese mismo motivo.
Y basado en mi actual situacion yo diria que no es cosa de Rick sino de la empresa, que le convenia tener menos empleados de los realmente necesarios (o simplemente no ha priorizado algo que deberia ser maxima prioridad) y en lugar de contratar mas gente han propiciado eso (de lo que se han beneficiado luego, que eso de que no han reutilizado casi codigo de Rick es lo que dicen ellos...). Tan raro te parece eso sabiendo como actuan muchas empresas?
#75 yo no sé cómo funcionan otras empresas o que dirán otros jefes, yo de digo lo que opinión yo de lo que entiendo es un entorno laboral sano y eficiente.
Seguro que hay un porrón de sitios donde sucede lo que dices, yo intento que eso no pase en mis equipos y si llegase a ese sitio y viese ese percal es muy probable que actuase igual, esa situación es insostenible.
#76 Pues igual es que tienes mucha suerte pero sigue sucediendo (y mucho) que enchufen a gente bastante inutil pero con buenas conexiones, y cuando se tiene la mala suerte de estar en la misma categoria y nivel (teorico, por supuesto) que ellos eres tu el que se acaba comiendo su trabajo ademas del tuyo.
Y cuando tu proyecto tiene fecha fija de publicacion (cosa que no ocurre en todos los proyectos informaticos) y te comes tu solo lo que esta planificado para ser hecho por 3 o 4 programadores no es cuestion de opinion subjetiva, son jodidas matematicas.
#74 Pues o haces peer review o SI necesitas a alguien entre cuyas tareas esté auditar el código. Yo reviso las pull requests de parte de mi equipo, y otra compi revisa la otra mitad.
#79 diferentes metodologías yo no audito mis propios desarrollos, los auditan terceros en tst, yo diseño, pico y doy soporte técnico a Juniors y consultores funcionales pero se supone que no tengo que auditar (otra cosa es que revise algunas cosas específicas y haga pruebas unitarias por mi cuenta sobre las cosas antes de dar el visto bueno para revisión) de eso se encarga una herramienta automatizada en SAP llamada SCI parametrizable para cazar cagadas que revisa principalmente sintaxis y algunos rollos de rendimiento y luego el equipo funcional la funcionalidad del cacharro y luego el cliente. Cosas de la responsabilidad legal ante cagadas o gente creativa cuando entre las cosas que manejas hay cuentas bancarias que mueven mucha pasta diaria.
Trabajamos en sectores diferentes, con herramientas y metodología diferente, igual en tu sector tienes razón, en el mío nop
#83 Lo estás llevando a tu terreno y la discusión inicial no era esa. Además por lo que cuentas tu no eres el gerente ni el jefe de proyecto sino el arquitecto y desarrollador senior (y a mucha honra!). Es decir, tu eres Rick. Y yo estoy criticando a los jefes de Rick por no saber llevarle ni en la parte personal ni en la técnica.
#85 Home la discusion inicial era si actuaron bien o mal y yo te digo que desde mi punto de vista (que esta sesgado por mi sector y forma de trabjar) si y lo digo porque no es la primera vez que veo comportamientos similares y desde mi punto de vista son inaceptables.
Y sobre mi puesto, pos a ver no yo no vendo motos (y salveme dios de recibir esa bala), no ejerzo de manager, pero ejerzo la direccion técnica de proyecto, en mi mundillo un proyecto tocho, una implantacion, implica un director/manager de proyecto (que será el principal "comercial") e inmediatamente por debajo la direccion tecnica (que es un servidor) y la funcional (que es otro colega) y debajo pues seniors y juniors. Me encantaba ser Rick pero tristemente soy un Morty muy Morty que tiene que lidiar con Ricks (y creeme que el mundillo de SAP está lleno de flipadetes con infulas elegidos para la gloria de mierda porque ganan 4 putos cacahuetes)
#87 Yo a lo que voy es a como se llega a esa situación. Las cosas no ocurren de repente y porque si. Ocurren porque se permite y se fomentan. Y muchas veces se fomentan comportamientos y actitudes tóxicas por inacción al no cortarlas de raíz la primera vez que se dan. Y el artículo me hace saltar todas las alarmas de "gerente inútil". Un tío senior no te hunde un equipo ni un producto, ni genera él solo lo que describe el artículo. Unos gerentes incompetentes si que pueden.
#89 A ver yo (toca madera) nunca me he visto en esa situacion, tambien porque lo he atajado antes (ya sea mediante broncas que uno tambien sabe ser macarra o, solo una vez pero la persona se lo gano a pulso, realmente es una situacion muy desagradable, solicitando la expulsion del proyecto via "yo contigo no trabajo que no me pagan para aguantar a niñatos") pero si he entrado en sitios donde ves esa situacion enquistada desde hace tiempo en equipos de mantenimiento.
Empieza poco a poco, tienes a un tipo que es resolutivo, pero hace mierda, esa mierda la vende como "nuevas tecnicas que tu no entiendes" y en mi sector hubo una época donde no habia mucha gente que tuviese un conocimiento profundo del sistema y habia mucho vendehumos (y sigue habiendo, SAP es un mundillo muy cerrado) y ese tipo poco a poco se va haciendo con mas cuota de poder a base de ofuscar su codigo para que nadie se lo toque, el es el responsable del modulo de X porque ni dios sabe como funciona, no ha documentado nada, el codigo no está comentado y como hablamos de sistemas criticos y muy caretes (para que te hagas una idea, un paron de almacen igual son 100.000 pavos al dia y un proyecto "muy pequeño" es raro que te baje de los 10.000 pavos) se mantiene la premisa de "si funciona no lo toques" .
Lo malo de la situacion es que ese tipo tiende a ir acumulando cada vez mas cuota de poder, hasta que basicamente es el unico que maneja todo, se le ha ido completamente de las manos su estrategia (por eso digo que el principal afectado por su idiotez es el mismo) porque en el momento en que falla algo, no tiene manos para abarcarlo todo (y la ofuscacion y falta de documentacion una de las putadas que tiene es que te acuerdas hoy, pero dentro de 3 años cuando de repente tienes que tocar lo que has hecho de espaguetti... pos cacota) y empieza el problemon, el chacho se estresa, el sistema está hecho unos zorros y la cosa revienta en su cara, la solucion realista parte por tirar todo abajo y levantarlo de nuevo (en SAP solemos enmascararlo como cambios de version, tienes el sistema tan hecho un mojon que vamos a aprovechar el cambio de version para replantear toda esta mierda y dejartelo bonico) si por encima el chacho entorpece mas que ayuda, meu este tio no te hace nada bien y desde luego necesita un cambio de aires
Si, la direccion tiene culpa, pero no exculpes a tu "Rick" que culpa tambien tiene la suya. Por no hablar de que joder tio nuestro sector es una mierda pero si algo tiene es mercado de trabajo, mira, si estaba quemado, un cambio de aires no le vendra mal.
#91 Goto #90 que describo al menos lo que yo he visto por ahi.
Amos que si que tienes razon que no suele ser lo habitual, pero haberlo haylo.
#90 No creo que en este mensaje estés describiendo a nadie bueno en su trabajo, precisamente lo que describes es un eterno mediocre trepa que busca destacar a costa de sus compañeros buenos (lo cual no coincide con este artículo).
En lo que estamos de acuerdo es que le han hecho un favor enorme despidiendolo.
#4 #66 Exactamente. Despues de exprimirlo hasta la medula le dan la patada y ni gracias.
#5 Creo que he entendido bien.
Se trata de unas personas que suben un artículo a una web poniendo a parir a un compañero de trabajo.
¿ Cómo lo llamamos ? ¿ Putada, cerdada, agresión ?
Está claro la clase de personas que son los agresores. De eso no hay duda.
Sobre la víctima, hay que tener mucho cuidado en juzgar a alguien por lo que dicen de él sus enemigos, sobre todo si son de la calaña de estos.
¿ De acuerdo, verdad ?
Cualquiera que haya llevado grupos de trabajo sabe que siempre hay quien marea, que la lía y que te lía. Por eso se deben tener unos criterios claros: mérito, capacidad y objetividad.
Aquí se trata de un grupo con un ambiente enfermizo y quien lo gestione, lo hace realmente mal.
Prácticamente en el post solo hay insultos.
Problemas reales:
¿ Está aislado ? Es imposible que en un grupo de trabajo alguien esté aislado. te acercas a él, le dices buenos días, hablas un poco y ya no lo está.
¿ Que está sobrecargado de trabajo ? Lo mismo. Es imposible, Te acercas y le dices "tienes mucho trabajo, te ayudo con algo".
¿ Que solo él sabe hacerlo ? Mentira. Mira cómo luego se ponen todos. Lo que pasa es que quien no quiere ayudar no va a decir "tengo mucho morro". Siempre dice "no sé y además es por culpa suya".
Y así puedes seguir. El artículo destila mucho odio y te dicen a quien odiar, pero si lo llevas a lo objetivo, los agresores tienen poca, pero muy poca razón.
Ya lo último, subir un artículo a internet para insultarle. Es increíble, eso se ve muy pocas veces en la vida, yo es la primera vez que lo veo.
El jefe de toda esta gente es muy malo. Su trabajo es que haya buen ambiente y quedarse con los mejores trabajadores. Se ha quedado con lo peor.
De estas empresas hay que huir siempre. Si eres bueno porque te machacan o te ves obligado a esconderte. Si eres malo, porque la empresa se va a ir a la mierda.
Y te digo que una vez que pases unos meses o años tratando con gente a la que no puedes elegir ni echar, todo esto lo ves claro, clarinete según lees un post así y no tienes ni que preguntar que quienes son los malos ni por qué.
Cuidadito con la empatía, que a veces nos hace identificarnos con quien actúa mal. Si se olvida la empatía con las víctimas o se olvida la objetividad, nos convertimos en cualquier cosa.
cc/ #25 #50
#6 eso será en un caso general. En este caso parece un mobbing de libro (ver parte anterior del comentario para más señas). Si suben una web para ponerlo a parir, lo normal es coger un bate de béisbol y romperle los cristales a los coches de cada uno de los agresores. Lo que menos haga de eso, señal de que es un bendito.
Aquí lo más grave que dicen de él es que es un chulo. Pues eso, que todos hemos sido chulos alguna vez, de esa crítica no escapa nadie. No es ni crítica.
Debe ser una persona cojonuda para que, después de sufrir ese "ambientazo", no le pillen en ningún renuncio por haber perdido algún día los papeles.
Felicidades a la empresa que al final se lo haya llevado.
#86 Home meu, no dicen su nombre, es un articulo de opinion sobre gestion de personal en ambientes de desarrollo para identificar dinamicas perniciosas, las cuales se dan y hay que ponerle freno o se vuelven un puto tumor (como parece ser el caso) Si no puedes hablar de dinamicas de trabajo toxicas por si alguien se ofende creo que podemos mandar a la mierda media teoria de gestion de equipos.
Que nunca te toque gestionar una "primma donna" porque creeme que no es agradable, no es recomendable para el equipo y si dejas que se te enquiste vas a tener una situacion como la descrita, la cual, de entrada no es buena ni para el, que tarde o temprano acabará estallando por mucho que no le hubieran largado.
#88 #86 No es agradable lidiar con este arquetipo, ni como gestor de un proyecto, ni como compañero.
De hecho dudo que sea una historia real, pero si que explica como un monton de gente con buenas intenciones, es incapaz de llevar a cabo un proyecto. Hay fallos de libro en el management, en el "Rick", en los compañeros, pero sobre todo en el proyecto.
No se donde leí que uno de los errores más imperdonables en un equipo/proyecto es tener alguien insustituible. Es tentador tener a alguien que sea capaz de sacarte las castañas del fuego en una situación imprevista, pero no se puede dejar que sea la tónica general.
En mi trabajo, he bordeado varias veces convertirme en esa persona. Y lo peor de todo es que el primer sintoma es que todo pasa por tus manos. Eso significa que te crees util, la ostia de bueno, todo son palmaditas en la espalda. Luego vienen los marrones, luego la rutina y la ley no escrita. Los demás pierden el interés en tomar la iniciativa, por lo que te cargas de más trabajo aún. El jefe está encantado porque el trabajo sale adelante... durante un tiempo. A partir de ahí puede reventar por cualquier lado si no se detecta ese problema.
Lo peor de todo es que se llega a esa conclusión cuando es absolutamente evidente e imparable. En mi opinión, la lista de culpables es cerrada, y se puede resumir en:
-Jefes cortoplacistas o con poco caracter.
-Compañeros poco ambiciosos, o con poca implicación.
-Rockstar hipermotivado, que se convierte en un quemado.
-Un proyecto sin una hoja de ruta, que se mueve a merced de los acontecimientos, y que permite que alguien se convierta en la punta de diamante de un proyecto, afilado pero fragil.
#99 sip, puede ser. Pero este no es insustituible, este es alguien a quien los compañeros le hacen el vacío.
Yo esto si lo he visto, no tan exagerado pero del estilo: es bueno, le pulteamos porque si no, nos quita la posibilidad de medrar en la empresa. Lo más alarmante es que quien lo dice, no se da cuenta de lo mala persona que está siendo.
Hay de todo por el mundo.
#1 yo lo llamaría Rick Linus Torvals
Lo que puede que no te cuenten es que esa persona que hasta ahora arreglaba problemas estaba cansada de ver como sus jefes no le hacían ni caso a la hora de solucionar otros problema para que no todo dependiera de el y se apuntaban para si los buenos resultados que esa persona conseguia....es sólo una hipótesis....pero tampoco tan descabellada...además echarle la culpa a el de su propia inoperancia para no arreglar el problema de comunicación mucho antes no dice nada bueno del autor del artículo....
Típica historia. Se tiene a alguien bueno, hay quien tiene celos, se le presiona, se le crítica la reacción a esa presión y se le echa.
Hay empresas que no saben gestionar el talento ni la igualdad de trato.
#4 No has entendido ni una palabra del artículo.
#4 Has leido algo?
#4 No has dado ni al palo.
A mí me pasó en mi último trabajo: llego, y había un par de programas cruciales que los había hecho el programador superstar, un auténtico crack. Me toca a mí asumir el mantenimiento, porque el superstar se iba, y cuando le preguntó con qué framework los ha hecho, que están muy chulos, la respuesta es "con uno que me he programado yo". Silencio incómodo, cuando se va el programador intento mirar el código... y básicamente está todo programado a pelo desde cero. Desde la capa de persistencia hasta las librerías javascript de la parte cliente. Y todo sin documentación alguna, por supuesto.
¿Resultado? Sudores fríos cada vez que aparece un bug o el programa hace algo raro, sangre, sudor y lágrimas para hacer el más mínimo cambio, casi por prueba y error y rezando para que funcione, y apenas 1-2 años después ya se está gastando un pastizal en encargar a alguien externo rehacer los programas desde cero, con tecnologías medio estándar y mantenibles. Moraleja: habrá programadores estrella que hagan el trabajo de dos, pero a veces a largo plazo es mejor pagar a dos programadores normales que te hagan algo mediocre, pero mantenible.
#10 Bueno, a fin de cuentas eso es lo que hizo Steve Jobs con su hardware: "es bueno, funciona de PM, pero si quieres cambios págame a mi o te costará más caro descifrar mi trabajo". Sí, es del género hijoputa, hasta que resulta que el HDP hace legión y le ríen las gracias. Y mientras tanto se asegura el pan.
#11 Si es tu modelo de negocio, pues bien por ti. Pero si haces un código que se supone que tiene que ser mantenible por terceros en el futuro, es una cagada.
Aunque el problema no es tanto del que lo hace, como del jefe que le permite hacer un código inmantenible y basar su negocio en él.
#10 Para mi si un código no es mantenible no es bueno. Un buen programador crea código mantenible. Ese tío sería muy bueno escribiendo líneas pero es un mal programador.
#10
Tengo que discrepar.
Un buen programador no es alguien que sabe hacer cosas complejas de manera compleja, lo es uno que es capaz de hacer cosas complejas de manera fácil y entendible por otros.
#41 En el fondo es lo que he venido a decir: el buen programador es el que hace cosas de forma eficiente y mantenible. Y eso generalmente implica hacerlas de la forma más sencilla posible.
El problema es que el concepto de "buen programador" está muy distorsionado, centrándose en un único factor e ignorando muchos otros igual de importantes (aunque menos glamourosos). Es como si dices que un futbolista es el mejor del mundo porque te hace unos regates cojonudos, pero luego es incapaz de chutar sin mandarla a la grada y tiene una barriga cervecera que si corre 10 metros seguidos se tiene que sentar.
#10 O, idea loca que se me ocurre, tener un programador estrella y un jefe que haga su trabajo y evite las idas de olla al tiempo que aprovecha la genialidad del empleado.
#10 Vamos, que si el codigo no esta hecho con el framework que te gusta es un cristo, malo e inmanejable
Ajam ...
#69 "El equipo", es la extrapolacion de cuando tocaba presentar un trabajo y todo el mundo pasaba menos tu, te comias todo el curro y luego "somos un gran equipo"al terminar, tu quemao y el resto de fiesta.
Puto mr wonderful, scrum y team building de los cojones...
#95 Si lees mi mensaje, el problema no es que no me guste el framework. El problema era que era un framework hecho a medida por una persona para sí mismo, y sin la más mínima documentación.
Me parece estupendo que seas un crack y consideres que no te vale ningún framework existente, y decidas hacerte uno mejor. Pero eso requiere también unos mínimos de documentación. Es mil veces preferible usar un framework mediocre bien documentado, que el mejor framework del mundo que sólo sabe usar su programador. Al menos si pretendes que el programa sea mantenible.
#69 Efectivamente, es lo que he dicho en #9. El programador no es tan culpable como el jefe que le permitió hacer ese tipo de cosas.
He compartido la historia con toda mi oficina y todo el mundo le ha puesto nombre a Rick, todos han puesto a la misma persona y la historia es exacta no siendo una empresa de desarrollo, cambiando el nombre y el tipo de negocio y que no podemos echar a Rick porque es el encargado en resto es clavada.
Llevo muchos años en esto y el problema son los compañeros ruines, da igual si son cracks o mediocres, jefes o subordinados. Los ruines son a los que hay que temer.
#52 Igual es que a largo plazo la empresa no deberia dar por sentado que ese unico empleado va a trabajar como un esclavo, y tal vez deberia solucionar ese problema mucho antes de que surjan las consecuencias...
Como los 7 meses que me he pasado sin ayuda haciendo el trabajo de 2-3, (a pesar de que la empresa me contrato diciendo que estaban buscando 3 o 4 programadores mas) y como sacaba el trabajo adelante nunca ha sido una prioridad el encontrar mas empleados hasta que ha sido tarde.
#45 Totalmente de acuerdo contigo.
Muy interesante esta frase:
It’s sad that Rick descended this far. His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.
Vamos, que tan malo, o peor, que escribir código críptico que no entiende nadie, es que los jefes permitan que suceda.
#33 ¿Y eso que tiene que ver con lo que yo he dicho?
¿Me estás diciendo que en esas 5 primeras compañías de software no usan herramientas de desarrollo estandarizadas, ni tienen guías de estilo de programación, normas unificadas de códigos ni procesos definidos de desarrollo, testeo y paso a producción? Es decir, que cada uno de los programadores de esas empresas hace lo que les sale de las narices, programa a su puta bola y sin ningún criterio unificado porque total, son todos unos cracks en lo suyo.
Hay programadores que se creen que programar es un arte, algo propio de genios inspirados y el 99% es más una cadena de montaje con obreros encajando piezas que están mas o menos estandarizadas.
#14 cadena de montaje con obreros encajando piezas que están mas o menos estandarizadas.
Se ve que no tienes ni idea de lo que estas hablando. Busca el indice S&P500 y mira quienes son las 5 primeras companias mas grandes y a que se dedican.
decir que el software se hace por obreros encajando piezas mas o menos estandarizadas es no tener ni puta idea, cuando es la industria que mas rapido evoluciona, mas rapido crece y donde estan uno de los trabajadores mejores pagados.
Es gracioso que te digan que te coordines cuando el resto sudan de coordinarse
Igual estaba tan amargado porque su esfuerzo y responsabilidad no se recompensaba...
#0 No sé si estás a tiempo de cambiar la categoría. La noticia es del 2017 y no cuadra en actualidad.
Recordaba haberla leído porque tuvimos un caso similar de un tipo que iba de gurú cuando todo lo que hacía era enrevesar las cosas a propósito para que el resto dependieran de el, y me identifico por completo con el artículo porque desde su marcha la velocidad y la calidad del equipo se han multiplicado hasta el punto de que hemos tenido que redefinir la referencia de storypoints dos veces en un año.
Edit
Lo leí hace muchísimo. No voto antigua... porque a ver, sigue en vigor. Pero es antigua.
Pues leyendo se me ha venido a la mente el personaje de Wardog. El típico que como es muy bueno se cree imprescindible y se permite ir de borde con todos.
#82 Es que Scrum para un proyecto con marrones... malo. Y Kanban, para proyectos pesados y con muchos programadores, creo (nunca he trabajado con kanban) que puede ser algo lioso. Al fin y al cabo es algo anárquico.
Aunque no haya una "organización que te cobra cientos de euros o miles por darte un papelito", y reconociendo que es un tanto "casero", es la experiencia probada de cómo mezclar ambos sistemas y hacer que funcione.
También digo que en un equipo de seis o siete personas y un producto que sale desde cero y definido de forma interna, yo no saldría casi nada de Scrum.
Quitaría al vago del Scrum Master, creo que en Scrum.org lo definieron para crear un nuevo puesto de trabajo en el que ellos cobran por repartir títulos oficiales.
El texto es interesante, pero falla en lo esencial. Un programador con talento no escribe código que nadie más entiende.
Sería un programador que echase más horas, que comenzase con partes críticas y que se encargase de hacerlo todo él solo para que pareciera que era indispensable.
Pero no tenían, seguramente, mucho talento. Es como si dijéramos que Ussain Bolt es un gran futbolista porque corre mucho, pero no controla el balón, ni chuta fuerte... Teclear rápido y decirle a todo el mundo "yo lo soluciono" no dice nada. Que todo el mundo le pregunte solo indica que él se lo ha comido y parido y solo él sabe las respuestas
#31 De eso habla. De que era alguien con talento, y por ese motivo se le dejó ir hacia donde el quería. Y no hubo nadie que pusiera freno a la situacion.
En el corto plazo, merece la pena tener a alguien que te saque las castañas del fuego, e inconscientemente se valora ese tipo de empleado porque intrinsecamente es valioso.
Pero a largo plazo, son un cancer, y cuando se hace evidente ya es demasiado tarde, y lo major es amputar.
Es algo tan comun en el sector, que parece la norma. Trabajar en equipo es MUY dificil en la programación.
#52 Sigo negando la mayor. Tener talento para ser programador es otra cosa, e incluye escribir código legible.
De la misma forma, trabajar en equipo en desarrollo es muy sencillo. Con cualquier versión casera medio normal de las metodologías ágiles se trabaja con fluidez.
Lo único que hace falta es vigilar los egos de los trabajadores ególatras, pero eso pasa en cualquier entorno laboral.
#63 "Con cualquier versión casera medio normal de las metodologías ágiles se trabaja con fluidez"
Ese es el mayor error de la mayoria de empresas , el hacer "versiones caseras" (que se traduce en hacer un minimo de 30 minutos de reunion cada puta mañana para que los que tienen poco trabajo se entretengan).
#72 Es como todo, las versiones caseras pueden ser adaptaciones a la realidad del equipo de trabajo o ser un estropicio.
Nosotros somos un equipo de desarrollo de tres personas, pero pese a ser el mínimo (de 3 a 9 para Scrum), no hacemos sprints porque estimamos que perdemos el tiempo.
Si llevas Scrum.org a rajatabla, tienes sprints de una a cuatro semanas. Si es de una semana, tienes tres reuniones semanales (planning, restroespective, revision), más el backlog, más el product backlog. Si es de tres semanas un error grave en producción descubierto antes del sprint planning se queda colgando tres semanas sin que nadie lo arregle.
En fin, todo con mesura y cariño.
#81 Hace un año tuve que hacer de Lead en un equipo de 2 () y estuve investigando el metodo Scrumban (una mezcla de Scrum y Kanban). La verdad es que me parecio muy interesante pero casi ninguna empresa lo conoce.
A programar en ensamblador sin macros os ponia yo ... (solo por joder y ver el mundo arder)
O sea, solucionaron los problemas harcodeando y comprando frameworks que añaden mierda innecesaria a los productos para hacer cosas que podría hacerse de forma mucho más óptima con componentes a medida. Perfecto.