¿Es cierto que algunos desarrolladores de software débiles siempre se esconden en el equipo y no aportan nada sino ser atrapados?

Sí, puede y sucede. Sucede en la mayoría de los trabajos, no solo en el desarrollo. La razón por la que parecen no ser capturados varía, pero muchas veces se trata de plazos.

Si tengo un equipo de 5 miembros y encuentro que uno me da un producto de trabajo tan bajo como 10% efectivo, eso significa que en una semana tengo 174 horas de trabajo efectivo. Si quiero contratar a alguien nuevo, tengo que despedir a la persona en cuestión, perdiendo esas 4 horas durante el tiempo que sea necesario para encontrar al nuevo miembro del equipo, Y mientras busco, probablemente pierda otro 5% ya que el resto del equipo está llamado a revisar candidatos y participar en entrevistas. Luego, cuando encuentre un nuevo miembro del equipo, tendrán que ser entrenados y actualizados en las cosas, lo que significa una pérdida de otras 40 horas más o menos de trabajo, mientras que los miembros del equipo ayudan a configurar los sistemas del nuevo miembro y les ayudan a ponerse al día. velocidad. Además, el primer mes de una nueva persona será perjudicial, sin importar cuán buenos sean (y, a veces, cuanto mejor sean, más perturbará el flujo del equipo a medida que empiecen a adivinar las decisiones anteriores, etc.). Por lo tanto, debe asumir una pérdida de productividad en el equipo en su conjunto durante ese período, tal vez hasta un 50%, dependiendo de lo disruptiva que sea la nueva persona. Entonces, finalmente, realmente no sabes cuánta mejora obtendrás realmente, es posible que termines justo donde estabas y pierdas un montón de tiempo de desarrollo.

Ahora aquí es donde entran las líneas de tiempo. Si las fechas límite y las líneas de tiempo no fueran un problema, sería inteligente y fácil reemplazar a las personas porque eventualmente terminará con una mayor productividad. Pero desafortunadamente 200 horas / semana en 2 meses a menudo es menos útil que esas 30 horas / semana ahora porque necesita obtener algo para retener la participación en el mercado, para hacer una venta o para mantener el flujo de ingresos. Por lo tanto, todo depende de una gran cantidad de factores de lo que está sucediendo. Eventualmente, si la persona nunca mejora, ocurrirá una pausa y tendrá la oportunidad de reemplazar a la persona, pero podría llevar un tiempo.

Sí. He visto gerentes con estas personas en sus equipos y, aunque algunas respuestas ya destacaron el argumento de las diferentes habilidades, dudo que sea realmente por eso que el gerente los mantiene.

Muchos optan por no tomar medidas porque es difícil poner a un empleado en un plan de mejora del rendimiento. Idealmente, solo le haría eso a los empleados más incompetentes y desmotivados, porque el proceso lleva mucho tiempo para los gerentes y es tan estresante para el empleado, de lo contrario, probablemente no valga la pena.

He visto a gerentes muy políticos mantener bajo rendimiento porque a menudo esas personas son leales a ese gerente. El gerente también puede usar a los jugadores de bajo rendimiento para proteger a sus jugadores estrella si alguna vez son necesarios los despidos.

Como gerente, no apruebo ninguna de estas tácticas de construcción de imperios. Siento que los equipos deben mantenerse pequeños, la responsabilidad alta y la tolerancia de la incompetencia baja.

Es cierto que algunos equipos son “equipos solo de nombre” y no apoyan ni asesoran activamente a otros compañeros de equipo.

Es decir, ellos:

• centrarse en el logro individual, no en los resultados del equipo
• actuar como individuos, en lugar de colaborar de manera efectiva
• carecen del coraje y las habilidades para tener “conversaciones difíciles”
• ver a los compañeros de equipo como rivales más que colegas
• esperar a que otras personas se ocupen de los problemas, en lugar de mostrar liderazgo
• carecen de entrenamiento, mentoría y habilidades de liderazgo.

Eso es a menudo el resultado de la cultura del equipo.

Los equipos de alto rendimiento pueden aprovechar sus diversas habilidades para lograr más juntos de lo que podrían trabajar de forma semi independiente en el mismo trabajo.

Aprovechan sus fortalezas para apoyar las debilidades de los demás, al tiempo que aumentan las habilidades de los demás.

Tienen una cultura de “organización de aprendizaje” y buscan mejorar continuamente.

TLDR; Sí, pero tiende a reflejar más la falta de una cultura de equipo colaborativo de alto rendimiento y un liderazgo débil que el individuo.

Ellos no.

He tenido un par de desarrolladores débiles en mi equipo a lo largo de mi carrera, y todos los gerentes sabían que eran débiles. Lo que más me sorprende es que ninguno de ellos fue despedido.

Desde la perspectiva de un gerente, es una buena práctica tratar de ayudar al miembro del equipo a mejorar y simplemente despedirlo en caso de que no mejore algunos meses después de comenzar este proceso.

Lo que vi fue que los gerentes no hicieron absolutamente nada para ayudar al desarrollador, y al mismo tiempo nunca despidieron a estas personas.

Tal vez esto sea cultural, y los gerentes en mi país (Brasil) tienen dificultades para despedir a los artistas de bajo rendimiento.

También en algunos casos estas personas valen sus salarios. Hay trabajos que no requieren una gran experiencia, y los trabajadores de bajo rendimiento son muy bienvenidos debido a sus expectativas salariales más bajas.

Si esto le está sucediendo en este momento, primero intente ayudar a esta persona a mejorar. Si el desarrollador no muestra interés en aprender, repórtelo a su jefe. Si no sucede nada, entonces la empresa para la que trabaja realmente no se preocupa por mantener a los buenos empleados, y es posible que desee irse a una empresa que se toma en serio la contratación de personas talentosas.

Esto es casi imposible en startups y agencias más pequeñas, pero bastante factible en grandes corporaciones empresariales.

Aflojar y ocultar con éxito la incompetencia es posible cuando:

• Los procesos son lentos: falta de revisiones de rendimiento, sprints de 6 meses, toneladas de tiempo dedicado a I + D, validación y pruebas.
• Los equipos son grandes: docenas de personas que trabajan en el mismo proyecto.
• Varias capas de gestión. Ayuda con revisiones mixtas y transmitiendo las habilidades o informes requeridos a cada miembro de una manera diferente.
• La gerencia asigna tareas poco claras y vagas: la capacidad de pedir ayuda en todo momento (sin necesidad), lo que indica el progreso sin hacer eso.
• Algunas estrellas de rock autónomas están ansiosas por resolver todos y cada uno de los problemas y abordar una cantidad insuperable de desafíos.

Un desarrollador débil puede esquivar fácilmente una bala pidiendo ayuda a los miembros del equipo, publicando comentarios de aclaración todo el tiempo, informando sobre un progreso no cuantificable, lo que indica el éxito con la I + D que no es aplicable en el trabajo y similares.

Podría suceder fácilmente con una gestión deficiente , falta de pautas de eficiencia, disposición del equipo de gestión para seguir invirtiendo en su personal a toda costa.

Algunas corporaciones se centran extremadamente en la retención, el desarrollo personal y profesional, el liderazgo de talento. Harían todo lo posible para retener a su personal y recibir críticas entusiastas en Glassdoor (que también podría ser contraproducente).

Algunos de esos desarrolladores débiles abordan diferentes actividades que están fuera de la descripción de su trabajo pero que ayudan a la organización. Piense en la documentación, enviando comentarios sinceros, solicitando cursos de capacitación internos que beneficien a todo el equipo. Al apoyar al negocio en diferentes áreas, podrían quedarse por un tiempo a pesar de sus habilidades mediocres.

Dicho esto, es ciertamente posible, pero rara vez sostenible . Las empresas se quedan sin dinero, cambian la gestión, subcontratan a un lugar más barato o reducen su plantilla mientras se preparan para una salida.

Claro, algunas personas exitosamente saltan al trabajo varias veces sin poner demasiado esfuerzo en el desarrollo del aprendizaje. Pero es un juego y puede dejarte desempleado para siempre.

Sucede. Lo sé porque, por ahora, soy uno de ellos.

Soy parte de dos proyectos completamente no relacionados, y en uno de ellos, en un equipo de tres desarrolladores (eso no es exactamente ingeniería de software, utilizamos un lenguaje de muy alto nivel en el que los conceptos de programación más básicos, como los bucles, están completamente ocultos .), Soy, con mucho, el menos eficiente: mi producción es tal vez la mitad que mis colegas, y mi trabajo rara vez está libre de errores (Una vez más, eso es “diferente” que la mayoría de los proyectos: los errores son absolutamente inevitables aquí, ya que nosotros se trata de lenguajes naturales. Pero hay un umbral de precisión que se debe eliminar en cada sprint).

¿Cómo me escondo? Yo no. Estoy aprendiendo, lentamente, pero lo estoy, y cada vez que me doy cuenta de que llegaré tarde al sprint actual, le advierto al gerente al menos dos semanas antes del final para que podamos adaptarnos. Y para ofrecer una compensación por la calidad de mi trabajo, aprovecho todas las oportunidades para otras tareas, como las secuencias de comandos (Literalmente, lo único en lo que no fui autodidacta) o el seguimiento de errores.

Esto es cierto para muchos grupos de profesionales, desde trabajadores de la construcción hasta ingenieros de software e incluso médicos. Pero siempre tenga en cuenta que un buen decelopers no es todo lo que un equipo necesita. Especialmente en TI hay un mayor porcentaje de personas que encuentran la interacción social difícil y desagradable, pero los miembros del equipo deben interactuar, de lo contrario no hay equipo. Ingrese al desarrollador socialmente dotado. Puede que no sean los más hábiles o experimentados, pero tener una pista sobre el código y tener talento para las personas hacen que el equipo logre lo que ninguno de sus miembros podría lograr solo. ¿Cuál es el valor de dicha persona para la empresa? Nadie lo sabe, porque las compañías aún no han encontrado una manera de iterar a esas personas y de valorar lo que hacen.

La respuesta a su pregunta depende del sistema y la cultura corporativa en el lugar.

En mi tiempo en Microsoft a mediados de la década de 2000, hay muchas maneras de monitorear las contribuciones, y mencionaré dos cosas fuera de mi cabeza.

Primero, cada trimestre, establece una serie de objetivos (cuantificables) para lograr durante la reunión regular uno a uno con su gerente. Y esto es seguido por una revisión de rendimiento para ver si realmente completa lo que se propuso hacer inicialmente.

En segundo lugar, también tenemos nuestro sistema de administración de código interno SourceDepot (antes de la transición a TFS y luego a Git), y el historial de verificación dice mucho sobre qué características aporta cada desarrollador y qué errores se corrigen, etc.

Ciertamente, durante su reunión uno a uno, su gerente debe tener una idea muy clara de cuánto progreso ha realizado, etc. E incluso sin reunirse, el historial de revisiones y las revisiones de código también proporcionarán muchas ideas.

Durante los primeros treinta años, una y otra vez, el jefe me puso a cargo. Mi entrenamiento inicial en UC-Irvine enfatizó el trabajo en equipo. Como consecuencia, encontré métodos para ayudar a cada miembro a contribuir.

Para un chico mayor, dividí sus tareas en pequeños segmentos. Algunos de los otros miembros del equipo se rieron al darse cuenta de que el viejo se había convertido en la exportación del “informe menor”. También le fue bien en la minería de datos simple. Su salud lo obligó a retirarse.

En una gran agencia gubernamental, treinta y tres programadores me informaron. La mayoría eran contratistas. Absurdo. En la primera semana, entrevisté a la mayoría de ellos y recopilé copias de su software. Al final de la segunda semana, tenía copias de cada una.

Mi jefe sacudió la cabeza infelizmente cuando le mostré comparaciones de software desde la primera semana y las siguientes. Cerré la puerta de golpe en una investigación no dirigida. En la semana seis, varios programadores no productores presentaron una queja que yo administré de manera micro. Algunos otros renunciaron. El gerente de recursos humanos con sus amables palabras persuadió más a renunciar; sofocó el agravio sofocado y sonrió a sabiendas. La docena restante se desempeñó increíblemente bien. Progreso semanal observable.

También teníamos a todos los programadores trabajando en un proyecto o tarea importante de aproximadamente treinta horas estimadas y en al menos una pequeña tarea. Si el programador se quedara atascado por más de quince minutos de la tarea principal, pasaría a la menor. Si ambas tareas se estancaran, entonces él podría preguntarme a mí u otro programador. Esto creó tramos de intensa concentración, pero también proporcionó oportunidades para los esfuerzos del equipo.

Otras veces, comparé las habilidades de los programadores con las ofertas de trabajo en otras compañías. Llamé a las otras compañías. Mis programadores se sorprendieron de mis recomendaciones para lanzar empresas, pero todos lo hicieron.

Con conexiones con profesionales en varias universidades, anuncié “programador necesario: experiencia de cero a cinco años”. Como resultado, regularmente contrataba programadores geniales que necesitaban ese primer trabajo. En su universidad, al menos un profesor dio una gran recomendación. Algunos renunciaron en unos meses. A lo largo de los treinta años, unos veinte crecieron mensualmente y después de tres años, nos dimos la mano porque se habían ido a un trabajo bien pagado.

Me protegí a mí y a mis empleadores al darles pruebas de ubicación. Diez preguntas sobre un sistema operativo común que eligen los solicitantes. Como HP-UX, Linux, RedHat, MS-DOS. Diez preguntas sobre un idioma web de su elección. Diez preguntas sobre C, C ++, COBOL, Java u otro lenguaje. Un proyecto de ejemplo de su pasado. Incluso los mejores consultores de HP tomaron los exámenes y, por lo tanto, aumentaron mi cartera de exámenes.

La buena contratación disminuye los malos disparos. Mi vicepresidente de un gran minorista que cotiza en bolsa estaba impaciente por entrevistar a treinta y contratar tal vez uno. Más tarde me consiguió trabajo donde lo único que hice fue entrevistarme.

Definitivamente, hay desarrolladores cada vez más débiles y, sí, si está un poco por debajo del promedio, es posible que pueda encontrar un buen equipo y ser transportado un poco, y posiblemente no tenga muchas consecuencias, particularmente en un trabajo discreto .

Pero en casi todos los trabajos de desarrollo de software, su trabajo es claramente identificable como el suyo en el futuro porque todo el trabajo que realiza está comprometido en un sistema de control de código fuente (control de versiones, control de fuente). Por lo tanto, es casi imposible en un trabajo de desarrollo moderno contribuir “nada” sin ser atrapado, sería muy obvio que no está contribuyendo a nadie a quien le importara mirar.

Entonces estoy respondiendo esto desde una perspectiva de novato puro. Soy un estudiante de primer año de CS en mi segundo semestre y solo he estado programando por menos de un año. Solo sé Java y HTML (CSS también) hasta ahora.

Este semestre he tenido el ‘placer’ de trabajar en grupo para una clase que nos permitió ver el desarrollo de software / aplicaciones desde todos los aspectos, excepto la programación. Creamos una aplicación y tenemos propuestas de proyectos, estudios, etc. Me encantó la clase porque representa muchas conversaciones de “¿por qué a la gente le gusta esto?”. Por decir lo menos, mucha gente estaba en el porque era un curso recomendado. Al principio yo también, pero me volví extremadamente involucrado en la clase.

Nos dividieron en grupos basados ​​en nuestras ‘personalidades’ y, para ser sincero, mi grupo parece estar formado por todos los que no parecen encajar en ningún otro lugar (yo incluido yo). Al principio, mis miembros parecían al menos un poco interesados, todos haciendo el mismo trabajo, pero después de un mes las cosas cambiaron. Todavía en la clase, tengo que hacer que otros miembros trabajen y administrar a todos los demás. Literalmente me encuentro haciendo tareas completas, o dividiendo el trabajo y teniendo que asegurarme de que todos hagan su parte. Por supuesto, lo aliento, ya que no tengo problemas para hacer el trabajo, es solo que no me gusta creer que puedo confiar en que alguien haga el trabajo solo para que venga a mí el día de vencimiento y pregunte “¿cuál era mi sección nuevamente? ”

Sin embargo, hay un miembro en particular, tengo que presionarlo para que haga la menor cantidad de trabajo y, aun así, definitivamente no está a la altura. Por ejemplo, este miembro en particular tenía 6 preguntas para responder y tenía 2 semanas para hacerlo. El día que vence, pregunta sobre la sección que se supone que debe hacer (esta vez todos eligieron su sección, así que me molestó aún más). Le cuento la sección y luego me envía un documento con sus “respuestas”. Eran patéticos. En primer lugar, solo respondió 3, y los tres que respondió ni siquiera respondieron las preguntas. ¿Cómo puedes responder una pregunta con “explicar” en una oración?

No dije nada porque vencía pronto y, sinceramente, no confiaba en él. La próxima vez que intentó salir del trabajo, lo llamé. Probó lo bueno “hicimos esto en una tarea anterior, así que simplemente copie y pegue”. Lo importante es que nos hacen preguntas similares, cada tarea es ayudarnos a crecer y desarrollar nuestra idea, no mantenerla exactamente igual. el principio. Le dije que si copiaba y pasaba no estaría haciendo nada y eso no sería justo. Así que le di el trabajo de antes para basar su trabajo y agregó un par de oraciones más, pero no las leí. En realidad, los leí un poco y era evidente que no tenía idea de lo que estaba pasando con las actualizaciones que teníamos.

Por lo tanto, este niño apenas se ha presentado a la clase y no contribuye a las discusiones en absoluto o de manera positiva. Puede que no seamos desarrolladores reales, pero él realmente se esconde en este grupo y solo funciona cuando realmente lo presiono.

Los gerentes los despedirán SOLAMENTE si afecta su presupuesto.

Trabajé en esta horrible compañía llamada ParkWestGallery en Southfield MI. Nos contrataron a 3 de nosotros al mismo tiempo. En un par de días noté que los otros 2 nunca habían codificado antes y fingieron sus currículums con 8 años de experiencia.

Después de un mes le dije al gerente lo que estaba pasando. El imbécil me dijo que era mi percepción y comenzó a hacerme la vida imposible cada vez que tenía la oportunidad. Pasé los próximos meses arreglando su código horrible y finalmente me fui. Justo después de que me fui, con unos pocos meses ambos fueron despedidos.

Supongo que finalmente comenzó a afectar su balance final cuando una persona no estaba recogiendo estos falsos desarrolladores indios.

¿Quién dice que no están siendo atrapados? ¿Y qué significa “ser atrapado” realmente? ¿Disparo?

Según mi experiencia, trabajando en una gran empresa, hay un proceso pesado que un gerente debe renunciar para despedir a alguien. Demasiado trabajo. Y al final puede que no tenga éxito. La mayoría de los gerentes solo quieren que el empleado “entienda” y se vaya. Pero siendo tan débiles, nunca se irán, a menos que sean forzados a hacerlo. Por lo tanto, es bastante conveniente para ellos simplemente “esconderse”. Lo que generalmente termina sucediendo es que se dejan llevar por el despido anual de la compañía y los gerentes colocarán sus nombres en la parte superior de la lista.

En una empresa más pequeña, especialmente en el inicio, el proceso es muy rápido y esos empleados no pueden ocultarse en absoluto.

He experimentado ambos lados como gerente y esa es la razón principal por la que estoy trabajando para una startup …

No, esto es una tontería. Es el material de las comedias de televisión.

La única forma en que esto podría suceder es si el desarrollador de software débil fuera el gerente, y él no fuera totalmente consciente de cuánto trabajo estaba realizando cada desarrollador. Quiero decir, cuánto tiempo tomaría notar que un desarrollador no estaba registrando ningún trabajo , ¿no estaba completando ninguna tarea cada sprint? A menos que el desarrollador fuera el sobrino del CEO, estaría en el radar. Podría llevar algunas semanas pasar por los aros de RR. HH., Pero se habría ido.

Es cierto, en mi experiencia, una vez estuve trabajando como desarrollador de software, mientras que el desarrollador de software Sr no hacía nada, era inocente de cómo funcionan las cosas, así que fui al CEO para preguntarle cuál es la responsabilidad del desarrollador de software Sr. en la empresa, por qué trabajo todo el tiempo y me golpeo la cabeza para resolver problemas técnicos mientras él descansa y recibe más salario que yo.

El CEO respondió: “Es un antiguo miembro que permaneció en la empresa durante 5 años cuando esta empresa se encontraba en la etapa inicial, solo por respeto tiene derecho con este Desarrollador de Software Sr., no importa cuánto trabaje, se mantendrá un paso por delante de tú”

Todavía creo que si se le pide al ingeniero de software Sr individualmente que trabaje en algo por su cuenta, no lo hará. se esconde y aprovecha al máximo la mentalidad del CEO.

Depende completamente del equipo.

Trabajé en un equipo con un gerente no técnico y ciertamente había una persona en el equipo que hacía muy poco trabajo, y el trabajo que producían era increíblemente pobre y solo creaba una carga para el resto de nosotros.

Por supuesto, cualquier gerente medio decente debe saber al menos verificar git para ver si se está produciendo trabajo, y no tomar esto como que los desarrolladores deben ser juzgados por la cantidad de líneas de código escritas, pero cualquiera que no cometa nada día a día probablemente debería investigarse al menos.

En mi caso, dudo que el gerente en cuestión pueda incluso deletrear “git”, y mucho menos explicar lo que hizo o saber cómo acceder a él.

Sé dónde se encuentran las fortalezas y debilidades relativas de mis desarrolladores. Puedo ver cuánto trabajo están haciendo y la naturaleza de lo que están haciendo porque lo entiendo. Por supuesto, tengo un interés personal en su productividad porque es mi empresa.

También creo que vale la pena mencionar que su pregunta no solo se aplica a los desarrolladores de software. Es lo mismo en muchos trabajos.

Ellos no. En un buen equipo, tenemos una combinación de fuerza, ambición y experiencia. Todos sabemos quién es quién, y los desarrolladores débiles reciben las partes más simples y menos críticas del sistema. Mientras eventualmente trabajen, todo está bien. Si se convierte en un cuello de botella, una persona más fuerte intervendrá y lo arreglará.

Mientras un desarrollador débil pueda lidiar con el hecho de que un desarrollador fuerte con el mismo título puede ganar 4 veces más de lo que es, no hay razón para esconderse en absoluto.

Esto siempre es cierto y no solo para los desarrolladores de software, sino para todos los puestos. Administro una gran organización y muchos desarrolladores de software. Lo bueno de los desarrolladores de software, que no tienes para cada puesto (pero muchos sí) es que hay indicaciones claras de lo bueno que es alguien. Puedo ver cuántos errores introducen en su código, cuánto código produjeron (agregaron o eliminaron), cuántos rechazos recibieron en sus revisiones de códigos y, si realmente quiero, puedo ver qué tan bien fue diseñado, documentado y escrito. Tener tantos datos sobre cada desarrollador permite que cada administrador de desarrollo decente tome la decisión correcta cuando se trata de bonos, promociones o despidos. Creo que en muchos casos donde los gerentes no son muy buenos, muchos de esos puntos de datos se ignoran y esos gerentes prefieren las conexiones personales.

No conmigo. Sé exactamente quién en mis equipos está contribuyendo más / menos, siempre lo he hecho. Si alguien no tiene una contribución significativa que hacer, trato de encontrarle otro equipo o rol que funcione mejor. Si no, es mejor separarse. Todos los que trabajan para mí tienen fortalezas y debilidades y la mayoría de las deficiencias, aparte de una actitud despreocupada y de mierda, pueden mejorarse de alguna manera con esfuerzo, pero es probable que alguien que no está contribuyendo y no está mejorando esté tomando mucho de mi esfuerzo. . Si paso tanto tiempo haciendo que alguien haga su trabajo como ellos, entonces bien podría estar haciendo su trabajo yo mismo y eso no tiene sentido seguir haciéndolo.