"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
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.
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.
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.
Hay empresas que no saben gestionar el talento ni la igualdad de trato.
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.
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.
Y meu... que gran cagada.
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.
¿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.
1,tu que sabrás que programas en SAP.
Señoría,no hay mas preguntas.
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.
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
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.
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.
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
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.
¿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.
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.
ojalá
Como se nota que no has estudiado en Aravaca
"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.
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.
CC #54
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.
Porque sus mierdas te las vas a acabar comiendo tú y encima serán tu culpa
Y cuanto mas te acercas a software crítico la cosa cambia mas y mas.
"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.
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.
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.
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.
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.
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!!!
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.
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.
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).
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.
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?
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.
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.
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.
Trabajamos en sectores diferentes, con herramientas y metodología diferente, igual en tu sector tienes razón, en el mío nop
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.
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.
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)
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.
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.
Amos que si que tienes razon que no suele ser lo habitual, pero haberlo haylo.
#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...
Yo soy de los de violencia gratuita, extrema y sadica...
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.
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.