Mi nuevo jefe amenaza con despedir a cualquiera que no use el IDE que ella usa. ¿Cómo debería lograr que nos deje usar el IDE que queramos?

Hasta hace poco, .Net era un entorno cerrado. Se hizo de código abierto recientemente. No conozco ningún buen IDE para DotNet que no sea Visual Studio.

Como programador experimentado, sé el tipo de herramientas que posee Visual Studio. Similar es el caso con tu jefe. Ella podría tener suficiente experiencia con suficientes IDEs para elegir el mejor para el idioma que usa.

No estoy abogando por la parte amenazante. Cuando trabajaba con mi empresa anterior, mucha gente usaba texto sublime para Python. Algunos usaron pycharm. Nuestro CTO usó texto sublime pero nunca amenazó con usar pycharm.

Lo que tu jefe está haciendo es totalmente incorrecto. En cambio, debería tener una sesión explicando las ventajas con IDE que está utilizando, para promover su uso. Los IDE no deben imponerse a un desarrollador. Deben dejarse solos para tomar la decisión.

Existen beneficios al usar un IDE único para la empresa.

1. Cooperación y formación. Si está utilizando IDE1 y el estándar para la empresa es IDE2, no puede ayudar a los nuevos empleados a ponerse al día, no puede ayudar a otros que están atrapados tan fácilmente y otros tampoco pueden ayudarlo. Entonces, si su IDE deja de compilarse por alguna razón, sus recursos son limitados en cuanto a quién puede ayudarlo. Además, la conversación “Uso IDE1 porque es mejor, no sé por qué a Jon no le gusta IDE1” no es útil, ya que socava la confianza en el liderazgo.
2. Muchos IDE tienen archivos de configuración que hacen un seguimiento de cosas como módulos vinculados, bibliotecas externas, a veces definiciones de UI que se convierten en código real, etc. Si cada persona usa su propio IDE, esa información debe comunicarse de alguna otra manera. Entonces, si estoy usando IDE1 y agrego una referencia a una biblioteca externa, eso debe comunicarse de alguna manera. Si todos usan IDE1, es probable que la referencia simplemente esté allí cuando obtenga lo último del control de origen. Si está utilizando IDE2 y Jill está utilizando IDE3, debe existir otro mecanismo para identificar este tipo de cosas. No es necesariamente mucho, pero cada lugar donde
3. Licencias, existen diferentes ramificaciones de licencias cuando las empresas usan software. Tener múltiples IDEs significa que las personas que tienen que realizar un seguimiento de lo que se está utilizando en la empresa ahora deben realizar un seguimiento de otro programa.

En lo que respecta a la elección de su jefe, recuerde, ella tiene que entender las cosas lo suficientemente bien como para enseñarle a la siguiente persona que toma su lugar (si ella es un jefe práctico, que generalmente es mejor que un jefe que no cumple con los plazos y demandas poco realistas en personas) y / o explicarlo / venderlo a las personas que controlan el dinero cuando preguntan por qué tienen que administrar múltiples licencias y tal vez pagar por múltiples programas.

Probablemente haya una muy buena razón para que su jefe quiera que use un IDE en particular. ¿Por qué no preguntas qué es?

Tiene sentido que todos usen la misma versión del mismo software. De lo contrario, SIEMPRE ocurren problemas innecesarios que tardan en resolverse. Tiempo que podría gastarse mejor trabajando en el producto real.

Finalmente eres un empleado. Te pagan por trabajar allí. Por supuesto, debe ser libre de expresar sus inquietudes y cuestionar ciertas políticas, pero al final del día, su jefe decide cómo trabaja y qué herramientas utiliza.

Así es como un profesional trabaja con otros profesionales :

Jefe: debe usar este IDE.

Empleado: Disculpe jefe, si es posible preferiría usar este otro IDE, por razones X, Y y Z.

Jefe: Ah, ya veo, esos son muy buenos puntos. Sin embargo, hay otras razones para usar ese IDE, como P, Q y R, de las que puede o no tener conocimiento. Entiendo completamente por qué quieres usar otra cosa, pero me temo que la respuesta es no.

Empleado: De acuerdo, lo entiendo. Solo pensé en preguntar.

Jefe: Gracias por su aporte y comprensión.

En muchas compañías hay equipos que analizan el software para decidir qué se aprueba o no. Si intenta utilizar otro software que no está en la lista aprobada, lo despedirán.

Entonces, el nuevo jefe puede estar tratando de asegurarse de que obedezca las reglas con las que se ha apegado, porque si deja que su departamento rompa las reglas, entonces puede ser despedida tanto como usted.

Incluso entonces, no es solo una regla absoluta, cualquier equipo de soporte que configure máquinas quiere tener una configuración tan consistente como sea posible, por lo que admitir IDE arbitrarios sin fin aún no es aceptable.

En las empresas más pequeñas, los desarrolladores pueden usar lo que quieran porque admiten sus propias máquinas, pero en muchos lugares no tienes esa libertad.

Me gusta tener la libertad de elegir mis herramientas, pero no es el fin del mundo si tienes que usar un IDE en particular. Te pagan para estar allí. Tu jefe es el que toma las decisiones. Acepta eso. Si no le gusta la cultura, hay una escasez de habilidades, por lo que debería poder encontrar otra cosa, pero no sea un empleado difícil solo por la elección de IDE.

Hay algunos beneficios prácticos si todo el equipo usa el mismo IDE:

• Formato de código consistente. Esto es muy importante, especialmente cuando se fusionan ramas. Si diferentes personas usan IDE diferentes, entonces el formato de código diferente causa muchos cambios no deseados que hacen que las solicitudes de extracción sean difíciles de revisar y causen conflictos.
• Si alguien tiene un problema con el IDE, puede descubrir cómo resolverlo y compartirlo con el resto del equipo.
• Puede preparar un documento que describe paso a paso cómo configurar un entorno de desarrollo, con recomendaciones sobre las herramientas. Esto ayuda a los recién llegados a acelerar rápidamente.

Tengo algunas sugerencias claras para mi equipo sobre qué herramientas usar y cómo configurar todo. Les digo que estas son sugerencias y que son libres de elegir lo que quieran, pero estarían solos ya que no podría ayudarlos.

Sin embargo, amenazar con despedir a alguien parece excesivo.

Mi sugerencia es decirle que eres más productivo con tu herramienta. Dígale que seguirá los estándares de codificación. Dile que no necesitas apoyo porque puedes resolverlo tú mismo. En otras palabras, concéntrese en explicar por qué su elección no terminará siendo una carga adicional para ella.

Mi primera experiencia en la gestión de un equipo de programadores fue interesante. Apenas tenía más experiencia que un pasante, y me encargaron contratar a 8 pasantes para ayudarme a desarrollar 25 cursos de aprendizaje electrónico que usaríamos como producto de nuestra empresa.

La parte difícil ya se había hecho, los que tenían más experiencia construyeron un jugador del curso y la estructura básica para cada página del curso. Lo que hizo nuestro trabajo bastante simple, mucha programación repetitiva haciendo lo mismo en diferentes páginas.

Mis pasantes eran en su mayoría estudiantes universitarios, lo que significa que sus horas de trabajo eran un poco esporádicas, y nunca supe cuántas personas vendrían en un día específico. Teníamos una fecha límite ajustada para completar el proyecto (pequeña empresa con fondos muy limitados). Pronto se hizo evidente que necesitaba que estas páginas se construyeran de manera que cualquiera en mi equipo pudiera entrar en una página, descubrir qué estaba sucediendo y hacer los cambios necesarios.

Se me ocurrió una convención de nombres muy estricta, y pasé innumerables horas creando plantillas para actividades comunes. ¿Había otras formas de hacer las cosas? ¡Seguro! ¿Hubo mejores soluciones para algunos de nuestros problemas? Tal vez. ¿Ayudó a nuestra eficiencia? Por un orden de magnitud!

Aquí está la cosa, ella es tu jefa, tenía el poder de contratarte, y por ella recibes un cheque de pago. Al final del día, realmente no importa qué IDE uses, y francamente probablemente te convertirás en un mejor programador al haber tenido que usar diferentes herramientas. En serio, este no es un problema lo suficientemente grande como para perder un trabajo, cambiar su IDE, aprender a usarlo bien, ¡Programa como el viento!

Buena suerte.

Bienvenidos al mundo real.

Para mí, esta pregunta suena como “Mi nuevo jefe exige que todos usen pantalones, pero prefiero codificar desnudos”. Puede que realmente sea más productivo el código de la honda, pero generalmente es mejor para todos los involucrados si todos usan pantalones. Hasta que usted sea el que firme el cheque de pago, no puede decidir la política de pantalones / sin pantalones (aunque puede dar su opinión).

Recientemente, le estaba proponiendo al propietario de mi empresa que cambiamos a una versión más nueva de Visual Studio y comenzamos a discutir el historial de IDE. En los primeros días de nuestra empresa, cada desarrollador usaría el IDE de su elección. Algunos usaron Visual Studio, algunos usaron vim, otros usaron EMACS, mientras que otros usaron mariposas o lo que sea. El problema era que aproximadamente el 20% de nuestro desarrollo se realizó en programación por parejas, y el popurrí de IDE fue una pesadilla. Cuando estandarizaron el IDE, la productividad general mejoró significativamente.

Honestamente, ni siquiera veo cuál es el gran problema. A menos que su jefe le pida que escriba con edlin, la mayoría de los IDE son generalmente los mismos en lo que respecta a las características. Después de un mes más o menos de usarlo, probablemente ya ni siquiera lo pienses más.

Creo que a todos les falta un factor importante a considerar aquí. El jefe en cuestión es “nuevo” . Eso puede significar muchas cosas, como:

• es la primera vez que es jefa y ella es completamente inepta (lo vio pasar)
• ella ha sido jefa antes, pero ha recibido un nuevo equipo y le gusta implementar el cambio en aras del cambio (visto que sucede)
• ella hizo la pregunta “¿cuál es el mejor IDE?” aquí en Quora y siguió con lo que la mayoría de la gente sugirió, porque no tiene idea sobre programación, productividad, editores de texto e IDE (¿Cuál es el mejor IDE?)
• ella quiere verse bien con aquellos que están por encima de ella aplicando estándares, incluso si algunos de ellos son innecesarios. Estoy a favor de codificar estándares dentro de una organización, pero imponer un IDE a los desarrolladores rara vez es un requisito razonable (visto que sucede)
• ella no tiene vida sexual y necesita un compañero para lidiar con eso. Sí, algunos jefes pueden ser perras (incluso si son hombres) porque tienen una terrible vida personal / sexual (visto que sucede)
• ella está faroleando y solo busca información real de por qué sus desarrolladores están usando las herramientas que usan; quiere contraargumentos reales y medibles y ver quién se defiende a sí mismo para establecer la cadena de mando dentro del equipo. No he visto que esto suceda, pero hay jefes inteligentes que usan técnicas poco ortodoxas para conocer a sus equipos y la forma en que trabajan.

En pocas palabras, si fuera usted, pensaría mucho por qué estoy usando el IDE de mi elección, y ¿puedo demostrarle de manera medible que las herramientas que estoy usando son realmente más adecuadas para la tarea, ahorrar dinero en el a largo plazo y son una buena opción para un enfoque de todo el equipo. En caso afirmativo, escriba un libro blanco y se lo entregue. Lo más probable es que ella vea tu punto. Si no lo hace, y quiere despedirte, puedes demandar por ser despedido sin fundamento, o puedes ir por encima de ella y hacer que la despidan, y tal vez tomar su trabajo mientras lo haces. 🙂

He trabajado en un gran proyecto, creo que 1000 programadores son grandes.

He trabajado en un proyecto pequeño, piensa que 5 programadores son pequeños.

El gran proyecto tenía un equipo dedicado de personas que se preocupaban por la “gestión de la configuración”. Este equipo decidió qué herramientas, revisiones de herramientas y tableros de desarrollo usarían las personas. Fueron bastante conservadores en la actualización, pero todos terminaron usando las mismas herramientas. No hay nada peor que pasar un día buscando un error solo para escuchar “¿estás usando la última versión? Eso suena como algo que se solucionó hace 3 semanas”.

En el pequeño proyecto, no había personas de gestión de configuración. Alguien decidió actualizar el IDE con el que estaban desarrollando a la última versión. Eso introdujo una nueva versión del compilador o modificó la configuración predeterminada del compilador (no recuerdo cuál), lo que resultó en que el código se optimizó de una manera ligeramente diferente.

El código resultante expuso un problema de sincronización sutil en el hardware: la optimización era demasiado inteligente. Nunca falló con el viejo compilador. El mismo código compilado en diferentes máquinas de repente actuó ligeramente diferente.

“Pero funciona para mí”. “Aquí falla”

La * primera * pregunta para resolver problemas difíciles como este es “¿qué es diferente?”.

Si las cosas fueron iguales para empezar, puede descartarlo de inmediato.

Las herramientas estandarizadas son tu amigo. Cualquier cosa que lo salve de hacer la pregunta “¿qué es diferente?” Ahorra tiempo y dinero.

Si vale la pena dejar de usar su IDE favorito, hágalo.

¿Cómo usar tu propio IDE?

1. Denunciarla. Haz que la despidan. Con suerte, hay personas más sensatas en la cadena, ¿verdad? Si no, mejor actualice su perfil de LinkedIn.
2. Haz que vea algo de sentido.
3. Invoca su farol y sigue usando el IDE que quieras. ¡Ojalá estuvieras trabajando en Japón!

Solo escucho un lado de la historia. Así que no puedo estar seguro de por qué tu jefe te obliga a usar ese IDE en particular. Tal vez,

1. En mi trabajo, se recomienda usar un IDE en particular, aunque somos libres de elegir el nuestro. Todas nuestras tecnologías internas y nuestro entorno giran en torno a él. Es más fácil desarrollarlo que cualquier otra cosa. Quizás sea lo mismo para ti. Ella no quiere que pierdas el tiempo.
2. A ella le gusta el IDE y quiere que su equipo lo use. Ella mencionó amablemente antes, pero ninguno de ustedes cambió. Entonces ella regresó con amenazas.
3. Este IDE particular es el producto de su empresa.
4. Ella solo está siendo una mala jefa.

Pero cualesquiera que sean sus razones, las amenazas son un poco preocupantes.

Si está lista para despedir a las personas por su elección de un IDE, debe comenzar a preguntarse para qué más estará lista para despedirlo.

En mis 30 años como desarrollador de software profesional, solo pude elegir mi cadena de herramientas cuando estaba trabajando en proyectos en solitario.

Cuando se trabaja en un equipo, es importante que todos usen la misma cadena de herramientas y la misma versión. ¿Por qué? Porque incluso los cambios de versión pueden romper la compilación, lo cual es una mala cosa.

En entornos particularmente regulados, como los dispositivos médicos y aeroespaciales, los compiladores (etc.) y las versiones deben informarse al gobierno o no se obtiene la aprobación para enviar su producto.

En el desarrollo integrado, es una práctica bastante común archivar una copia de las herramientas utilizadas para construir el software junto con el código fuente. Esto se debe a que hay muchos casos en los que los cambios solo se realizan después de años (rara vez, décadas) de solo enviar el mismo producto.

Si su nuevo jefe ya amenaza con despedir a la gente, lo que IDE está usando es el menor de sus problemas.
Despedir personas por preferencias de software está completamente fuera de lugar.

Eso no quiere decir que si su jefe dice “estamos estandarizando este IDE” y se resiste a sus intentos de persuadirlos para que sean más flexibles, no tendrá que decidir cuál es más importante, su IDE o su trabajo. Pero si está acortando la conversación y excluyendo la discusión con amenazas, entonces no está manejando, está afirmando el dominio. Ella tiene rencor o está sobre su cabeza. Este es un mal jefe.

Mi sugerencia es buscar un trabajo en otro lugar.

Tu pregunta es abstracta.

¿Su empresa posee ese IDE? Entonces, supongo que no tiene otra opción, ¿verdad?

¿Está siendo ingeniosa pidiéndole a los empleados que usen el IDE particular o que lo despidan? Puede haber una razón para hacer que se cumpla, averígualo. Si no puede, es mejor que lo despidan por no cumplir con los estándares IDE de su empresa en lugar de agregar un IDE adicional a su currículum.

Todos los demás usan el mismo IDE: debe recomendar a otros que usen un IDE específico para no amenazarlos.

Podemos repasarlo especulando diferentes escenarios, pero tratamos de averiguar la razón. Si es absurdo, actualice su perfil de LinkedIn.

Entre lo que se quiere decir y lo que se entiende, ¡se pierde mucho! Una de las posibilidades:

1. Su jefe, que probablemente sea una persona con experiencia, ha elegido usar un IDE. Ella lo encuentra asombroso.
2. Ella identifica que ciertas características en el IDE la ayudarían a organizar las cosas mucho mejor y podrían mejorar la vida de sus programadores.
3. Ella decide pedirle a cada uno que use la mejor herramienta. (Probablemente pregunta y nadie está interesado)
4. Ella piensa que una amenaza leve sería un buen empujón. Ella no puede recortar el sueldo porque la compañía no la dejó hacer eso. Pero ella conoce su autoridad y sabe que sus juniors también conocen su autoridad.
5. Entonces ella dice “Te despediré si ustedes no usan este IDE” con la esperanza de suavizar todo. Ella lo hace pensando que los empleados cambiarán porque este es un problema menor en comparación con la pérdida de trabajo.
6. Uno de esos empleados es un tipo súper serio que no quiere cambiar el IDE y publica la amenaza en línea sin discutir con ella al respecto.
7. La gente piensa que “esto es serio” y él está recibiendo sugerencias sobre cómo denunciarla.

¿Cómo puedo predecir todo esto? Porque en un momento había aplicado la misma política porque el IDE podía sincronizar configuraciones de llaves, espacios, sangría, herramientas, entorno, implementaciones, etc. El proceso recibió al menos un aumento de 2x solo por el IDE.

Discutir con ella. A menos que sea tan mala como la hiciste aparecer en la red, es probable que te diga por qué quiere que se haga.

(^_^)

Las empresas tienen muchas razones legales / de seguridad / de administración para forzar el uso de cierto software. El software * ejecuta * la empresa. Si trabajó en la construcción de un avión, no puede elegir qué destornillador (IDE) o tornillos (código, marcos) que usa.

Pregúntale sus razones. Si no está de acuerdo con ella, discuta. Y si es un gran problema para ti, renuncia.

He estado en tiendas de desarrollo donde todos usaban un IDE diferente y todos eran un IDE de estilo “apuntar y hacer clic”. Se gastaron numerosas horas tratando de averiguar por qué algo no funcionaba solo para descubrir que se trataba de un error de configuración en el IDE. Si yo fuera tu jefe, dependiendo de la pila, probablemente te haría usar Atom y una ventana de consola. Esto evita las diferentes configuraciones que existen, me muestra que conoce bien una CLI y que no es simplemente un mono de apuntar y hacer clic. Debe examinar los pros y los contras entre su elección y la de ella. Si puede encontrar más profesionales para su elección que los suyos, profesionales que realmente se ocupan de la productividad y no de la preferencia, entonces hable con ella. Descubra sus ventajas y desventajas y compare.

Sin embargo, ella es nueva, así que realmente debes equilibrar a tus profesionales con enojar a tu nuevo jefe. Si no trata absolutamente con la productividad, entonces sería mejor absorberlo.

Demuéstrele a través de resultados medibles que el beneficio de los desarrolladores que utilizan múltiples IDE supera el beneficio de la estandarización del equipo en un solo IDE.

Asumiendo que son un ingeniero real, no pueden ignorar los datos reales.

Sin embargo, si falla y demuestra que es más eficiente para estandarizar … ¿es usted un verdadero ingeniero?

Voy a apuñalar en la oscuridad aquí y supongo que este es quizás su primer o segundo trabajo en una empresa establecida con más de un desarrollador o tal vez no tenga muchos años de experiencia laboral.

Hay algunas razones válidas por las que un jefe puede querer que use un IDE en particular. Como no ha dado más detalles en sus preguntas al momento de escribir esto, mencionaré algunas:

• Digamos que te atropella un automóvil esta tarde y aterrizas en el hospital durante una semana. Algo en su código debe hacerse con urgencia. No puede hacerlo, por lo que se llama a otro desarrollador para que lo ayude. Dado que todos están trabajando en el mismo IDE, el otro desarrollador puede compilar su código en un instante y dado que él también está familiarizado con ese IDE, sabe cómo usarlo lo suficientemente bien como para encontrar el problema y solucionarlo. Ahora considere si ese desarrollador nunca ha visto el IDE que usa, puede llevarle medio día descubrir cómo navegar a las tareas relevantes y cargar su proyecto en él. O para que funcione en el IDE que prefiere puede requerir muchos ajustes, lo que obviamente la compañía no puede permitirse si no hay tiempo que perder.
• el IDE particular que está aplicando su jefe puede no ser una versión gratuita, o pueden tener algún acuerdo contractual con un proveedor de servicios o cliente para usar ese IDE. Si la empresa pagó varias licencias para que sus desarrolladores utilicen ese IDE, entonces tienen que justificar ese gasto.
• Si su computadora portátil / computadora es propiedad de la compañía, entonces es un buen derecho de la compañía elegir qué software se puede instalar o no en él, le guste o no. Al instalar su propio software, podría poner en riesgo a la compañía. sus políticas de seguridad o incluso causar problemas legales.

Ahora, supongamos que ninguno de los anteriores se aplica y que son cinco desarrolladores en su oficina y los cinco quieren usar el mismo IDE (pero que es diferente al que prefiere su jefe), puede tener un caso, en el que podría compile una lista de razones de por qué su IDE preferido es mejor que la elección de su gerente, y tal vez demuestrelo y muéstrele todas las cosas que puede funcionar mejor de lo que ella prefiere. Si puedes convencerla, genial. Si no es así, al menos trate de entender por qué ella prefiere ese IDE y pídale que le muestre las cosas que le gustan, podría ayudarlo a comprender mejor su razonamiento y tomarlo de allí.

Considere también esto:

Es una muy mala idea vincularse a un solo IDE. En primer lugar, muestra que no es flexible para adaptarse a diversas tecnologías y, en segundo lugar, puede terminar corriendo el riesgo de quedar desempleado o limitar sus perspectivas laborales a empresas que solo usan el IDE que prefiera. Tal vez el tipo de trabajo que realiza no requiere mucha adaptabilidad, pero en el mundo del software que cambia rápidamente no es un riesgo que deba correr.

Es posible que algún día consigas un trabajo en el que tengas que trabajar en una variedad de proyectos diferentes. El tipo de proyecto puede determinar qué IDE sería el más adecuado para utilizarlo. Cada IDE tiene algo bueno y sobresaldrá en algo en que otro IDE puede requerir más configuración. Date un tiempo para descubrir sus características fuertes y tal vez incluso te guste. Mi trabajo actual, por ejemplo, requiere que use alrededor de 5 IDE diferentes, algunos que odio, otros que amo, pero definitivamente no voy a buscar otro trabajo porque tengo que trabajar con software que no me gusta o con el que no tengo problemas. Es un desafío y una oportunidad para crecer. Es algo que puedo poner en mi CV para mi próximo trabajo.

Aquí hay algunas consideraciones.

1. ¿Su tecnología depende en gran medida del uso de un solo IDE? P.ej. El desarrollo Dotnot realmente necesita un estudio visual. En tal situación, no se puede culpar al jefe por sugerir la mejor opción teniendo en cuenta la productividad y el equipo.
2. ¿El IDE sugerido por el jefe hace que las personas sean menos productivas o necesita recursos? Sugiera un IDE más productivo y eficiente y explique por qué y cómo es mejor.
3. Si su trabajo realmente no se ve afectado por el IDE utilizado, solo dígale al jefe que continuará trabajando en su IDE actual porque eso es con lo que se siente más cómodo y productivo y no tiene sentido perder el tiempo (horas facturables) en familiarizarse con algo más cuando se sienta realmente cómodo usando algo que sea igual de bueno.