¿Es una orden de la compañía cambiar a cierto IDE una bandera roja? [cerrado]

Recientemente me uní a una startup de rápido crecimiento. En los últimos 3 meses, el equipo de desarrollo ha crecido de 4 a 12. Hasta ahora, eran muy laissez-faire sobre lo que los desarrolladores solían hacer su trabajo. De hecho, una de las cosas que inicialmente encontré atractivas sobre la compañía es que la mayoría de los programadores usaban Linux, o cualquier sistema operativo que consideraran más adecuado para sus esfuerzos.

Ahora las órdenes, sin discusión, han bajado de que todos deben cambiar a Eclipse. Un buen editor. Prefiero SublimeText2, pero es solo mi gusto personal.

Para que quede claro: somos un equipo de JS que usa Backbone y Eclipse simplemente no es bueno para comprender el código de Backbone. Esto significa que aquellos en el equipo que usan un / good / IDE (PHP Storm), tienen que volver a hacer muchas cosas de buscar-encontrar-oh-esperar-donde-estaba-yo-tres-hace-hace-tres-pasos en lugar de simplemente presionar Ctrl + hacer clic y usar atrás / adelante, probablemente disminuya la productividad en un 15% y disfrute en un 50% ...

¿Es esta una bandera roja? Parece caprichoso e irrazonablemente controlado decirle a los desarrolladores (no MS) qué IDE o conjuntos de herramientas usar si ya están instalados y son productivos.

"Ahora las órdenes, sin discusión , han bajado de que todos deben cambiar a Eclipse".

Creo que esta es la verdadera bandera roja. ¿Su equipo es el experto en desarrollo de software y el que se verá afectado por la decisión, y aún así no pudo decir una palabra en la discusión que dio lugar a este orden?

Suena como un exceso de gestión por parte de jefes de pelo puntiagudo. ¿La persona / equipo que toma decisiones tiene información relevante para esa decisión?

Dado que los tomadores de decisiones están lo suficientemente calificados para tal decisión, no pedir la opinión del equipo de desarrollo tiene al menos dos deficiencias:

• El equipo no se siente involucrado. Involucrar al equipo debería ser una prioridad para la gerencia. No me gustaría trabajar como desarrollador en algún lugar donde mi opinión sobre temas tan centrales como IDE no sea lo suficientemente valorada como para ser solicitada. Es cierto que pedir la opinión de alguien y luego decidir en contra puede ser peor, pero en ese caso esperaría una razón sólida para esa decisión.

• La administración, sin embargo con experiencia, no funciona al 100% con el desarrollo de este código específico. Suponiendo que las personas que no tienen una idea interesante serían ingenuas. Por supuesto, puede ser que los gerentes hayan pensado en todo lo que se les ocurre a los desarrolladores, pero la única forma de saberlo es preguntar.

Es razonable que cuando trabajen juntos en un proyecto común, que en cada estación de trabajo tenga todas las herramientas disponibles para editar / construir / depurar su software, y que las herramientas centrales para hacer aproximadamente el 90% del desarrollo sean conocidas por todos en el equipo. Esa meta es más difícil de alcanzar si su equipo está creciendo y todos usan su conjunto de herramientas favorito personal: cuantas más personas, más opiniones. Y el trabajo administrativo también se hace más fácil si no permite que la cantidad de herramientas crezca más de lo necesario.

Por supuesto, si un desarrollador insiste en usar su editor favorito personal, puede estar bien siempre y cuando pueda asegurarse de que la fuente no se vea o se comporte de manera diferente en el editor principal del equipo (en su caso Eclipse), entonces si dev B tiene que editar la fuente del desarrollador A, el desarrollador B no debería verse obligado a aprender el editor favorito personal de A para poder cambiar la fuente de manera efectiva. Pero cuidado, si los dos tienen que trabajar juntos de vez en cuando frente a la misma pantalla (o hacer un par de programación), las cosas a menudo son más fáciles si el editor elegido es conocido por ambos.

Por el bien de la programación de pares, es bueno que ambas partes enfrente de la pantalla tengan las mismas habilidades cuando usan el teclado. También es bueno saber que, si su proyecto tiene necesidades especiales de configuración en el IDE, entonces está configurado de la misma manera para todos. Iniciar un nuevo desarrollador es más fácil cuando las herramientas son las mismas para todos.

Pero si lo comparas con solo tratar de ser más efectivo, entonces realmente no vale la pena

Sí, es una señal de alerta que la gerencia se considera un mejor juez de las herramientas con las que sería más eficiente de lo que es.

No es una bandera roja en sí misma.

A veces la gerencia necesita tomar decisiones . Cualquier problema que requiera estandarización en algo tiende a caer en esa categoría. Una vez trabajé en un cliente que había permitido que los estándares cambiaran durante algunos años y tenían más de 20 herramientas SCM diferentes. Lo que comenzó como una elección independiente de diferentes equipos de desarrollo se convirtió en una pesadilla logística que obstaculizó severamente el intercambio de habilidades y la colaboración en el código en toda la organización. La construcción integrada era ..... er ..... no muy integrada .....

Además, no es práctico ni necesario consultar a todos para cada decisión . La medida en que esto debe hacerse depende de la cultura de la organización y la importancia / complejidad de la decisión. Por lo general, tomaría una de estas opciones menos consultadas:

1. Tome la decisión usted mismo, si tiene suficiente conocimiento de los pros / contras y no es una decisión lo suficientemente importante como para requerir una consulta amplia.
2. Consulte con algunas personas clave (quienes probablemente serían los desarrolladores senior más calificados para tomar la decisión).
3. Explique el hecho de que está tomando una decisión con todos los que puedan verse afectados (correo electrónico, reunión del ayuntamiento, reuniones de equipo). Di cuál crees que es la decisión correcta, pero estás dispuesto a cambiar esto si surgen nuevas pruebas de lo contrario. Invite a las personas a presentarse individualmente si tienen puntos de vista importantes
4. Invite a las personas a formar un sub-equipo para revisar las opciones y recomendar una decisión. Buena opción si realmente es una llamada cercana, no sabe la respuesta y desea que los involucrados se involucren en la decisión.

Para algo como herramientas para desarrolladores (que es un problema potencialmente polémico), probablemente haría 2 seguido de 3 o 4. es decir, definitivamente habría algunas personas con las que no hablaría personalmente sobre el tema, pero por otro lado, la mayoría de las personas clave tendrían la oportunidad de contribuir a la toma de decisiones.

Para mí, la verdadera bandera roja estaría presente si usted cree firmemente que se ha tomado la decisión incorrecta (incorrecto == perjudica a la empresa en lugar de que simplemente no se elija su herramienta favorita). ¿Cómo reacciona la gerencia cuando plantea este problema?

• La buena administración escuchará su argumento, le agradeceremos sinceramente sus comentarios y reconsiderará su posición en caso de que haya planteado nuevas ideas . Es posible que aún no estén de acuerdo con usted y que se apeguen a su decisión, pero apreciarán que lo haya mencionado con ellos y le harán la cortesía de decir por qué se apegan a su decisión. Incluso podrían cambiar la forma en que toman tales decisiones en el futuro, y si hizo buenos comentarios, puede incluirlo en su lista de "personas inteligentes para preguntar".
• La mala gestión se pondrá a la defensiva, diga que "se toma la decisión" y otras tácticas para evitar enfrentar el hecho de que pueden haber tomado una decisión equivocada. Pueden verte como un "alborotador". La empresa sufre, al igual que su fe en la administración. Esta es una verdadera bandera roja! ¡Sal mientras puedas!

Si está utilizando Maven o algo similar, no debería importar qué IDE esté utilizando. Puede haber casos en los que uno está vinculado a un IDE específico como eclipse, si hay complementos en los que confía.

Creo que debería poder elegir su propio IDE, el IDE en el que es más productivo. Sin embargo, como ya dije, hay casos en los que tiene sentido usar un IDE estándar.

Instalaría el IDE "obligatorio por mandato", pero seguiría haciendo la mayor parte de mi trabajo en el IDE que quisiera; no es como si alguien pudiera decir qué IDE se utilizó para editar un archivo fuente.

En el IDE vs frontal editor ... para casi todos los idiomas, me fuertemente prefiero un IDE (IntelliJ) porque sólo hay mucho más que puede hacer por usted que una lata editor. Hay algunas cosas por las que vuelvo a ST2 o Emacs, pero para la codificación diaria, a pesar de lo mucho que me gustan tanto ST2 / Emacs, el IDE casi siempre gana.

Todos los equipos en los que he estado han tenido una multiplicidad de IDE y editores: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine; nunca ha sido un problema. Nunca.

Para mí, esto habla de un malentendido en los altos niveles de la organización, en cuanto a lo que realmente importa. Lo importante es dejar que los buenos programadores hagan lo que tienen que hacer y utilicen las herramientas que los hacen sentir más cómodos. La uniformidad IDE tiene muy poco que ver con la comunicación real que tiene lugar sobre las cuestiones esenciales de la arquitectura de objetos, pruebas unitarias, algoritmos, etc.

Tener el mismo IDE que el siguiente tipo solo significa que ambos sabemos cómo explorar el código con los mismos accesos directos y cómo está configurada nuestra compilación / configuración. Nada de eso importará cuando se hable de problemas de código real.

Mira, es habitable, dependiendo de otros factores en la empresa. Siempre puedes usar tu propio editor preferido para las cosas del día a día. Y tal vez su grupo está haciendo otras grandes cosas que crean una gran cultura. Pero los IDE obligatorios son un gran paso en falso de la OMI. Para mí, si me estaban entrevistando con una empresa y me informaron IDE que estaba permitido usar, me gustaría darles las gracias amablemente por su tiempo.

En nuestra tienda Ruby hay una fuerte recomendación para usar el IDE que disfruta la mayoría del equipo (RubyMine), porque sabemos que hace el trabajo y podemos enseñarnos atajos, etc.

Los desarrolladores son libres de usar un IDE diferente, pero les exigimos que tengan habilidades sólidas en ese editor si así lo desean. Si vemos a alguien luchando por navegar por su proyecto o editar texto en su FooEdit personalizado, RubyMine para ellos lo es.

Si un programador es un experto en un IDE determinado, debe usarlo. Si no son expertos en ningún IDE, probablemente haya uno o dos que sean muy comunes para su lenguaje de programación o dentro de su equipo, y probablemente tenga sentido que lo aprendan.

Ser forzado a estandarizar en un IDE parece una idea terrible.

Deben examinarse las razones por las cuales una empresa obliga a un editor o software en particular a sus desarrolladores. La parte paranoica (quizás no la palabra que estoy buscando) de mí piensa que podría haber algún tipo de seguimiento de productividad agregado al eclipse que están pidiendo a los desarrolladores que instalen. Una idea mucho menos paranoica (de nuevo) sería que han pasado tiempo agregando herramientas de compilación de productos a este IDE que facilitaría mucho las cosas si todos presionaran el mismo botón para probar y construir su rama de código.

De todos modos, lo que estoy tratando de decir es que probablemente sea más que una simple burocracia, o un método para meterse con los jefes de los desarrolladores.

Esta es una bandera roja masiva. Cada compañía tiene algunas ideas estúpidas, pero si siguen apareciendo otras banderas rojas, simplemente váyase.

Es fácil perder la motivación detrás de algunas decisiones, especialmente con un equipo en rápido crecimiento. La motivación para mudarse a Eclipse podría ser el hecho de que la mayoría de los desarrolladores parecen estar perdiendo mucho tiempo simplemente configurando el IDE y que solo hay una experiencia limitada dentro de su empresa.

Simplemente tomaría la orden de pasar a Eclipse para indicar que debe tener la configuración de Eclipse en caso de que sea necesario, pero continúe su trabajo en su editor favorito. (Es posible que deba mudarse a Eclipse gradualmente si su empresa comienza a implementar herramientas interesantes dentro de Eclipse).

Bandera Roja: Esperaría si hay algunas órdenes más irracionales antes de preocuparme.

Una startup generalmente está tratando de mantenerse ágil el tiempo suficiente para descubrir un modelo de negocio sostenible. Una vez que se da cuenta de la parte del dinero, la gerencia se mueve para ampliar el negocio. Eso es generalmente cuando todos los primeros empleados tecnológicos comienzan a irse, a medida que los procesos de ingeniería se endurecen.

Como sabes, no sabes qué hará el código hasta que lo ejecutes. Turing lo demostró en los primeros días de la informática. Esto significa que no existe una medida significativa de productividad cuando se trata de escribir software. Sin embargo, para que la gerencia haga su trabajo, la productividad debe ser legible. Como no puede medir el código (y las personas lo han intentado, por ejemplo, líneas de código), medirán lo que pueden ver. Los programadores son más legibles que el software que desarrollan. El equipo de gestión típico intenta controlar a los programadores para que estas cosas sean legibles para ellos (en lugar de hacer su trabajo real: salir del camino). Y porque miden las cosas equivocadas, no funciona muy bien.

Habiendo dicho eso, aún puedes recorrer un largo camino con un equipo débilmente acoplado. El equipo de desarrollo de Github tiene alrededor de 50 personas y rompen todas las reglas en los libros de texto de gestión empresarial. Parecen estar bien. Los errores se arreglan (eventualmente). Las características se agregan. Los incendios se apagan.

Lo que es una gran bandera roja es si están tratando de ampliar las cosas sin haber descubierto cómo ganar dinero. En ese momento, debes preguntarte cuánto valen realmente tus opciones y subvenciones no invertidas.

Seguramente esta es una mala idea. Es inevitable que el equipo sea menos productivo ya que tienen que aprender a usar nuevas herramientas. E incluso entonces no serán tan efectivos como con las herramientas que ya utilizan .

Como he probado varias herramientas, siempre tuve la sensación de "Dios mío, este editor me molesta con <insertar algún error / diferencia de la herramienta preferida>". Por lo tanto, también será un inconveniente moral.

Pero, por supuesto, también hay profesionales para que todo un equipo use las mismas herramientas. Compartir configuraciones, skripts, complementos y todo ese tipo de cosas. Lo que no sería posible con una diversidad de conjuntos de herramientas.

Por otro lado ... ese último bit no sería necesario si todos usaran su software preferido. ;)

Puede "usar" Eclipse mientras sigue escribiendo SublimeText2.

Esto significa tener Eclipse instalado y configurado para sus proyectos y ponerse al día con él para que esté igualmente cómodo usándolo si, por ejemplo, empareja la programación. A nadie le importará (o al menos debería importarle) qué editor usó realmente para escribir un código que cometió, siempre que el mantenimiento de su configuración paralela no tome una cantidad indebida de tiempo y no se desconecte del entorno de desarrollo estándar

Si está usando Git y su ramificación está baja, no debería necesitar usar los editores de los demás de todos modos. Puede empujar una rama y hacer que otro desarrollador la tire para que funcione si realmente no puede entender su conjunto de herramientas. Forzar a todos a usar el mismo editor suena como una orden de un jefe de negocios que quiere parecer inteligente pero que realmente no entiende la forma en que operan.

Si piensa en esto desde un punto de vista administrativo, la razón por la que pueden estar haciendo esto es para el cumplimiento legal. La empresa es responsable de garantizar que todas las herramientas utilizadas se utilicen legalmente y tampoco gravarán el producto que se está desarrollando. (Algunos editores son gratuitos para uso personal, pero no para otros fines, etc.) Auditar cada herramienta que cada desarrollador quiera usar puede ser costoso. He visto que en proyectos donde los plazos son ajustados, la administración será cautelosa acerca de qué herramientas / bibliotecas / etc. se utilizan para minimizar los cambios posteriores en el proyecto dirigidos por la gente legal.

En los proyectos de mayor seguridad también existe la preocupación de dónde almacenan los archivos IDE los archivos temporales y qué información se almacena entre sesiones.

Todo depende de las razones por las que tienen que recomendar Eclipse. Si los desarrolladores tienen problemas para configurar sus entornos porque todos organizan las cosas de manera diferente, puede haber una razón para recomendar una camisa de fuerza. Sin embargo, si todos estuvieran felices y productivos usando lo que quisieran, hay pocas razones para imponer un cambio en algo tan profundamente involucrado en el proceso creativo.

Eclipse es mucho más que un editor: puede seguir usando su editor favorito para editar su código y confiar en Eclipse para el control de la fuente, la depuración y cualquier otra cosa que el flujo de trabajo obligatorio de la empresa quiera que se use.

Una última cosa: hacer cumplir el proceso en este nivel puede indicar que la empresa tiene la intención de expandir el equipo de desarrollo y quiere tener una cierta estructura para que los nuevos compañeros de equipo puedan ser productivos más rápido. Si crees que Rails (o Django) como un marco "obstinado", te darás cuenta de que tener una estructura ayuda a comprender nuevas aplicaciones más fácilmente.

La bandera roja no es tanto que un único IDE / editor se está imponiendo a cada desarrollador, sino que esta decisión, y especialmente la decisión sobre qué IDE / editor se iba a utilizar, no fue tomada por todos los desarrolladores, y quizás ninguno de los desarrolladores ¡¿¡ellos!?!

Ciertamente, sería mejor que los desarrolladores llegaran a un consenso, especialmente porque obviamente están mejor calificados para la decisión (al menos en qué editor / IDE). Puede haber buenas razones para conformarse y esa decisión debería influir en la preferencia de la administración, pero qué editor / IDE debería haber sido la decisión de todos los desarrolladores.

Hacer que 12 desarrolladores emitan algunos votos sería fácil. ¡Ciertamente había tiempo suficiente para hacer eso! La conclusión habría sido dolorosa para algunos de todos modos e incluso podría haber terminado siendo Eclipse al final, pero etiquetar el requisito como una "bandera roja" en ese caso sería mucho más discutible.