EDICIóN GENERAL
78 meneos
2357 clics
Este envío tiene varios votos negativos. Asegúrate antes de menear

Despedimos a nuestro trabajador con más talento y fue lo mejor que hicimos [ENG]

"Nunca entenderéis nada de lo que he creado. Soy el puto Albert Einstein y todos vosotros sois monos escarbando en mierda." Eso fue lo que declaró delante del equipo de diseño de producto, desarrolladores, dirección y cliente antes del lanzamiento. Fue nuestro mejor y mayor programador, le llamaremos "Rick" como en la serie de animación.

| etiquetas: programación , talento , equipo , tóxico
Comentarios destacados:                  
#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.
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…   » ver todo el comentario
#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. :troll:
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 xD
#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 xD
#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 xD
#37 cuando el frontend supera el scroll de la consola del navegador,entonces solo entonces,sabes que vas a morir.
#19 Cuánta crueldad... :troll:
#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 :-S 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" :troll:
#93 No no, yo soy solo un cabron violento que se ve obligad por las circunstancias a no poder repartir ostias a mano abierta xD
#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…   » ver todo el comentario
#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
xD
#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.

:troll:
#48 ¿Entonces Robert de Niro era un controlador? :troll:
#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…   » ver todo el comentario
#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 :troll:
#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 xD ) 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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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 xD 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 xD
#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.
Igual estaba tan amargado porque su esfuerzo y responsabilidad no se recompensaba...
Edit
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.
Lo leí hace muchísimo. No voto antigua... porque a ver, sigue en vigor. Pero es antigua.
#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…   » ver todo el comentario
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 (:shit:) 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) :troll: :troll: :troll:
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.
«12
comentarios cerrados

menéame