¿Debería obligar a un desarrollador más lento a cambiar de herramienta para intentar aumentar su velocidad?

Tengo un desarrollador en mi equipo que, si bien entrega un código de buena calidad, es significativamente más lento que los demás desarrolladores de mi equipo. Esto está causando un cuello de botella bastante serio que estoy tratando de encontrar una manera de resolver. En el mediano a largo plazo, hacer que el equipo sea multifuncional permitirá que otros miembros del equipo ayuden a aumentar la velocidad, pero estoy buscando cualquier opción que pueda para aumentar la producción de este desarrollador en particular (especialmente porque el proyecto está en riesgo de sobrepasar el presupuesto).

A este desarrollador en particular todavía le gusta codificar "vieja escuela". Es decir, utiliza un editor de texto para la codificación, la línea de comandos para cada situación posible y, si tuviera la oportunidad de quitar el mouse y cualquier ayuda visual, lo haría. Es explícitamente claro: no quieren hacer nada más que codificar, preferiblemente donde no tengan exposición a otros humanos, y preferiblemente en casa. Absolutamente ninguna reunión, ninguna discusión, él quiere las tareas que deben hacerse y completarlas por sí mismo. Tratar de introducir Agile va a ser un desafío. No tiene muchas otras responsabilidades, el 95% de su trabajo es código.

Ahora bien, no estoy en contra de que los desarrolladores se nieguen a usar interfaces, mouse e IDE si quieren complicar sus propias vidas (personalmente, creo que es solo un movimiento de presumir y reduce significativamente el tiempo de desarrollo en mi opinión), pero cuando la velocidad es bajo par, estoy viendo esto como una de las opciones para aumentar la producción.

Entonces, la pregunta es, ¿es justo y está dentro de mis competencias pedirle al desarrollador que cambie a un IDE para mejorar la velocidad? En mi experiencia, esto tiene una mejora drástica en el tiempo para completar una tarea, pero siento que lo arrinconaría y le quitaría algo que realmente disfruta, lo que no ayudará con la motivación.

Para aquellos que dicen "¡da más flexibilidad/poder!", entiendo este punto, y la línea de comando siempre está ahí el 2% del tiempo que la necesitas. El resto del tiempo, los IDE y las interfaces visuales se diseñaron por una razón: velocidad y facilidad de uso. No lo compro.

Editar: Para mayor claridad, soy un nuevo miembro del equipo, contratado como gerente de proyecto, pero también soy un ex desarrollador líder que tiene una experiencia significativamente mayor que los otros desarrolladores del equipo. Me han dado carta blanca para tomar decisiones arquitectónicas y de desarrollo para recuperar este proyecto en particular que está en serios problemas y es vital para el éxito de la empresa.

Edit2: una sugerencia común aquí es preguntarle al desarrollador qué cree que ayudará a mejorar su velocidad. Ya lo he hecho varias veces, pero no se recibe ninguna respuesta útil: "Lo pensaré", lo cual no sucede. Esa es parte de la razón por la que estoy buscando rutas relativamente inusuales para ver si puedo aumentar la productividad de otras maneras.

Edit3: Está claro que toda la discusión sobre IDE/CLI no se puede resolver; ambos lados tienen sus puntos de vista, y como OSX/Windows, o Python/PHP o... no hay una forma correcta o incorrecta. Si quiere que usted diga sobre esto, diríjase a esta discusión para continuar hablando con las paredes de ladrillo. La pregunta no era si los IDE son mejores que las CLI, sino si puedo pedirle a este desarrollador que pruebe algo nuevo para ver si afecta la velocidad. En última instancia, los desarrolladores pueden codificar con tarjetas perforadas o en Minecraft si lo desean, siempre que la velocidad esté ahí . Tenga en cuenta que volverse eficiente con CLI tiene una curva de aprendizaje mucho más larga y más difícil que los IDE, y es posible que esa sea la situación aquí.

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
¿Con qué frecuencia necesita revisar su código debido a problemas de calidad en comparación con otros miembros del equipo? ¿Es menos?
Ya se han movido decenas de comentarios al chat . Si no está solicitando una aclaración del OP, comente allí o únase a The Workplace Chat en todo el sitio . OP: edite las respuestas a los comentarios útiles en su pregunta en lugar de mantener la discusión.
Cambiar de herramienta también tiene un costo. Si logra que el desarrollador cambie, recuerde que probablemente dañará su productividad a corto plazo, independientemente del resultado a largo plazo.
Tenga en cuenta que está asumiendo una relación entre el entorno de desarrollo y la velocidad. Este podría ser el caso, pero también podría no ser el caso.
"La pregunta no era si los IDE son mejores que las CLI, sino si puedo pedirle a este desarrollador que pruebe algo nuevo para ver si afecta la velocidad". - No, mira de nuevo el título de la pregunta. "Forzar" y "pedir" tienen dos connotaciones bastante diferentes.
¿Qué has hecho con tu equipo hasta ahora? ¿Se ha sentado con cada uno de ellos y discutido de qué eran inicialmente responsables? ¿Problemas/obstáculos que han tenido? ¿Cómo planean seguir adelante? ¿Establecer sus propias expectativas? ¿Reafirmaron plazos y entregables?
@dKen El marco de la discusión está en cuestión. "Fuerza" es demasiado fuerte y demasiado presuntuoso, incluso si tiene razón acerca de sus ideas para aumentar la productividad. Trate de mostrar algo de humildad cuando se acerque a este desarrollador.
No todos los puntos de la historia son iguales, no solo mire su velocidad, mire el trabajo que ha producido, si aborda los problemas que los otros desarrolladores evitan. ¿Pasa mucho de su tiempo apoyando a sus colegas además de hacer su propio trabajo? estas son cosas que deben ser consideradas.
Ofrezca a su empleado un compromiso. Ofréceles una semana de trabajo desde casa si aceptan una semana de trabajo con un IDE. Entonces puedes medir ambas semanas y comparar. ¿Quizás trabajan más rápido y durante más tiempo en casa? Solo tenga en cuenta que hay un período de aprendizaje para nuevas herramientas.
@Jasper Ninguna persona racional o sensata puede argumentar que el entorno de desarrollo no afecta la velocidad. Sugerir lo contrario es pura locura. ¿Es esta la causa aquí? No estoy seguro, pero es una posibilidad al 100 % y me pregunto si debería investigarlo más a fondo (pista: no, no debería. Hay muchas otras cosas que probar primero, como modificar mi estilo de gestión). ).
@dKen Estoy trabajando principalmente con herramientas CLI y soy el más rápido de mi equipo. El entorno de desarrollo seguramente afecta la velocidad, en mi caso, los IDE me ralentizan.
Más allá de todos los argumentos sobre las virtudes de los IDE, esta pregunta me entristece mucho. Ilustra una tendencia negativa que he visto en los últimos años y Agile parece alentarla. Hay muchas cosas que deben tenerse en cuenta para evaluar la utilidad de un desarrollador de software más allá de la velocidad de desarrollo: conocimiento de las herramientas, el sistema operativo, el producto, la capacidad de diseñar y analizar código existente, habilidades de depuración, etc. Alguien podría ser un un poco más lento en la programación, pero tiene un conocimiento enciclopédico del lenguaje que se utiliza. No quieres perder a esa persona.
Sugeriría usar la redacción " requerir " en lugar de " forzar " o " pedir ".
Las declaraciones generales de la forma "Ninguna persona racional o sensata..." son ideológicas, no racionales o sensatas.
"Tenga en cuenta que volverse eficiente con CLI tiene una curva de aprendizaje mucho más larga y más difícil que la de los IDE" ¿Cómo puede hablar en nombre de toda la humanidad?
Sus dos preguntas en esta pila se refieren a su interacción con los humanos. Ha declarado que su función tiene "Carte Blanche", pero, sin embargo, no es gerente ni parte del personal de recursos humanos. ¿Ha considerado centrarse en mejorar su conjunto de habilidades sociales en el lugar de trabajo? Recuerde que la edad, el origen social y las normas culturales afectan el desempeño de todos , incluido el suyo.

Respuestas (14)

La gerencia necesita establecer metas medibles.

Luego deben confirmar que el desarrollador está alcanzando esos objetivos. Si no es así, deben tomar medidas.

Si enfrenta problemas relacionados con esto y no es el gerente de este empleado, concéntrese en los problemas de velocidad cuando hable con su jefe. Si usted es el gerente, debe tener más claras las expectativas.

El resto del tiempo, los IDE y las interfaces visuales se diseñaron por una razón: velocidad y facilidad de uso. No lo compro.

No discuta sobre el enfoque de "herramientas" como lo ha hecho aquí. Parece mezquino y, en última instancia, no tiene sentido: algunos de los mejores programadores que conozco aman/juran por vim y son más productivos usando vim de lo que yo seré jamás. El punto no son las herramientas, el punto es la productividad general.

Cada vez que le mencione esto a un gerente, seguramente hará que sea menos probable que tome medidas.

Centrarse en las herramientas garantizará que no pueda convencer ni a este empleado ni a la gerencia para que tomen medidas, porque es una acusación insignificante y, en última instancia, irrelevante. Debe concentrarse en los resultados (o la falta de resultados).

Solo para mayor claridad, soy el gerente, por lo que parece que es mi desafío descubrirlo. En última instancia, respondió a mi pregunta: "¿Debería impulsar un cambio de herramienta?", Así que voy a tomar esto en cuenta y buscar diferentes enfoques. ¡Gracias!
@dKen probablemente sea aún más importante presentar objetivos claros en lugar de argumentos basados ​​​​en herramientas. Sus compañeros lo encontrarán increíblemente mezquino si intenta argumentar a favor de un PIP o incluso despedir a un empleado basándose principalmente en las herramientas que utilizan.
Creo que tienes razón. El resto del equipo está prosperando con el enfoque "autogestionado" que proviene de Agile, pero este desarrollador podría estar luchando con él (de hecho, ya dijo que prefiere la presión de las tareas y los plazos en lugar de elegir lo que hace él mismo). Creo que el próximo paso es tal vez hacer y asignar objetivos claros que le resulten más fáciles de cumplir. Gracias nuevamente por su aporte (y sí, creo que culpar a las herramientas está fuera de discusión por el momento).
@dKen Según su descripción, es posible que tenga problemas de autogestión y gestión del tiempo, y algunas personas prefieren más estructura mientras que otras prosperan con menos. Es posible que sea un problema de "trabajo que se expande para llenar su espacio", especialmente si son consistentes. Es posible que deba trabajar con ellos en plazos más ajustados con informes más regulares que los que usan sus otros empleados: estrategias individuales como informes de fin de día de 15 minutos, establecimiento de objetivos matutinos, etc. Tendrá que experimentar para encontrar el camino correcto que funciona para ellos, pero nada de esto funcionará si no está comunicando claramente el problema.
Mi perspectiva sobre las herramientas es doble: 1) Pareces convencido de que su negativa a usar un IDE es terquedad, pero puedes ser igualmente terco y estar equivocado. Solía ​​trabajar en un sistema en el que el IDE generalmente me ralentizaba, excepto para pasar por el código. En mi proyecto actual, un IDE es una bendición. Depende de la persona y del proyecto. 2) El desarrollador podría estar atrapado en su zona de confort, en cuyo caso, parece justo que se vea obligado a probar diferentes herramientas, pero si lo intenta honestamente y no le ayuda, debe retroceder y dejar que utilizan sus herramientas.
Como idea novedosa, después de articular sus inquietudes y expectativas, ¿por qué no preguntarle al desarrollador qué cree que mejoraría su velocidad?
@dKen si la persona afirma que le iría mejor con una lista de tareas personales en lugar de tener la libertad de elegir entre todos los equipos que trabajan en el scrum (o etc.); ¿Sería posible poner a prueba esa afirmación y dividir una parte del trabajo razonablemente independiente que represente su 'parte justa' del total durante unas semanas para ver qué sucede?
Oye, @dan, sí, esto parece lo más prometedor para probar con el desarrollador. Iré al trabajo temprano y prepararé algo para él. Veamos cómo va.
@BrianDHall Gracias de nuevo por tu aporte, amigo. ¿Cómo evito que no sienta que lo estoy destacando si tiene que informar más que los demás?
@dKen ¿Su objetivo es no destacarlo, o simplemente evitar que se sienta señalado, mientras que en realidad lo señala? No hay nada de malo en destacar a alguien por buenas razones, y ser honesto y abierto al respecto. Por ejemplo, "Dado que hemos acordado probar un nuevo enfoque de trabajo, necesitaré que me informe con más frecuencia que los otros desarrolladores para asegurarme de que este cambio funcione bien para ambos".
@wjl Mi objetivo es alcanzar una velocidad sostenible. Si puedo hacer eso sin señalarlo, eso significará menos posibilidades de que se sienta molestado y aislado, lo que no será bueno para la moral. Aunque puede que no sea evitable. He establecido algunos objetivos claros para que él sea responsable, así que veamos si siente que lo estoy tratando de manera significativamente diferente a los demás.
@wjl un mal gerente no ajusta su estilo a sus empleados. Intentarán hacer exactamente las mismas cosas para todos sus empleados, independientemente de cómo los empleados quieran ser administrados. Un buen gerente reconoce que todos los empleados son diferentes en la forma en que quieren ser administrados y ajusta su estilo en consecuencia.
a menudo, puede automatizar más con una CLI que con una interfaz de usuario. Esta es la razón por la cual el desarrollo del lado del servidor ocurre en las líneas de comando y scripts de shell de Unix. La existencia de una herramienta de interfaz de usuario no necesariamente hace más que permitirle NO APRENDER cómo hacer algo realmente; y la interfaz de usuario es inútil si aprendió a usarla, y la herramienta automatizada hace un trabajo a medias. Si este tipo "no es tan rápido como me gustaría" pero "hace mucho bien", entonces probablemente sepa lo que está haciendo.

Como desarrollador de la vieja escuela que usa editores de texto y CLI, puedo decir que obligar a alguien a usar diferentes herramientas no necesariamente aumentará la velocidad.

Dicho esto, si usted es el líder del equipo, generalmente no es prudente microgestionar hasta el nivel de exigirle que use ciertas herramientas sobre otras.

O está haciendo su trabajo o no lo está.

Si lo es, déjalo en paz.

Si no lo es, comience el proceso para despedirlo.

El viejo dicho de que administrar codificadores es como arrear gatos no es una subestimación de la dificultad involucrada.

Esta parte realmente se destaca para mí:

En mi experiencia , esto tiene una mejora drástica en el tiempo.

Sí, en tu experiencia. En el suyo, puede tener un efecto terriblemente deletéreo.

Nunca hagas el argumento basado en una herramienta.

Recuerde, el punto es que está haciendo su trabajo o no.

EDITADO PARA AGREGAR::

Evite la microgestión a toda costa. Todo lo que hace es prepararlo para el fracaso, ya que el empleado puede reaccionar de tres maneras.

  1. Resentir y dejar caer su moral
  2. "Delegado inverso" y lo colocará en la posición en la que la mayor parte de su tiempo se dedicará a cosas de muy bajo nivel
  3. Aparente cumplir, reducir la velocidad y luego culparlo por el impacto en el rendimiento. "Estaba bien con mi editor de texto, luego me obligó a usar esta herramienta con la que no estoy familiarizado.

Su trabajo es simplemente acelerar. Asegúrese de que su equipo tenga las herramientas que necesita y elimine cualquier obstáculo para el éxito. Si su objetivo con este empleado es la velocidad, entonces siéntese con él y hable sobre la velocidad, no sobre las herramientas. Pregúntele cómo podría producir más en un período de tiempo más corto.

Mencione que cree que las nuevas herramientas pueden ser útiles, pero solicite su opinión. Si es su decisión, puede usar las herramientas voluntariamente sin que la moral se vea afectada. Es posible que conozca otras herramientas que le permitirían ponerse al día sin el IDE o las herramientas que está utilizando ahora. Recuerde: el objetivo es aumentar el rendimiento, no "Usar estas herramientas o de lo contrario"

Gracias por la respuesta Ricardo. Está haciendo su trabajo, pero a una velocidad significativamente más lenta de lo que es sostenible en este momento. Estoy impulsando algunos cambios en la forma en que trabajamos que han tenido un resultado muy positivo para el resto del equipo, pero él se resiste porque es un cambio en su proceso habitual. Generally unwise to micromanage: A veces me piden microgestión, pero en situaciones en las que el proyecto está retrasado y las tareas necesitan una priorización estricta para obtener el máximo beneficio, ¿no es a veces necesario?
@dKen Estoy editando mi pregunta para responder a esto ^^^
gracias, gran consejo y buena edición. Creo que necesito modificar un poco mi enfoque.
Creo que todo el mundo está siendo demasiado cauteloso. Digo que cambiar el entorno es un golpe de rendimiento garantizado . En el mejor de los casos, después de un tiempo, el rendimiento aumentará lo suficiente como para compensar las pérdidas iniciales. Pero esos serán pesados: si la fecha límite del proyecto está cerca, esa es la mejor manera de perderlo. Es una simple cuestión de inversión y el retorno de la misma.
@dKen ¿Pero su microgestión está ayudando objetivamente? ¿O simplemente te da la tranquilidad de saber que estás haciendo algo ? La mayoría de la gente sigue la regla "Si no puedes arreglar lo que está roto, comienza a arreglar algo que puedas" sin siquiera darse cuenta. No digo que este sea el caso aquí, pero esto es lo que le da a la microgestión su mala reputación.
@Agent_L, tiene razón sobre el impacto en el rendimiento. El cambio de herramienta está fuera de discusión ahora. Acerca de MicroManaging, es algo que sufro de vez en cuando, pero en este caso, ese MM ha dado la vuelta al proyecto. A la mayoría de las personas no les gusta recibir MMed, pero si significa la diferencia entre un proyecto fallido o uno exitoso que mantiene su trabajo seguro, entonces no hay otra opción. Mi MM ha sido efectivo de acuerdo con todas las estadísticas medibles, aunque ha tenido un efecto un poco negativo en la moral, como se esperaba. Sin embargo, ahora no es el momento para el sentimiento.
O número 4. renunció porque ya no se siente cómodo y @dken acaba de perder un codificador de alta calidad (aunque no el más rápido).
@dKen Si ayudó objetivamente, entonces no es el caso que me preocupaba :)
@dKen bueno, no se puede discutir con el éxito, pero una vez que el proyecto vuelve a la normalidad, no se olvide de retroceder, de lo contrario se agotará.
¡¿Seguro que existen más alternativas que dejarlo en paz o despedirlo ?!
@gerrit A menudo se reduce a eso, pero incluí alternativas en mi último párrafo.
@dKen "Sin embargo, ahora no es el momento para el sentimiento". A menos que el sentimiento llegue al punto de querer irse... Supongo que la partida de sus desarrolladores tendría un impacto negativo en el cumplimiento de la fecha límite de su proyecto. Por supuesto, el golpe de moral también puede reducir la motivación, lo que puede ralentizar las cosas incluso si no se van. Esto no quiere decir que el sentimiento sea el fin de todo, solo que tampoco es prudente ignorarlo por completo.
# 2 es lo que yo personalmente haría. "Ok, jefe, ¿puedo hacer clic en Guardar ahora? Ok, ¿debo confirmar? ¿Cuántas veces al día debo confirmar? ¿Cuántos espacios tiene una pestaña? ¿Debería usar la conversión de pestañas del IDE o debería contar los espacios manualmente? Ok, comencé a usar el IDE, ¿cómo debo colocar mis ventanas en mosaicos? ¿Qué combinación de colores en el IDE cree que es más productiva? No puedo escribir ningún código hasta que me diga qué diccionario usar para la revisión ortográfica. Así que tengo esta parte donde Me gustaría mirar las tablas mientras creo el modelo, ¿puedo poner las ventanas una al lado de la otra en el IDE?
Luego, después de 2 o 3 semanas, de repente tenía un nuevo trabajo en otro lugar que me permitía usar el editor de mi elección.
@coteyr Lo he hecho yo mismo. Un gerente anterior seguía tratándome como un idiota, así que actué como tal hasta que hizo mi trabajo por mí. Liberé mucho tiempo para buscar trabajo.

Como señalaron otros, forzar un cambio de herramienta dentro y fuera de sí mismo puede no ser siempre el mejor enfoque o trabajo. Sin embargo, convencerlos de que lo mejor para ellos es cambiar una herramienta, lo hará.

Esto requiere un enfoque doble:

  1. demostrarles , tangiblemente, que cambiar la herramienta les ayudará a mejorar su productividad

  2. use sus palancas de gestión para impresionarlos de que deben mejorar su productividad , de modo que estén motivados para encontrar una respuesta sobre cómo hacerlo.

    #2 es una pregunta de gestión estándar que está un poco fuera del alcance de lo que está preguntando (esta es la gestión estándar 101).

    El resto de mi respuesta girará en torno a cómo lograr el punto n.° 1, convenciéndolos de que si están interesados ​​en mejorar la productividad, cambiar la herramienta los ayudará.

Un siguiente enfoque podría funcionar mejor que "forzar", al menos con algunos desarrolladores: producir evidencia . El sabor específico que puede usar depende de la personalidad del desarrollador individual y su dinámica. Algunos de estos enfoques pueden (y probablemente deberían) combinarse y combinarse.

  • Enfoque 1: Demostración

    Pídele que vea una demostración (realizada por ti mismo o por otro desarrollador a quien respete) de cómo un conjunto específico de tareas se realiza más rápido usando IDE/herramienta nueva.

    Si son buenos desarrolladores, al menos se verán influenciados por la evidencia y la lógica. Todavía son una bolsa de carne con errores en el software (también conocido como humano), por lo que es posible que esto no siempre funcione tan bien como se desea debido a las peculiaridades de la psicología del comportamiento, así que establezca sus expectativas en consecuencia.

    Es posible que desee hacer esto de una manera obvia (enmarcándolo como "Sé que no le gustan los IDE, me gustaría demostrar cómo pueden ayudarlo"); o menos obvio ("Aquí hay una demostración para todo el equipo, mírame hacer XYZ en 15 minutos para que todos puedan ser tan geniales como yo", después de que él mismo tomó un día para hacer lo mismo).

  • Enfoque 2: Desafío

    Esto no funcionará con todas las personalidades; y puede ser contraproducente; pero algunas personas son intensamente competitivas.

    Desafíelos a ver quién se acerca más rápido; ya sea como un desafío; o como una competencia.

    Como incentivo; puedes prometerles "si ganas el desafío, NUNCA volveré a mencionar el tema y te compraré pizza gratis durante una semana; si pierdes, te comprometes a aprender y probar el IDE durante un mes".

  • Enfoque 3: abrumarlos con los beneficios de la nueva herramienta

    Personalmente, me parezco mucho al desarrollador que describiste. No usaré el mouse a menos que deba hacerlo; Hago cosas en la línea de comandos (con alta eficiencia) que la mayoría de la gente no sabe que se pueden hacer; Enseñé habilidades de CLI a mis compañeros de equipo en un entorno formal. Solía ​​odiar a Eclipse y otros IDE.

    Lo que cambió las cosas para mí fue mi manager literalmente (¿o es eso en sentido figurado? :) aniquilándome hasta la muerte con "¡Oh, mira ESO cosas geniales que puedo hacer en Eclipse!" (Fácil refactorización. Fácil depuración. "Saltar a definición". Búsqueda "Dónde se usa este identificador". etc...)

    Todavía uso CLI cuando está justificado; pero hice un esfuerzo para escalar la curva de aprendizaje de Eclipse y hacer las paces con sus deficiencias, simplemente porque el administrador demostró objetivamente que hará que mi vida sea mejor/más fácil como desarrollador.

  • Enfoque 4: IMPORTANTE: Ofrézcales ayuda con la curva de aprendizaje

    Parte de la resistencia es probablemente la combinación de que a las personas les gustan las zonas de comodidad y la dificultad objetiva de aprender a usar los IDE modernos con algún grado de competencia .

    Tu trabajo como gerente es eliminar las barreras que afectan a tu equipo; como tal, usted está en posición de tratar con este último.

    Ofrézcales cualquier recurso que necesiten: materiales de capacitación; clases, etc... Sin embargo, en mis muchos años de experiencia, la que es más útil y más atractiva es la ayuda de usted mismo o de los miembros respetados del equipo.

    Si saben que pueden hacer preguntas en el IDE a alguien que no los juzgará de la manera "eh, eso es una cosa n00b, idiota de baja reputación"; serán menos resistentes.

    Si experimentan la alegría de que alguien los ayude con un extraño problema de IDE, se sentirían mucho menos aprensivos.

Esto es brillante. No creo que ninguna de las otras respuestas haya brindado diferentes formas de alentar al desarrollador a probar IDE alternativos, y me gustan los enfoques (en realidad, me hicieron reír con su inteligencia). Buen trabajo.
También ayuda si todos en el equipo usan el mismo IDE porque entonces todos pueden ayudarse entre sí y también es más fácil cambiar temporalmente a la programación en pareja cuando se encuentra con una dificultad, porque su compañero ya sabrá cómo navegar por su IDE.
@Sumyrda Esto funciona en ambos sentidos. Ser multifuncional también podría incluir el concepto de IDE; no hay ninguna razón por la que un desarrollador no pueda sentirse cómodo en más de uno (por ejemplo, uso diferentes IDE para diferentes lenguajes de codificación). Por supuesto, hay un impacto en la velocidad a medida que aumenta el aprendizaje, pero si el objetivo a mediano y largo plazo es tener empleados más flexibles, más valiosos y más felices, entonces esto es parte de la inversión necesaria.
Solo una pequeña adición al enfoque de "desafío": es una buena idea introducir la programación en pareja en el equipo. Es decir, deje que las personas trabajen juntas en una máquina de vez en cuando. Esto permitirá que el conocimiento sobre herramientas y técnicas se propague a nivel de igual a igual sin la participación activa de la gerencia.
15 minutos con un IDE, un día con otras herramientas; ¿Qué crees que está usando este desarrollador edlin?
@MichaelKjörling: el metraje ensamblado se mejoró ligeramente para lograr un efecto dramático :)

En pocas palabras, estás en el camino equivocado. La elección de herramientas no hará que un desarrollador sea más productivo. De hecho, si obliga a alguien a usar las herramientas con las que no disfruta trabajar, afectará negativamente su moral y lo hará menos productivo. Utilizo un IDE excelente cuando codifico en Windows y herramientas de línea de comandos cuando codifico en Linux y no hay absolutamente ninguna diferencia en mi productividad entre los entornos, pero eso es porque disfruto de ambos.

Para que el desarrollador sea más productivo, hable con él y pregúntele qué lo motivaría más. Es realmente un problema de recursos humanos, no técnico.

Bien dicho, gracias. Soy el primer ministro aquí, así que está sobre mis hombros. Parece que el problema radica en otra parte que no sean las herramientas en uso.
Yo también uso la línea de comandos y el editor de texto en Linux e IDE en Windows. En parte porque no he encontrado un IDE que me guste para Linux. Pero hay otro efecto importante que noto al no usar un IDE (aunque esto puede no coincidir con su situación): necesito entender muchas cosas en un nivel mucho más bajo y más específico. Necesito escribir a mano los archivos de compilación y diseñar los proyectos para que tengan sentido y sea fácil trabajar con ellos sin un IDE. Mientras tanto, mis proyectos de Windows que usan IDE están organizados como quiere el IDE, tienen áreas importantes opacas/automatizadas/dependientes y se sienten vulnerables a problemas extraños de IDE.
Otro factor aquí es que diferentes personas piensan de diferentes maneras. Simplemente no pienso visualmente (o intuitivamente), por lo que tratar de hacerme trabajar de manera efectiva con cualquier cosa que involucre íconos en lugar de palabras simplemente no funciona. Simplemente no sé lo que se supone que significan, excepto en los pocos casos en los que he memorizado los más comunes.
El uso de mejores herramientas mejora absolutamente la productividad. Decir que no es cómico.
"La elección de herramientas no hará que un desarrollador sea más productivo". - Presumiblemente, estaría de acuerdo en que la elección de herramientas puede hacer que un desarrollador sea menos productivo. En cuyo caso, su afirmación comienza a parecer un poco inestable, ¿no es así?
@Davor. "Mejor" es una opinión, no un hecho. Algunas herramientas son mejores para algunas personas en algunos entornos. Estoy absolutamente seguro de que obligar a un desarrollador que está familiarizado con las herramientas de línea de comandos a usar un IDE no mejorará su productividad.
Es realmente un problema de recursos humanos, no técnico. Yo diría que es un salto asumir esto. Realmente podría ser cualquiera. Tal vez esta persona está rindiendo a su potencial con el conjunto de herramientas elegido.
@Davor: No creo que nadie esté en desacuerdo con que usar mejores herramientas mejora la productividad, en lo que no estamos de acuerdo es en la definición de "mejor". Para tomar un caso extremo, la mayoría de nosotros estaría de acuerdo en que una pantalla de alta resolución de 24" es mejor que una CRT de 14", ¿no? Pero si tiene un programador ciego trabajando para usted, ¿actualizar su pantalla ayudará a la productividad?
@Davor: OK, entonces soy un elitista ridículo :-) (Y un buen editor de programación personalizable no es un "bloc de notas".) Pero creo que a casi todos les falta un punto importante aquí, que es que a menos que estés haciendo una codificación absolutamente trivial (para lo cual probablemente podría contratar a una persona de entrada de datos rápida), la mayor parte de su tiempo se dedicará a pensar, no a escribir / usar el mouse o interactuar de otra manera con las herramientas CLI o IDE. De hecho, algunos de mis momentos más productivos han llegado cuando estoy de excursión.
@jamesqf Sin embargo, un buen IDE no solo es útil para escribir. También es increíblemente útil para la depuración (por ejemplo, poder recorrer el código y ver rápidamente los valores de las variables relevantes), encontrar código relacionado (por ejemplo, encontrar rápidamente todos los usos o navegar a la definición de un símbolo dado), ver cambios a lo largo del tiempo ( por ejemplo, con diferencias visualizadas e integración de control de fuente, acceso rápido a la documentación relevante, etc. Todo esto ayuda a acelerar la parte de pensamiento además de acelerar la parte de escritura. Dicho esto, también estoy en el IDE en Windows, vim en el campamento de Linux.
@reirab: Estoy de acuerdo en que un buen depurador es muy útil. La pregunta que haría es si los integrados en los IDE son significativamente mejores que gdb &c. Del mismo modo, poder encontrar símbolos, mirar documentación, etc. son útiles, y en su mayoría son cosas que puedo hacer con mi editor de línea de comandos. Me atrevo a decir que podría hacerlos todos, si necesitara hacerlos con la frecuencia suficiente para justificar el esfuerzo de escribir macros.
@jamesqf En su mayor parte, los IDE (en Linux) son solo un contenedor en gdb de todos modos. Dependiendo de la situación, puedo hacer mi depuración de c++ a través de eclipse porque su GUI es mejor que ddd, o puedo ejecutar gdb desde la línea de comandos mientras edito en emacs. En muchos casos, el comando me gusta es más rápido y fácil de obtener la respuesta que necesito. Es bueno tener muchas opciones.
@NemanjaTrifunovic Digamos que yo era gerente en un proyecto de construcción y uno de mis empleados clavó clavos con una llave inglesa. Si superó a todos los demás, entonces sí, puede usar cualquier herramienta que quiera. Sin embargo, si comienza a convertirse en el martillador más lento, entonces tal vez sea hora de decirle que cambie a un martillo. No estoy aquí para decidir si la metáfora se aplica a CLI frente a IDE, pero ciertamente es posible que una herramienta sea objetivamente mejor.
@LordFarquaad. Una buena analogía, pero estaba hablando específicamente sobre el desarrollo de software del que sé un par de cosas, a diferencia de la construcción.
@NemanjaTrifunovic Lo entiendo. Si alguien me cambiara de Eclipse a IntelliJ porque "era mejor", estaría perdido por mucho, mucho tiempo. Pero me vi obligado a usar Eclipse en lugar de vim, y eso mejoró mi productividad a pasos agigantados. Obviamente, hay demasiados factores para decidir a través de una pregunta como esta si sería mejor que el desarrollador cambiara también (y estoy de acuerdo en que hay mejores opciones para probar primero), pero esperaba hacer un ejemplo no específico del dominio que muestra que podría haber alguna validez en cualquier lado del argumento.

Estás demasiado confiado en tu juicio aquí.

A menudo he observado que las personas que no son fluidas con las interfaces de teclado tienden a subestimar enormemente la eficacia con la que una buena interfaz de teclado puede ser utilizada por alguien que sí lo es. Doblemente cuando la interfaz es extensible y la utiliza alguien que sabe cómo configurarla.

Suenas mucho como esa persona.

Para empeorar las cosas, su publicación parece bastante perjudicial.

En consecuencia, creo que es extremadamente imprudente tratar de forzar este problema.

Dicho esto, claramente crees en esto y estás interesado en convertirte. Lo que debe recordar es que cambiar las herramientas que usa puede ser un viaje bastante accidentado, especialmente cuando la nueva herramienta es muy diferente a la que está acostumbrado.

En mi opinión, la mejor manera de abordar esto es eliminar los obstáculos para suavizar la transición. La respuesta de DVK va muy bien.

Pero debes recordar que este desarrollador tiene experiencias diferentes a las tuyas.

Por ejemplo, es posible que no piense que es un gran problema comenzar un nuevo proyecto en su IDE favorito. El nuevo usuario, sin embargo, se enfrentará a una desconcertante variedad de opciones cuyas ramificaciones no entiende. Y probablemente esté constantemente comparando el proceso con simplemente presionar un atajo de teclado para abrir un nuevo archivo en su herramienta anterior y preguntándose por qué la nueva herramienta tiene que complicar tanto las cosas.

Tenga en cuenta que tiene otras opciones potenciales para lograr una mayor productividad. Ha juzgado que su trabajo es de mayor calidad, así que asígnele tareas para las que la calidad es de mayor importancia. Obtendrá sus ganancias de productividad al permitir que sus desarrolladores rápidos completen otras tareas y avancen más rápidamente, en lugar de dejarlos atascados en una tarea que tiene que pasar por varias iteraciones para pulir su código.

El problema del teclado y el mouse es algo que esta respuesta toca (y otras no) que es importante. Algunas personas piensan que apuestan por las teclas de inicio y rompen su línea de pensamiento al cambiar entre el teclado y el mouse, mientras que para otras no importa. No escribo mucho código en estos días (y uso un editor de texto), pero encontré que los IDE que requieren que use el mouse son un problema. Un IDE bien diseñado con buenos atajos de teclado solo le costará la pena de aprender un montón de nuevos atajos en comparación con el editor, imponga un IDE inadecuado a esta persona y nunca recuperará la productividad.
Es posible que la persona que usa la interfaz del teclado tampoco lo hable con fluidez. Hay buenos desarrolladores que se basan principalmente en el teclado, pero el hecho de que alguien evite un IDE no significa que sea una especie de ninja de la vieja escuela.
@Chris H: Un buen editor o IDE no debería obligarlo a aprender atajos, debería permitirle DEFINIR sus atajos. Y permita que esos accesos directos sean tan complejos como desee, como, por ejemplo, mi tecla de acceso directo que ejecuta make si estoy programando C/C++, o LaTeX si estoy trabajando en un archivo tex...
You've judged his work as being of greater quality- la respuesta original lo llamó "bueno", que se lee como adecuado. No se menciona como superior.
"A menudo he observado que las personas que no son fluidas con las interfaces de teclado tienden a subestimar enormemente la eficacia con la que una buena interfaz de teclado puede ser utilizada por alguien que es" Puedo decir que he visto lo contrario. He tenido la experiencia de personas que me dicen cuán rápido es su estilo sin mouse y luego observan el tiempo insoportablemente largo que les toma hacer las cosas más básicas.

Asegúrese de que esta persona no sea un mejor codificador a largo plazo. Es posible que obtenga funciones más lentamente, pero si son de mayor calidad, es difícil tener un argumento en contra de eso.

No hacer las cosas lo suficientemente rápido como para mantenerse dentro del presupuesto es parte de su trabajo. Alguien que es responsable, necesita intervenir y trabajar hacia una corrección. Tal vez él necesita ser responsable de la ayuda. Con suerte, alguien estaría dispuesto a trabajar con él para resolver este problema antes de que se tomen medidas drásticas. Tal vez sea el uso de otras herramientas. No se sorprenda si lo obliga a hacer un cambio y su productividad disminuye. Estas cosas toman tiempo y son peores si la persona no cree que ayudará y no está motivada.

Aparentemente, alguien a cargo ahora está al tanto de este problema o no está haciendo nada al respecto. ¿Quizás sienten que el resto del equipo tomará el relevo? Le haría saber a esta persona que no tienes intenciones de hacer eso, especialmente si no se compromete y usa otras herramientas.

Gracias @JeffO. Soy el gerente aquí, por lo que recae directamente sobre mis hombros descubrir cómo hacer que funcione. Le agradezco que haya dicho que la herramienta " puede ser el problema", en lugar de otros que la han descartado por no ser posible en absoluto, lo que en mi experiencia simplemente no se acumula. Tengo mucho en que pensar.
Si te sientes así de fuerte, deberías sentarte junto a él en una especie de situación de programación en pareja y verlo trabajar. Si él siente que la suya es una mejor manera, es la única forma en que veo que él cambie de opinión y que descartes esto.
Creo que su primera oración es un punto muy importante: "Asegúrese de que esta persona no sea un mejor codificador a largo plazo". La mayoría de los programadores muy buenos que conozco no son necesariamente programadores rápidos (y descuidados). Son codificadores donde no tienes que refactorizar nada más terminar. Compare eso con alguien que produce nuevos errores a diestro y siniestro o no piensa bien las cosas.

Hay diferentes escuelas de administración:

  • Las personas deben hacer las cosas que la gerencia les dice que hagan, y hacerlas de la manera en que la gerencia les dice que las hagan.

  • Las personas deben hacer cosas que ayuden a la empresa y descubrir por sí mismas cómo hacerlas, porque son profesionales.

La mayoría de los desarrolladores generalmente se manejan de la segunda manera y responden un poco mal a la primera. Ok, simplifiqué enormemente y hay más de 2 escuelas de administración, pero deberías entender el punto. Si desea que un desarrollador u otro trabajador altamente calificado haga algo, generalmente hace lo siguiente:

  • Dígales cuál es el objetivo y ayúdeles a descubrir cuál es su posición.
  • Deje que encuentren una solución.
  • Proporcionar asistencia donde sea que lo necesiten.

Como gerente, las herramientas que usa su equipo no le importan. Lo que debería importar es si el equipo tiene acceso a las herramientas que necesita, está adecuadamente capacitado en las herramientas que usa y si hay herramientas que causan fricciones innecesarias en los procesos del equipo. Recuerda: Ellos son los expertos, ellos saben trabajar, por eso les pagas.

Lo que puedes hacer es crear conciencia sobre las herramientas. Algunas formas de crear conciencia y familiarizarse con una gama más amplia de herramientas son hacer que los miembros del equipo revisen el código de los demás al registrarse, tener algunas sesiones de programación en pareja, tener diferentes composiciones de equipo en ocasiones especiales (por ejemplo, en la "semana anual de errores" o "semana especial"). project Friday"), y muchos más.

Consejos específicos para el editor de texto IDE vs parte de la pregunta:

Si un desarrollador que trabajó con un editor de texto durante años es significativamente más lento que otros desarrolladores que trabajan con un IDE, ese desarrollador no alcanzará repentinamente la misma velocidad que los demás al cambiar a un IDE. La diferencia de velocidad no está ni cerca de la región de "significativamente más lenta".

En última instancia, lo que importa es si los desarrolladores están alcanzando los objetivos de manera oportuna y con un estándar de calidad alto (pero razonable). El entorno no debería importar, incluso si están usando mariposas, siempre y cuando logren ese objetivo :). Aparte de las restricciones en cosas como el costo y la seguridad, deben tener autonomía sobre su entorno y no deben poder transferir la responsabilidad a las herramientas cuando las cosas salen mal porque así lo eligieron. Si hay un problema de rendimiento, está en el desarrollador. La microgestión de las herramientas del desarrollador no lo resolverá, y el desarrollador se resentirá contigo por ello.
En mi experiencia, la mayoría de los gerentes afirman usar la segunda forma, pero en el momento en que alguien hace algo que no se le ha dicho explícitamente que haga, incluso si es un beneficio directo para la empresa, muestran sus verdaderos colores y se enojan contigo por hacer algo que no estabas haciendo. t dijo que hacer. Y sí, esos son los administradores de TI.
En cuanto a mis propias preferencias, me gustan en algún punto intermedio. Que me den objetivos claros, pero que me den margen para hacer otras cosas que me brinden beneficios cuando los veo (que luego generalmente presento primero a mis gerentes dependiendo del impacto que tendrían).

Realmente no estoy de acuerdo con muchas de estas respuestas que sugieren que siempre es malo obligar a un desarrollador a usar una determinada herramienta al desarrollar. Por ejemplo, qué sucede si está codificando en Java y necesita depurar, pero tiene un desarrollador que solo usa un editor de texto y la línea de comando. Conocí a personas que estuvieron en la industria durante años, que no sabían que se puede cambiar el código en Eclipse durante la depuración y que los cambios surtirán efecto inmediatamente... Me refiero a echar un vistazo a esta pregunta sobre la depuración de Java en VIM, https://stackoverflow.com/questions/545056/how-to-debug-java-application-using-vim-gvim. La respuesta aceptada tiene un enlace a algo llamado JavaKit, que se actualizó por última vez en 2008. Si yo soy el jefe y tengo un desarrollador que se toma horas depurando Java en Vim para encontrar un error, lo que haría sería mostrarles cómo Puedo hacer esta tarea en 5 minutos en un IDE. Después de lo cual les haré saber que pueden jugar ese juego en su propio tiempo, y espero que usen el IDE mientras tanto. Pero, de nuevo, tendría que demostrar el beneficio o la necesidad comercial de esa herramienta para asegurarme de que no estaba administrando micro, sin embargo, no me permitiría debatir si un desarrollador es o no más eficiente en la depuración con o sin un IDE. Si el desarrollador fuera realmente un mago con los editores de texto y la línea de comandos, no los vería funcionar más lento...

Si la única preocupación es su propia velocidad personal, entonces estoy de acuerdo con el amplio consenso: gestionar eso. Hágale saber que podría tener opciones para aumentar la productividad mediante el uso de herramientas modernas, pero que, por lo demás, eso depende de él.

Sin embargo, si la forma en que trabaja su equipo requiere algunas de estas herramientas, ya sea que trabaje con proyectos que requieren al menos abrir Visual Studio para configurar flujos de proceso, o si estandarizó al equipo en un analizador de código que no tiene una CLI, entonces usar esa herramienta es un requisito del trabajo, y debes dejarlo claro. Está trabajando en un equipo y no debería dañar la productividad del equipo en general por su propio estilo de trabajo personal.

Cualquier cosa que esté dentro de la caja negra del programador depende de él, siempre que cumpla o supere las expectativas de productividad y calidad. Cualquier cosa que cruce fuera del equipo y tenga un impacto en los demás o en el equipo en su conjunto, sigue tus requisitos o se suelta. Esa es una expectativa razonable y una división razonable de responsabilidades para un profesional.

En cuanto a cómo, si decide que algo de esto es un requisito para que el equipo funcione correctamente: simplemente aclare, en una reunión de equipo, que el uso de la herramienta es un requisito (para todos). Si continúa sin usarlo, y no cambia después de que se lo pidan directamente, escale con la gerencia según sea necesario. Personalmente, haría un esfuerzo por "venderlo", pero no demasiado, si es un requisito, especialmente si el resto del equipo ya está convencido.

Recientemente intenté usar el IDE de Xcode con un proyecto muy grande en el que estamos trabajando ahora mismo en una Mac de 4 años: ¡desastre total! Para ejecutar los IDE de última generación, también necesita una máquina de última generación; de lo contrario, solo verá cómo el IDE dibuja sus elegantes ventanas, o peor aún, carga indicadores, en lugar de codificar. Y ahí es donde suele ser útil la CLI, porque siempre funciona a muy alta velocidad, sin importar el rendimiento de su máquina.

Entonces, ¿quizás puedas sobornarlo? Consígale la máquina más rápida que pueda encontrar y podrá usarla para aprender a trabajar con el IDE. Si vuelve a la CLI de inmediato, entréguele la máquina anterior y la nueva a alguien que pueda usarla. No como castigo, sino para utilizar el recurso efectivo. Si realmente lo intenta durante mucho tiempo, tal vez deje que se lo quede. Depende todo de tu presupuesto.

Además, como otros han mencionado, necesita ver el IDE volar, simplemente deje que algunos desarrolladores lo llamen y lo ayuden a solucionar algún problema. Automáticamente usarán el IDE según lo previsto y harán todas las cosas geniales y él estará en la primera fila y solo lo mirará e ingerirá porque probablemente esté demasiado ocupado buscando el error. Obtienes muchos momentos de oh-no-sabía-que-puedes-hacer-eso cuando ves a otra persona codificar en un editor diferente. A menudo, incluso en el mismo, deje que los desarrolladores compartan sus funciones IDE favoritas en presentaciones rápidas.

Tengo una estación de trabajo HP Z400 de 6 a 7 años, y ningún IDE se acerca siquiera a usar más de qué, ¿5% de la CPU? Me cuesta creer que una Mac de 4 años se bloquee desde un IDE cuando tengo el XCode más reciente ejecutándose en una Mac de 2010, creo.
Apple tiene un historial de venta de software inflado para hardware de poca potencia a un costo superior.
Estamos ejecutando las últimas MacBooks con 16 gb de RAM. Mi computadora es idéntica y estoy ejecutando dos IDE para dos idiomas, además de Photoshop y otros cerdos sorprendentemente rápidos. Las especificaciones no son el problema. Como mencioné, el desarrollador se dedica a la "vieja escuela"; hay pocas razones, excepto que quiere estar nervioso y hacer las cosas de la manera más difícil para aprender más (lo cual es genial, siempre que no afecte la velocidad). Es consciente de lo que otros IDE son capaces de hacer.
@dKen Management tiene que ver, al menos en parte, con la empatía. Vas a tener problemas con eso si parafraseas el argumento de la otra parte como "Quiero ser nervioso".
@MatthewWhited: ¿Tiene alguna experiencia personal? Desde mi experiencia personal de iOS / MacOS a tiempo completo, lo que dices es solo una diatriba sin educación.
Si la velocidad es lo suficientemente importante en esta empresa como para que la velocidad lenta de un desarrollador sea un gran problema, honestamente no tiene tiempo para esto. Intercambiar máquinas, configurar nuevos IDE, esperar a que el desarrollador vuelva a tener plena productividad en el nuevo entorno si alguna vez lo hace, etc., todo lleva tiempo. Mucho tiempo. Tiempo que parece que no tienes.

Las herramientas que están utilizando no son el factor limitante.

Es explícitamente claro: no quieren hacer nada más que codificar, preferiblemente donde no tengan exposición a otros humanos, y preferiblemente en casa. Absolutamente ninguna reunión, ninguna discusión, él quiere las tareas que deben hacerse y completarlas por sí mismo. Tratar de introducir Agile va a ser un desafío. No tiene muchas otras responsabilidades, el 95% de su trabajo es código.

No interactúan con otros miembros del equipo. No recibir comentarios. No hacer revisiones de código (que son una de las mejores formas de mejorar la productividad, la calidad del código y la habilidad de los desarrolladores).

Continúe permitiéndoles trabajar de forma remota, pero no el 100 % del tiempo (nuestra oficina lo hace el 10 %).

Instituya revisiones de código obligatorias en persona con todo el equipo. Permítales ver las herramientas y técnicas de los otros miembros. El código que no ha sido revisado y aprobado por otro miembro del equipo no se compromete con Master. Tal vez todos cambien a Vim, no lo sé, pero todos mejorarán.

Este es un problema de gestión. El punto es que el desarrollador no se está desempeñando lo suficientemente rápido para las necesidades del proyecto. El gerente debe llamar la atención sobre su desempeño lento y luego debe corregirlo. Si él/ella tiene preguntas para el resto del equipo sobre cómo, esa es una historia diferente, pero el problema básico aquí es que el desarrollador no se está desempeñando lo suficientemente rápido para el trabajo que está haciendo. La gerencia necesita trabajar en la situación con el desarrollador y tal vez un PIP para volver a encarrilar las cosas.

Editar basado en comentarios: He tenido una situación similar. Recomiendo actividades de "capacitación" en equipo sobre herramientas y otras cosas que están haciendo que el resto de los desarrolladores "tengan éxito". Si no quiere asustar a la persona, debe capacitar al equipo en su conjunto para seguir ciertas prácticas y herramientas para uniformar mejor el enfoque del equipo. Es probable que esto sea engorroso para todo el equipo por el bien de 1 persona, pero si no desea llamarlos específicamente, debe hacerlo genérico para todos. Puede dictar las herramientas requeridas una vez que descubra la mejor manera, pero nuevamente esto se dirige a todo el equipo con comportamientos forzados en lugar de solo al individuo. Puedes tener una conversación con ellos sin tener un PIP, pero no veo la forma de decirles que no son tan rápidos como los otros desarrolladores. que luego se convierte en el mismo sonido que mencionaste que querías evitar en primer lugar. Sí, las herramientas pueden ayudar a acelerar las cosas, pero el punto es que al desarrollador le gusta la forma en que está haciendo las cosas, que no usa las herramientas, lo que luego vuelve a ser un problema personal. ¿Quizás la capacitación los ayudará a querer utilizar herramientas más nuevas?

un PIP simplemente hará que se vaya. Por regla general, un PIP no es más que una preparación para el despido, es un terrible desmotivador
Soy el gerente aquí, así que depende de mí. No quiero ser demasiado drástico demasiado rápido. Soy nuevo (más o menos) en el equipo, pero estoy viendo algunas cosas para probar antes de pasar al siguiente nivel. Confío en que habrá algo que pueda hacer para ayudar a aumentar la velocidad.
@RichardU De acuerdo con que PIP sea un desmotivador, sin embargo, su respuesta sugiere "comenzar el proceso de terminación". No estoy seguro de cómo eso es un problema mío cuando sugieres el mismo enfoque sin mencionar ningún plan de mejora...
Gracias @mutt, buena edición. La formación es un gran punto, como lo es formar a todo el equipo para que no quede uno solo. Buen consejo. Voy a considerar el entrenamiento, pero este tipo es bastante terco, ¡así que puede ser un desafío! Bienvenido a PM, supongo :)
@dKen Lamentablemente, sí. Tenga en cuenta que al realizar el enfoque de equipo completo, tenga cuidado de no parecer "constrictivo" sino "habilitador" en la capacitación. Es muy bueno para todos estar al tanto de cosas nuevas y la capacitación es una buena manera de hacerlo. También tendrá más peso para hablar con el individuo si se niega a cooperar con el entrenamiento también. Como también menciona enderland, está cambiando las perspectivas de las personas para ser mejores programadores y no solo para crear herramientas. Espero que la capacitación lo ayude a "expandirse a cosas nuevas" para trabajar mejor con el equipo.
@mutt No se hizo para ser un golpe en su respuesta, solo que si desea mejorar el rendimiento/reentrenamiento, no lo llame PIP, tiene demasiada connotación negativa. Lo siento, debería haber dicho eso más claramente.
@dKen Si lo hiciera PIP, ¿los demás lo respaldarían en su evaluación? Es decir, ¿a sus compañeros de trabajo también les aparece la lentitud de la velocidad del revelador? Siempre es una buena idea asegurarse de que el problema sea objetivamente visible para otras personas que trabajan con la persona. También puede haber factores atenuantes que descubra de esta manera: por ejemplo, ¿esa persona está trabajando en un problema más difícil que los demás desarrolladores del equipo?
@dKen No me tomaría el tiempo para capacitar a todo el equipo en nombre de un empleado a menos que haya querido capacitarlos de todos modos. Eso es simplemente permitir que una persona sea un lastre para los demás. Si es una mala combinación y también es visible para otros, tenga la conversación honesta que necesita con el desarrollador. No es necesariamente un reflejo objetivo del desarrollador, sino del desarrollador en el contexto de este proyecto/empresa, pero aun así suena como una mala combinación y una situación que debe corregirse.

Si hay una herramienta útil que no está usando, indíqueselo.

Ciertamente estoy predispuesto a los editores de texto, y traté de escribir scala en vim, pero rápidamente me señalaron a IntelliJ, y aunque tiene una mentalidad diferente y algo así como una curva de aprendizaje; Soy mucho más productivo con él.

Por lo tanto, indíquele las mejores herramientas que cree que echa de menos. No lo obligues a usarlo, solo sugiérele que lo pruebe. Si se niega a intentarlo, eso es una señal de alerta para mí, parece una persona difícil con la que trabajar. Si lo intenta, pero no es más productivo con él, entonces al menos entenderás por qué es tan "viejo skool", algunas personas se confunden con las interfaces fáciles de usar, yo soy un poco así. ¿Tal vez pueda ponerlo en tareas en las que haya una interfaz de usuario para trabajar?

La persona que puede escribir rápidamente un script para cualquier tarea y escribir tipos más rápido de lo que habla puede ser mucho más productiva con la línea de comandos que con algún IDE extravagante, independientemente de cuán profesionalmente haya empujado a su equipo por parte del departamento de ventas. No asuma que esto está relacionado con el rendimiento de ninguna manera.

Además, no estoy de acuerdo con el enfoque general de que otra persona decida sobre las herramientas, a menos que recomiende una nueva herramienta que desconozco. La persona que usa la herramienta a diario es más competente que algún "tomador de decisiones" más alto en la jerarquía, que simplemente la evaluó rápidamente, o tal vez incluso simplemente vio la demostración bien preparada sin casos de esquina.

La discusión infructuosa y, en última instancia, sin sentido sobre CLI frente a IDE se puede encontrar aquí . La pregunta era: ¿tengo razón al probar un IDE para ver si cambia de velocidad? No estoy preguntando las preferencias de las personas sobre las herramientas de desarrollo.
El único entorno en el que vale la pena evaluar a un desarrollador es en las herramientas con las que se siente más cómodo (dentro de las limitaciones de la empresa en cuanto a costos, seguridad, etc.). Forzar uno externo no hará que el desarrollador sea más rápido, y es responsabilidad del desarrollador aprender un entorno óptimo al final del día de todos modos.
¿Debería obligar a un desarrollador más lento a cambiar de herramienta para intentar aumentar su velocidad?
RespuestasAquíPolítica de privacidad1y, 0v