Convencer al desarrollador para que use IDE [cerrado]

Hay un desarrollador, llamémoslo John (actualmente en período de prueba) en la empresa (empresa bastante pequeña de aproximadamente 10 personas, 3 desarrolladores, uno de ellos trabaja mucho en esta empresa conoce el proceso comercial y puede considerarse como líder del equipo) que no quería usar ningún IDE (está usando algún editor de texto).

La aplicación en la que trabaja este equipo es una aplicación Java de tamaño mediano con la pila de tecnología Spring Hibernate y la refactorización / adición de nuevas características para lanzar una nueva versión de esa aplicación en un futuro próximo.

El rendimiento de John trabajando sin IDE en esta aplicación es más bajo de lo deseable, la suposición del líder del equipo (llamémosle Bill) es que esto sucede porque John no está usando IDE.

Bill intenta persuadir a John para que use IDE, pero esta idea encuentra mucha resistencia y la razón principal es "Quiero tener el control total de lo que estoy haciendo, así que necesito escribir todo el código por mí mismo".

¿Cómo puede convencer Bill de que John intente usar IDE? (considerando el hecho de que Bill ya protegió a John del dueño de la compañía, varias quejas sobre el desempeño de John)

Actualizado: Bill decide intentar convencer a John una vez más si ese intento no tiene éxito, entonces no intentará obligar a John a usar IDE y más bien mirar si las características prometidas por John se entregan a tiempo o no.

Ya has respondido más o menos la pregunta:

1. El esta en libertad condicional
2. No es lo suficientemente productivo

Por lo tanto, debe ser consciente de que:

1. Necesita ser más productivo o no sobrevivirá a su libertad condicional.
2. Es probable que sea más productivo con un IDE adecuado que con un buen editor de texto.
3. Un buen IDE no se trata de ceder el control sobre el código que escribe, sino de proporcionarle herramientas que le permitan producir código de trabajo más rápido, independientemente de si elige usar las instalaciones de generación de código y plantillas que pueden estar disponibles dentro del IDE .

La falta de voluntad de adaptarse a su entorno también podría ser una preocupación.

Bill debería decirle a John que tiene razón sobre preferir un editor de texto simple, pero desafortunadamente, con frameworks de lenguaje + como Java + Hibernate + Spring, necesita usar un IDE si quiere ser eficiente.

Soy un poco como John No me gusta usar IDEs.
Cuando codifico en ruby ​​/ python / bash / lisp, no uso ningún IDE.

Pero cuando estoy tratando con un lenguaje tan bajo / detallado como Java y marcos que hacen que su código sea muy difícil de navegar sin ayuda, utilizo el IDE. Eso también es cierto si no conozco muy bien el lenguaje / marco.

• Cuantas más abstracciones / patrones / marcos utilices, más necesitarás un IDE capaz de ayudarte a navegar a través de tu código.
• Cuanto más bajo sea el nivel / detallado / desconocido para usted en un idioma, más necesitará un IDE capaz de ayudarlo a generar / encontrar el código que necesita.

Dígale que si quiere ser eficiente con las herramientas que usa, tiene que usar un IDE. Bill también debe programar en pareja con John para mostrarle cuán eficiente puede ser con el IDE.

Creo que impulsar un IDE es una mala idea. Creo que tener una lista de herramientas que las personas pueden usar, y que dejar que elija lo que usa, es una solución más respetuosa.

Luego, enfóquese en el rendimiento y la productividad del problema real, proporcione estadísticas reales de cómo ciertos proyectos han tomado demasiado tiempo.

No permita que el foco sea la herramienta que utiliza para codificar, solo permítale encontrar su propia solución, siempre y cuando el objetivo sea una mejor productividad.

He entrado en muchas compañías, al 90% no le importa, siempre y cuando no tengan que pagar por ninguna herramienta, al 10% le importa y exijo que usen sus herramientas.

Si haces del IDE el foco real de tu discusión, serás totalmente irrespetuoso con él y sus métodos.

En lugar de centrarse en el tema clave real, la productividad, la calidad y el rendimiento.

Yo mismo, he estado usando un editor de texto durante más de 6-7 años, y no hay nada de malo en mi rendimiento.

Un IDE puede ayudar, pero tiene que ser la elección del programador usarlo, siempre que no afecte el rendimiento.

Personalmente, odio que los IDE nunca los usen, mientras más personas me empujan, más me siento irrespetada. No tengo ningún problema con qué herramienta usan las personas, pero es como una religión y evangelismo, sienten la necesidad de que todos los demás tengan que pensar / hacer todo de la manera que lo hacen.

Y ese es un enfoque muy poco profesional sobre cuál es el verdadero problema, su productividad.

Si entrega el trabajo de calidad, en sus métodos, ¿a quién le importa qué herramientas usa? Siempre que esté libre de errores, sea un trabajo de calidad y sea oportuno.

No sé si hemos confirmado que el IDE es el problema de John. Creo que Bill debería trabajar con John un poco y observarlo: lo que está disminuyendo su productividad. Si pasa horas formateando su código e intentando mover cosas o buscar funciones ... el tipo de cosas que un IDE le proporciona, entonces debe mostrarle cuánto más rápido puede encontrar las funciones que desea y formatear su código con el IDE Si esta es la frustración, estoy seguro de que una vez que te vea formatear automáticamente un bloque o encontrar rápidamente alguna función oscura, saltará por el techo con alegría.

Sin embargo, si la eficiencia se debe a que está navegando en Google o tiene problemas para formular sus ideas en estructuras de codificación, un IDE no lo ayudará. En ese caso, debe tomar medidas enérgicas contra su disciplina o ayudarlo a aprender a diagramar sus ideas en un flujo de programa para que pueda atacar el problema de manera más eficiente

EDITAR: Mi representante es demasiado bajo para comentar, así que tengo que publicar aquí. No estoy de acuerdo con la gente que dice "deja que lo despidan, entonces él aprenderá". Para algunas personas esto funciona; perder su trabajo los sorprende y realmente se despiertan y se ponen en forma. Otros se convertirán en una espiral autodestructiva que generalmente termina en terapia o bienestar. Bill claramente se preocupa por John o no estaría preguntando cómo ayudarlo, por lo que creo que los comentarios y respuestas sobre dejar que lo despidan definitivamente no son lo que Bill está buscando.

El fracaso es un gran maestro. Bill puede dejar de proteger a John y dejarlo defender sus propias decisiones. Si John es despedido por eso, con suerte eso lo convertirá en un mejor empleado para la próxima compañía que lo contrate.

Puede intentar convencerlo de que si comprende el IDE y lo que hace, él tiene el control total.

Esta es la zanahoria.

El problema es que está en libertad condicional.

Tengo que decir que estaba usando e IDE (aptana para javascript), y lo odiaba, era lento e hizo cosas extrañas con el formateo. Me cambié a gvim con muchas herramientas de línea de comandos y estoy mucho más feliz.

Por supuesto, soy el tipo de persona que escribirá generadores de código en Elisp por diversión.

Me cuesta creer que el rendimiento de John tenga algo que ver con el editor que está usando. En mi lugar de trabajo, casi todos usan un editor de código diferente (Visual Studio, Source Insight, vim, SlickEdit ...) y no hay una correlación visible entre el editor / IDE y el rendimiento laboral.

Si hay un IDE estándar de la compañía, simplemente dígale "Este IDE es el estándar de la compañía, USE US".

Si no hay un IDE estándar de la compañía, y el deseo de que él use un IDE es solo para aumentar el rendimiento, entonces es:

1. La suposición errónea de elegir el entorno de desarrollo será un factor importante en el rendimiento
2. El enfoque equivocado para decirle que use un IDE

Si realmente quiere que use un IDE, creo que el mejor enfoque es decirle que su rendimiento no está a la altura, y luego mostrarle cómo el uso de un IDE puede ayudar a mejorar ese rendimiento. Mostrar con el ejemplo es un motivador mucho mejor en mi opinión.

Dicho esto, creo que las suposiciones están mal aquí. La mayoría de los desarrolladores decentes pueden ser productivos en prácticamente cualquier entorno de desarrollo. Si no está cumpliendo con las expectativas, entonces tal vez la causa raíz sea el desarrollador, no el IDE.

Si Bill, a pesar de su posición como líder del equipo, no puede hacer que John use un IDE cuando Bill quiere que todos lo usen, hay algo mal con la compañía en que el líder del equipo no tiene suficiente autoridad.

Y no, dependiendo del trabajo otorgado a una persona, esa persona puede ser tan productiva sin un IDE como con uno, dependiendo de las herramientas en uso, la experiencia de la persona con esas herramientas y su competencia general (y el entorno general, si John tiene que extraer cada fuente de un servidor de aplicaciones, cargarla en su IDE, editarla, cargarla de nuevo, etc. etc. es mucho más rápido simplemente editando directamente en el servidor de aplicaciones usando say VI (suponiendo que conozca bien a ese editor) .

No usar IDE es muy bueno porque aprenderá mucho. Pero no debería ser por el costo del proyecto. Debería usarlo cuando cree que podría terminar el trabajo sin afectar la línea de tiempo.

Sugeriría que él haga ambas cosas, para que pueda aprender rápido y al mismo tiempo no tener problemas.

Después de todo, necesita pan para sobrevivir, entonces solo usted puede pensar en convertirse en un culturista.

Creo que el valor principal de cualquier IDE no es que sea un editor, sino que sea un depurador. Hay algunos que no entienden el concepto de depurador. Se depuran con declaraciones impresas.

Si otras características son las que supuestamente hacen que los IDE sean más productivos, como intellisense o la conexión de control de versiones, podría estar de acuerdo con John, por varias razones que podríamos debatir.

Pero la depuración con declaraciones impresas me resulta difícil de asimilar (aunque solía hacerlo).

Escucha, hay personas que usan cosas, hay otras personas que usan otras cosas. Me gustan tanto el IDE como los editores de texto, son solo 2 tipos diferentes de aplicación, pero al final, la tarea realizada es absolutamente la misma.

Son solo naranjas y manzanas, al final de la línea, si quieres despedirlo diciendo "usa un editor de texto" o "es demasiado lento, PORQUE usa un editor de texto", continúa, pero ¿realmente tienes que conspirar? por alguna estrategia sobre cómo puedes convencerlo?

Sabes, la libertad no se trata de "solo prevalecerá el más apto", se trata de "Hacer lo que quiero".

No es porque vivas en una democracia que debas imponer la práctica de la mayoría. Casi parece una persecución de algún tipo