Tratando con Fanboys [cerrado]

Probablemente todos hemos conocido a alguien así, ese desarrollador que simplemente sabe que su idioma es el único idioma verdadero y no se callará al respecto. ¿Cómo se trata como alguien así? No quiero ofender a nadie (especialmente porque el fanboy en mi lugar de trabajo es el desarrollador senior). Pero quiero poder usar mi propio lenguaje de programación cuando tengo que escribir una secuencia de comandos desechable que nunca llega al repositorio y nadie más necesita saber que existe.

Pensamientos que tuve que lidiar con esto:

1. Ríete - "Jaja, sí, tal vez el lenguaje X es un poco más fácil, ¡supongo que soy masoquista!"
2. Adelante, realmente preferiría evitar esto, ya que no puedo permitirme la caída de la productividad asociada con aprender un nuevo idioma.
3. Ocultar mi idioma: conviértete en un programador de clóset y oculta mi monitor cada vez que escribo o automatizo algo.

¿Qué sugerirías para esta situación?

Pocas cosas están saltando fuera de la cuestión.

• ¿Es realmente un guión desechable? Si es así, es extraño que se esté discutiendo.
• ¿Estás seguro de que el guión desechable permanecerá como está? Muchas cosas de producción han sido un guión descartable en algún momento.
• ¿Va a reescribir el script si se promociona y necesita integración en el sistema?
• ¿La elección del idioma es puramente sintáctica o es un idioma de otra esfera?

Entiendo un poco la parte del fan-boy, porque desde un lado, a veces me comporto como un fan-boy, mientras protejo mis pocos idiomas de elección. Y también he tratado con otros fan-boys que intentan traer cosas nuevas.

Mi punto de vista sobre esta situación es así:

• Si es un idioma nuevo, pertenece a un contenedor de basura.
• Si es un lenguaje probado en la industria, puede usarse si está especializado para la tarea.
• Si es un lenguaje muy impopular, pertenece a un contenedor de basura, incluso si es súper genial y súper rápido.

Es porque nadie sabe cómo escribir software seguro y rápido en un idioma desconocido, y tiene todo lo que los desarrolladores tienen que aprender. El estúpido script tendrá que ser soportado durante 20 años o reescrito. Durante 20 años, al menos 50 desarrolladores cambian en una tienda promedio. Si cada uno escribe algunos scripts sofisticados en un nuevo idioma, necesitará 50 tiempos de ejecución de idiomas, 50 expertos diferentes en el equipo y la base de código tiene código defectuoso en 50 idiomas. Y algunos de los idiomas ya no son compatibles con Windows o Linux. Y necesita ese servidor personalizado de 10 años sin parches, sin repuestos disponibles, 24/7.

Además, nadie realmente quiere admitir idiomas muertos como VB, Silverlight, D, etc., cuando la base de código probablemente sobrevivirá al lenguaje mismo.

¿Decide lo que usa según la política de la empresa? Apele su caso a él; si todavía decide no hacerlo, cállate y haz tu trabajo con las herramientas que tu jefe dice que deberías usar.

Usted trabaja allí, no se juega allí. Finalmente está fuera de tus manos.

Incluso si él no es tu jefe, consideraría todos los ángulos aquí. ¿Te gustaría que conociera a Fortran y algún día heredases todo su código? Habría que aprender un nuevo idioma desde cero sobre la marcha , que es terriblemente estresante. Ahora imagine su lado, puede escribir sus guiones usando Cobol y puede que él no conozca a Cobol.

Use algo que la mayoría de su equipo sepa.

"2. Ve con eso"

Esta es la única respuesta razonable. Tienes una gran oportunidad aquí.

• Use los comentarios del programador senior para alentar a su empresa a pagar por el tiempo y / o un curso y / o certificación para aprender el nuevo idioma. En el peor de los casos: la certificación y el idioma mejorarán su currículum, puede obtener una buena recomendación para ser un jugador de equipo, y puede reírse hasta encontrar un mejor trabajo en otro lugar.

• He obtenido información valiosa sobre la programación de cada idioma que aprendí. Incluso el lenguaje menos práctico ( tos XSLT tos ) tenía su punto óptimo y estaba lleno de interesantes oportunidades de aprendizaje (y pagó mis cuentas durante varios años). El aprendizaje constante es uno de los grandes beneficios de ser programador.

• Todos los proyectos geniales probablemente usan el lenguaje favorito del desarrollador senior. Saber que el lenguaje te coloca en el grupo de talentos que pueden trabajar en esos proyectos.

• Es probable que alguien le pague para que realice cierto trabajo de cierta manera. Cualquier otra respuesta es probablemente insubordinación y es probable que termine mal.

El desarrollador / arquitecto senior normalmente elige el idioma principal utilizado en una tienda y se asegura de que todos usen ese idioma. De esta manera, una compañía construye una base de conocimiento en ciertas tecnologías para que un empleado (usted) pueda tomarse vacaciones y otra persona pueda recoger su código y arreglarlo mientras está fuera. Además, la compañía puede incorporar talentos de capacitación relevantes y el departamento de recursos humanos sabrá qué palabras de moda buscar en los currículums.

Al aprender su idioma y usarlo para el trabajo, usted acumula el capital político que necesita para defender eficazmente su idioma favorito. Muchas compañías tienen un lenguaje de infraestructura oficial y un lenguaje de scripting oficial para informes. Prepare una lista de pros y contras que muestre dónde sobresale su idioma y dónde lo hace el suyo, también donde cada uno se queda corto. Debe mantener esta lista en el contexto de una aplicación específica, como los informes que está escribiendo. Planifique un tiempo con él para mostrarle la lista de manera privada y respetuosa y discutirla con él. Escriba sus objeciones, investíguelas después de la reunión y, si tiene buenos contraargumentos, planifique una reunión de seguimiento.

¡Buena suerte!

Muestre que en un contexto específico, otro idioma es una opción más pragmática.

Si la persona es una apasionada de C ++ y está trabajando en un proyecto de aplicación web, no sería demasiado difícil. De la misma manera, algunos contextos están muy inclinados hacia la programación funcional y usar un lenguaje no funcional no sería muy sabio.

Notas:

• Evite situaciones en las que tanto su idioma como su idioma preferido sean muy similares.

  Por ejemplo, difícilmente imagino un contexto en el que Java sea "mejor" que C #, o C #, "mejor" que Java.

• Recuerde que la elección de un lenguaje es a menudo subjetiva y se explica más por la experiencia previa de un desarrollador que por algunos elementos basados ​​en evidencia.

  Por ejemplo, si me piden que haga una aplicación relacionada con el sector financiero, seguiría usando C # en lugar de Haskell, incluso si encuentro a Haskell más apropiado y realmente emocionante. La razón de esta elección es que tengo años de experiencia con C #, pero cuando se trata de Haskell, solo he leído algunos tutoriales y nunca los he usado profesionalmente.

La respuesta es 2) Ve con eso.

1. La única forma de callar al fanboy es hablar con fluidez (hasta cierto punto) en su idioma de elección.
2. La pérdida de productividad no es un problema. Está haciendo lo solicitado por su superior, por lo que los cambios de productividad deben ser acomodados por el proyecto.
3. Aprender un nuevo idioma hará que tu cerebro funcione mejor.
4. Aprender a ser abierto acerca de aprender nuevos idiomas te hará aún más bien.

Es ganar-ganar-ganar-ganar. ¡Disfrutar!

La respuesta es que no lidias con eso. Discutir con ellos simplemente arrastra al argumentador a su nivel (donde te golpearon con experiencia) y, en última instancia, no es constructivo porque son de mente cerrada.

Ignora cualquier argumento que den a favor o en contra de su idioma y toma tu propia decisión. Utilice las técnicas habituales, como evitar el contacto visual, responder monosílabicamente y pasar a un tema nuevo cuando el silencio lo garantice. Entrénelos para molestar a la persona a su lado.

El desafío aquí es que el fanático asocia el idioma con su identidad y cualquier negatividad asociada con ese idioma es personal. No ataque ni defienda. Solo ignoralo.

Muy pocas cosas en un trabajo son guiones verdaderamente descartables. Termino poniendo muchas de esas cosas en la wiki o en el repositorio de todos modos en caso de que sea necesario nuevamente.

Incluso las cosas que creo que están por debajo del nivel de compartir, mis compañeros de equipo a menudo se sienten de manera diferente. Por ejemplo, tengo un alias rgrep en mi .profile. Es solo una declaración de búsqueda con un parámetro ya que no tengo acceso a rgrep real en ese servidor. Un compañero de equipo se enteró y lo quiso en la wiki. Sí, la declaración de una línea. Obviamente no tuvimos un debate sobre el lenguaje de implementación, tenía que ser UNIX. Pero resalta la necesidad de hacer cosas que otros en el equipo puedan entender.

Otro giro es que es posible que el desarrollador senior tenga una razón que no conozca para usar ese lenguaje. ¿Has preguntado?

Tal vez intente hacer el mismo script en ambos idiomas una vez para mostrar por qué el suyo es mejor.

Deberías intentar empañarte . Esto significa estar de acuerdo con todo lo que dice el fanboy (en parte o en su totalidad), pero hacer lo suyo a menos que se le indique explícitamente que haga lo contrario.

Las opciones pasivo-agresivas 1,3 conducen a más angustia emocional, así que dame un 2) tómalo en la barbilla.

Algunos consejos generales para el camino: 4) Si no te hace más inteligente escuchar a tu superior, haz tu propio estudio en diseño de lenguaje / compilador. Escoge un idioma y aprende qué pensamientos entra en él. Cuál es la compensación entre características, rendimiento y poder expresivo. Qué otras opciones hay. Esto solo le otorgará superpoderes de programación inhumanos. Aprenda NBL incluso, va a ser enorme.

Afirmarse empujando opiniones sobre otros inhibe la productividad y la comunicación. La gente puede pensar que renunciar al impulso emocional es útil, pero es una mera ayuda en su inseguridad.

Ser humilde y amable con los consejos, y mejorarte a ti mismo hará maravillas para expresar tus instintos a nivel técnico. Te sentirás mejor y verás las cosas tal como son, porque podrás razonar. Es difícil enojarse cuando externalizas las críticas a un contexto técnico.