Necesita compilar un informe para la gerencia.

Escriba un documento breve que describa exactamente por qué el enfoque actual está llevando a la empresa por un camino peligroso (por ejemplo, ser atropellado por un autobús). Describa los riesgos de seguridad, tal vez incluso cite historias de advertencia dentro de su industria, con referencias a artículos, etc.

También incluya una lista de las formas en que el enfoque de este tipo está perjudicando su propio trabajo, así como el trabajo de sus compañeros de trabajo.

Por último, pero no menos importante, asegúrese de incluir una lista de recomendaciones que se implementarán de inmediato, como agregar el código al control de versiones para que todos lo vean y ejecutar el servidor en una máquina virtual a la que todos tengan acceso. Describa cómo estas medidas no deberían afectar de ninguna manera el trabajo de esta persona, y simplemente agregarán seguridad y transparencia a todo el proceso; deje en claro que no hay objeciones razonables a estas medidas.

Tal vez siéntese con su jefe cuando le entregue este informe y transmita verbalmente los temores exactos que ha escrito aquí: que este tipo está construyendo un imperio en la infraestructura de la empresa y que, en última instancia, es potencialmente peligroso . Si sus jefes sienten que esta persona puede volverse irrazonable, tal vez desee seguir el consejo de @BillLeeper y tomar el control de su máquina para que no pueda dañar su organización. Esto, por supuesto, será para que ellos decidan.

Este es un problema de gestión .

Antes de implementar el código crítico, se debe controlar la versión, revisar el código y, al menos, se debe documentar el uso. Si le preocupa la seguridad, elija a los revisores correctos y proteja el repositorio y los documentos. No hay ninguna razón por la que esto no pueda iniciarse de inmediato.

Hay un problema más grande que la seguridad laboral .

Cualquiera de estos desarrolladores podría introducir código malicioso en la empresa, ya sea por error o por sus propios motivos. En el peor de los casos, podrían cometer actos nefastos utilizando la situación que ellos mismos crearon (extorsión, sabotaje, espionaje industrial, etc.). En el mejor de los casos, su opacidad expone a todos a problemas de seguridad y siempre deja un signo de interrogación sobre cualquier auditoría o responsabilidad. Si algo sale mal, ¿quién puede decir que no estuvieron involucrados de alguna manera?

Desafortunadamente, no ha dicho realmente si alguien ha hablado sobre estas preocupaciones con el compañero de trabajo o la gerencia. ¿Es realmente malicioso? ¿O su colega es simplemente ciego? ¿O tal vez la gerencia es ciega?

Yo mismo he sido "ese" tipo.

En mi trabajo anterior, a veces tenía varias tareas secundarias para "hacer esta pequeña herramienta" o para hacer algo simple. Resulta que nunca hay recursos para el software interno... Por lo general, era algo como esto:

-- ¿Alguien puede ver las soluciones que elegí para decir si es apropiado? -- Vamos, solo necesitamos una herramienta simple que simplemente haga esta operación simple, hazlo y estará bien.

-- ¿Puedo crear un servidor virtual en nuestro servidor para esta cosa? - Hombre, es solo para uso interno. Solo póngalo junto con otras cosas en esa caja física rota. O póngalo en esa caja que no sabemos qué funciones. O póngalo en su propia estación de trabajo.

Por supuesto, nunca hubo recursos de tiempo para escribir documentos. A menos que elija hacerlo en mi tiempo libre. Por supuesto, todo lo que podía decir cuando algunas herramientas tenían problemas era "trabajando en ello".

Y entonces decidí dejarlo. Ese fue el primer momento en que alguien a mi alrededor se dio cuenta de que las herramientas "pequeñas internas" eran realmente importantes y que las cosas "simples" no son tan simples. Pasé un par de fines de semana escribiendo documentos para fastidiar menos a mis colegas. Ha pasado casi un año y todavía recibo múltiples llamadas cada mes sobre cómo hacer algo con mis herramientas internas.

Editar

Algunos comentarios han señalado que no debería ayudarlos de forma gratuita. Esto es generalmente correcto. Quería aclarar que no estoy dedicando horas de mi tiempo a resolver sus problemas, solo estoy dedicando un minuto a responder una pregunta. Técnicamente, sigue siendo cierto que estoy habilitando y fomentando las prácticas existentes. Por cierto, la empresa me ha ofrecido un puesto a tiempo parcial o pago por hora para resolver problemas como lo hice antes y lo rechacé.

La cuestión es que no estoy dispuesto a obligar a mis ex colegas a "investigar mejor" en lugar de simplemente preguntarme "¿En qué máquina se ejecuta Veeam?" si puedo simplemente decir el nombre o la dirección IP sin pensar o decir "Debería estar escrito en [..]". Además, una llamada telefónica de 2 minutos con un ex colega suele ser una distracción tan positiva y relajante como visitar stackexchange.

editar fin

Entonces, ¿qué puedo sugerir? Tu colega parece muy capaz, ¿no? Discuta esto con la gerencia. No digas "se está volviendo insustituible". Solo pregúntales: ¿y si se va? ¿Qué pasa si se enferma durante un tiempo prolongado? Convéncelos de que el problema es real. Deberían discutirlo con ese tipo ellos mismos para encontrar soluciones. ¿Quizás simplemente le faltan recursos? ¿Tal vez necesita a otra persona en el equipo de "software interno" para que todo sea agradable y bonito?

La mayoría de estas respuestas son MUY EXCESIVAS al asumir una intención maliciosa por parte del desarrollador en cuestión.

Antes de hacer una imagen subrepticia del servidor y luego sacar al tipo de la oficina, ¿por qué no tomar un respiro y tratar de entender qué está pasando?

Bien podría ser que la persona en cuestión esté sobrecargada de trabajo, no tenga suficientes recursos y esté más que dispuesta a compartir conocimientos. O tal vez lo ha estado haciendo de esta manera durante mucho tiempo y nunca ha recibido una indicación de que necesita hacer lo contrario. Como mínimo, especialmente si sus cosas FUNCIONAN, merece la oportunidad de resolver inquietudes y colaborar con sus compañeros de trabajo.

No veo evidencia de que se haya intentado nada de esto en la pregunta del OP. Antes de considerar opciones draconianas, intente comunicarse primero. Si la persona no tenía la intención de hacer daño, puede esperar su cooperación.

Hay algo que aún no he visto en las otras respuestas:

Casualmente empezar a buscar un nuevo trabajo

Por supuesto, esto se basa en la suposición de que ya ha hablado con su gerente sobre esto. Otras respuestas han brindado las razones por las que este no es su problema sino el de su gerente y también han brindado sugerencias sobre cómo abordar esta conversación con su gerente.

Ahora, estoy viendo la situación en la que ha hablado sobre esto con su gerente y luego, después de que ha pasado un tiempo razonable, no ha sucedido nada al respecto. Tiene la sensación de que su gerente no considera que esto sea un problema tan grande como usted sabe que es.

Ahí es donde es posible que desee comenzar a buscar un nuevo trabajo. No importa si su gerente simplemente no piensa que esto es un problema o simplemente no lo entiende lo suficientemente bien como para ver el problema, hay algo mal aquí. (Y no estoy hablando del código "privado", sino del problema de que el administrador no hace nada al respecto).

Tal problema es algo que probablemente no podrá cambiar desde la posición de un desarrollador. Sin embargo, hay otras empresas y no tienen los mismos problemas, por lo que es posible que desee buscar un empleador diferente.

Sin embargo, viéndolo desde el lado positivo, no hay demasiada presión sobre ti en este momento. Tienes un trabajo y no esperas perder ese trabajo. No tendrá que hacer concesiones para poder seguir pagando el alquiler, la hipoteca o los costos de vida. Puede simplemente comenzar a buscar casualmente y no renunciar a su trabajo actual hasta que encuentre el trabajo que realmente le gusta.

Todas las respuestas actuales y la mayoría de los comentarios actuales solo indican la situación actual o brindan sugerencias para tomar medidas extremas.

Solo para resumir: hay dos situaciones posibles: los compañeros de trabajo están haciendo esto intencionalmente, en este caso son maliciosos de una forma u otra, y entonces es necesario extremar la precaución. O los compañeros de trabajo simplemente no ven los problemas y peligros potenciales y reales que están causando, entonces son "amistosos" pero se les debe enseñar a hacerlo mejor.

Por lo tanto, la siguiente hoja de ruta intenta dos cosas al mismo tiempo: 1) Intentar minimizar el daño potencial que pueden hacer esos compañeros de trabajo, si son maliciosos, y 2) tratar de mantenerlos en la empresa (para que puedan convertirse en cooperadores). compañeros de trabajo en el futuro) si son amistosos:

(por cierto: lo sé, usted no es el jefe, pero con la información que otros han proporcionado, supongo que tendrá todo en sus manos para convencer a su jefe, para tomar este hilo muy en serio, por lo que esta hoja de ruta aborda lo que su jefe podrías hacer, no lo que harías. Lo único que puedes hacer es llamar la atención sobre tu jefe. btw2: Si tu jefe todavía no te escucha, busca un nuevo trabajo y retírate tan pronto como lo encuentres. Porque que los compañeros de trabajo son bombas de relojería, independientemente de si son amistosos o maliciosos, eso no importa en absoluto).

1.) Realice copias de seguridad silenciosas de todo lo que puede acceder. No apague los sistemas en el proceso, apagar los sistemas podría desencadenar algunos tipos de trampas explosivas.

2.) Construya una razón por la cual las estaciones de trabajo deben cerrarse. Si necesitas una idea, contáctame por privado.

3.) Extraiga los discos duros, haga una imagen completa, vuelva a colocarlos. Haga esto durante un fin de semana más o menos

4.) Si los sistemas tienen elementos de detección de intrusos a nivel de BIOS, y no puede eludirlos, construya otra razón, por qué se activaron esos sistemas de detección de intrusos.

Esos compañeros de trabajo están creando herramientas para cosas internas, ¿verdad? ¿Entonces no necesitan acceso a los sistemas de los clientes y similares?

5.) Si tienen acceso a los sistemas, no necesitan cambiar las contraseñas, asegurarse de que no haya ningún tipo de inicio de sesión de clave pública, verificar los puertos en busca de procesos que permitan un inicio de sesión no estándar. Verifique los trabajos cron/at, verifique inetd, verifique todo lo que se está ejecutando actualmente. Para cada pid, debe poder responder por qué se ejecuta ese proceso.

6.) Consiga un nuevo empleado (realmente nuevo, completamente desconocido. Debe ser un muy buen experto, porque debe ser capaz de hacerse cargo de su trabajo solo durante algún mes si fuera necesario. No puede simplemente tomar algunos estudiante graduado al azar (ni siquiera uno con la calificación más alta), necesita a algunos de esos muchachos, que nunca visitaron una universidad pero aún lo saben todo) e insértelo en ese equipo para apoyarlos. Especialmente porque están bloqueando a los otros trabajadores, se puede justificar fácilmente. Su trabajo oficial es apoyarlos, su verdadero trabajo es aprender cómo operan.

El paso 6 es especialmente importante, porque de esta manera, tiene la oportunidad de averiguar si esos compañeros de trabajo son maliciosos.

Si el chico nuevo se está integrando bien en el equipo, entonces puedes asumir que son amigables, ese chico nuevo debería poder implementar los cambios necesarios sin necesidad de decirles a esos chicos que ha habido alguna sospecha en su contra.

Si el chico nuevo se da cuenta, son maliciosos, pero lo integran, entonces su trabajo es seguirle el juego. Aprende todo, encuentra genial lo que están haciendo, y así sucesivamente. Págale el doble de dinero, porque tiene que trabajar dos veces, porque una vez que llega a casa, tiene que escribir todo lo que aprendió y enviarlo a algún equipo recién formado que debería hacerse cargo del trabajo tan pronto como se haya transferido suficiente conocimiento.

Si los tipos maliciosos no lo integran, entonces su única oportunidad es esperar, tiene suficientes datos respaldados (solo para el caso) y despedir a ese equipo. Entonces, es posible que necesite dos o más de esos súper expertos de los que estaba hablando anteriormente, para que un nuevo equipo ingrese a ese código muy rápido.

Espero que esta hoja de ruta ayude, al menos como fuente de inspiración sobre cómo manejar esto. Tal vez, en su empresa, tiene algunas opciones que no puedo considerar, tal vez, hay algunas diferencias culturales, por lo que aún debe pensar en esto y tal vez ajustar el plan.

Parece que hay algunos buenos remedios aquí para prevenir esto en el futuro, pero no qué hacer al respecto ahora.

1. Asegure la computadora. Haga que la gerencia y un experto en TI lo revisen cuando esté desbloqueado y desatendido, o vaya y exija que desbloquee la máquina y le conceda acceso. Entonces saca a este monstruo de la red. Haga una imagen inmediata del HD en caso de que tenga un interruptor de hombre muerto.

2. Despida a este individuo inmediatamente. Sal con él por la puerta. No te preocupes por la causa, habrá muchas pruebas en esa computadora suya. Si la empresa está preocupada, que su abogado haga su magia, para eso les pagan.

3. Reúne al equipo. Explique lo que pasó. Este individuo estaba actuando de manera imprudente y poco profesional. Puso en riesgo a la empresa y fue despedido por eso. Vamos a necesitar todos los recursos que tenemos para solucionar este lío.

4. Use el equipo para reconstruir y volver a implementar este trabajo de manera adecuada en máquinas seguras, etc. El equipo tendrá que revisar aplicación por aplicación y controlar las cosas. No se preocupe de inmediato por reescribir, solo asegúrese de que no haya puertas traseras, etc., luego obtenga los servicios en hardware nuevo y controlado.

5. Consiga a un experto en seguridad. Este tipo probablemente no se irá en silencio e intentará 'piratear' nuevamente para sabotear u obtener acceso a su sistema. También puede tener contraseñas globales para los sistemas con los que interactuó u obtuvo contraseñas individuales a lo largo del tiempo. TI debe activar un restablecimiento de contraseña forzado en todos los usuarios y bloquear cualquier acceso externo por un tiempo (como VPN).

Al programador en cuestión no se le debe dar ningún trabajo nuevo hasta que la situación se resuelva de una forma u otra. Todos los nuevos requisitos deben ir a otro desarrollador/equipo que debe seguir los procedimientos adecuados de control de fuente y revisión por pares (nuevas contrataciones si es necesario). El programador en cuestión puede mantenerse ocupado reparando defectos o "apagando incendios" de su legado existente. Se deben asignar recursos para aplicar ingeniería inversa al legado existente y volver a implementar mediante los procesos apropiados. El costo de hacer esto tiene que estar justificado por el riesgo existente: ¿cuánto le costará a la empresa si todo lo que ha hecho este programador se pierde repentinamente? O peor aún, ¿qué datos propietarios (de la empresa) son vulnerables a la pérdida frente a la competencia?

Quizá merezca la pena preguntarle a este empleado: "¿qué nos pasa si te atropella un autobús o decides hacer un crucero de un mes alrededor del mundo?" y mida la respuesta para decidir si entregará su código voluntariamente. Si coopera, no hay necesidad de que la situación se vuelva antagónica; si no hay señales de preocupación por la empresa de su parte, es hora de ocuparse de asegurar todo lo que ha tocado.

Este no es su problema, esta es la responsabilidad y el rol de los gerentes, usted es solo un compañero de trabajo y posiblemente no tenga toda la información necesaria. Me preocuparía más por mis propias tareas que por involucrarme con mis compañeros de trabajo. No veo cómo podría salir algo positivo de armar un escándalo por tu compañero de trabajo.

Te enemistarás con él, acusarás a tu jefe de incompetente y darás la impresión de que tienes tan poco trabajo que tienes tiempo para iniciar investigaciones internas sin que te lo pida ni tengas autoridad para hacerlo.

¿Cómo acercarse a la gerencia sobre esto?

Diga que la mejor práctica es no permitir esto, por muchas razones.

Los programadores profesionales deben saber que esta no es forma de administrar un negocio; y si los gerentes no saben nada más, al menos deberían saber eso (los programadores deberían decirle a los gerentes y/o los gerentes deberían decirle a los programadores).

Las razones son tan conocidas que no necesito decírtelo. Incluyen "respaldo", es decir, está en problemas si pierde al programador (o si lo reasignan a otra cosa), o si el programador pierde su máquina.

Al menos tiene el "control de versión de la empresa", por lo que no necesita pelear esa batalla; solo haga que sea un requisito de trabajo/proceso que realmente se use.

Probablemente no debería ejecutar software de producción en la máquina del desarrollador. Un primer paso podría ser insistir en que:

• Los usuarios no hacen conexiones de red a la máquina del desarrollador
• El software se ejecuta en/desde un servidor de producción
• El software que se ejecuta en el servidor de producción debe ser compilable por otra persona (o por una máquina de compilación), desde el control de código fuente

La implementación requiere que se registre el código fuente y se publiquen las instrucciones de compilación. Te sugiero que lo hagas como una semi-emergencia. No permita que el desarrollador tenga acceso de escritura al servidor de producción o a la máquina de compilación (para verificar que el código de producción se pueda compilar desde el control de versiones).

Una vez que haya hecho eso (después de saber que el código fuente está bajo control de versiones y que las instrucciones de compilación están publicadas), otros desarrolladores pueden pensar en inspeccionar el código fuente y ayudar a mantenerlo.

Tenga en cuenta que Deshágase del programador indispensable lo más rápido posible fue publicado por Gerald Weinberg en 1971 (así que, en realidad, todos deberían saber esto ahora). IIRC la cita original es,

"Si un programador es indispensable, deshazte de él lo más rápido posible".

No sé si solo eres tú u otros en la empresa, pero todos pueden ser reemplazados. Puede haber retrasos, pero puede y debe hacerse cuando las personas no hacen su trabajo. Sus gerentes no están haciendo lo suyo.

Estos desarrolladores están rompiendo casi todos los estándares básicos de codificación. La gerencia debe tener alguna idea de que algo anda mal, pero no hacen nada al respecto. No los veo como una solución a tu problema.

Necesitas tener seguridad laboral también. Si hay un error específico que necesita corregir, obtenga el código fuente. Si está en su computadora, dígales que lo copien en otro lugar. Si tienen derechos sobre los servidores de producción, quíteselo. Pueden ir y quejarse a la gerencia si quieren. Te estarán haciendo un favor y exponiendo su incompetencia.

Con suerte, alguien se dará cuenta de que todo el código debe estar centralmente ubicado y respaldado. Esta es propiedad de la empresa y todos los involucrados deben querer asegurarla. No dejes que se salgan con la suya con este lío. No tienen propiedad de nada y ni siquiera han mostrado la más mínima habilidad para supervisar la propiedad intelectual de la empresa.

La pregunta es, ¿cuántas ganas tienes de salir de este círculo vicioso? Porque no seamos monos con esto, le va a costar a la empresa.

1. La empresa tendrá que gastar dinero para contratar a alguien que escriba el código que controla la empresa.
2. La empresa tiene que exigir el código del codificador y respaldar esa demanda con ayuda legal si es necesario. Señalaré que el código fue encargado por la empresa, que el codificador obtuvo un cheque de pago de la empresa mientras escribía el código, por lo que el código es de la empresa. Si el codificador no produce el código, en el peor de los casos se consideraría robo, lo que constituiría un delito penal.

La libertad no es gratuita. Si la empresa no está dispuesta a gastar recursos para liberarse de este individuo, entonces todo lo que está haciendo es agitar las encías. Todos ustedes van a tener que enfrentar la situación, porque si el codificador se aleja o lo atropella un camión, la firma es SOL.

Considere la razón por la que están haciendo esto. Es muy posible que se estén tomando atajos para ajustarse a las limitaciones de tiempo, los objetivos de rendimiento y las demandas en constante aumento. Esto a menudo conduce a una deuda técnica y a un codificador muy estresado que no tiene más remedio que solucionar todos los problemas desde el principio.

Es posible que esta persona esté escribiendo cosas de una manera que solo ellos pueden arreglar porque no tienen tiempo para documentar, crear versiones y mantener el código de manera oportuna. Confía en mí cuando digo que esto tiene un efecto completamente negativo en cualquiera que se encuentre en esta posición. No es un papel cómodo donde alguien puede sentarse y relajarse.

Si, como sugiere su título, no están resolviendo problemas, no habría problema. Simplemente tirarías al codificador, con todo su código, porque es inútil.

Prevenir situaciones como esta es una tarea de gestión extremadamente básica. De ello se deduce que la dirección que es consciente del problema no es competente, y la dirección que es competente no es consciente.

Desafortunadamente, desenredar situaciones como esta es una tarea de gestión difícil. Entonces, dado que los gerentes a cargo de este desarrollador ni siquiera fueron capaces de prevenir la situación, no cuente con que puedan solucionar la situación.

La única* forma de solucionar esto es ascender a un nivel superior de gestión. Si están interesados ​​y pueden solucionar esto, ni siquiera tiene que explicar nada más de lo que nos explicó a nosotros, simplemente hágalo menos personal centrándose en los programas y los problemas con ellos, en lugar del programador.

Debe saber que esta es una opción de alto riesgo y baja recompensa . Si hace esto, incluso si funciona, el desarrollador y su gerente (que probablemente también sea su gerente) sufrirán y sabrán que usted es el responsable. El único beneficio que obtiene al hacer esto es que (posiblemente) está siguiendo su propio código de ética y honor, pero podría perder su trabajo por ello. Es por eso que algunas de las otras respuestas recomiendan dejarlo ir o simplemente buscar un mejor trabajo, que es lo más inteligente.

* La otra forma de arreglar esto es convertirte en administrador y arreglar esto, pero hay bastantes escollos involucrados.

Después de su propia autoevaluación, ha decidido que no tiene la oportunidad de ser promovido y que la única razón por la que la empresa tendría que retenerlo es que les está ocultando el código.

No sé si está de acuerdo con esto, pero si lo está, probablemente alguien mejor podría hacer el código. O si no explica por qué este comportamiento asegura que nunca podrá ser ascendido.

Creo que se trata tanto de si vale la pena arreglar esta situación como de cómo arreglarla.

Esta es una tarea de la gerencia. Primero, la gerencia debe tratar de descubrir si esto es intencional. Si es así, se debe hacer un plan para despedir a las personas infractoras. Si no es intencional, se debe hacer un plan para capacitar a las personas infractoras.

Ellos diseñan sus programas... para que sean poco a poco más difíciles de reemplazar.

¡No si yo fuera el jefe!

Hay dos problemas aquí:

1. Mal programador.

2. Gestión incompetente.

Esto es, por supuesto, asumiendo que estás representando la situación correctamente.

No puedes arreglar el problema #1. Existe una pequeña posibilidad de que pueda abordar el problema n.° 2. Esta pequeña posibilidad es si el jefe, por alguna razón, simplemente no está al tanto de lo que está sucediendo. Vaya con el jefe y cuéntele los problemas que ve y por qué son malos para la empresa. Es probable que eso falle porque el jefe ya conoce el problema y no es competente para abordarlo, o sabe tan poco sobre el software y la gestión de ingenieros de software que ni siquiera es competente para comprender el problema.

La única solución real es comenzar solucionando el problema n.º 2, en el que, en el mejor de los casos, puede desempeñar un papel menor. El gerente incompetente debe ser reemplazado.

Luego, el nuevo gerente se sienta con este programador, le pide que explique la arquitectura y le dice que detenga cualquier desarrollo nuevo y documente todos los protocolos. Mientras tanto, consigue un nuevo ingeniero que está allí para "ayudar" al primer ingeniero a documentar los protocolos, poner el software en control de código fuente y asegurarse de que el código en sí esté bien documentado. Este nuevo ingeniero realiza cualquier nuevo desarrollo y, con suerte, corrige errores y realiza mejoras menores del software existente.

Al primer ingeniero no le gustará esto. Puede renunciar, hacer una rabieta, objetar ruidosamente o, peor aún, sabotear las cosas. Es por eso que hacer una copia de seguridad es la primera orden del día. Sería bueno tener una transición suave del primer ingeniero al segundo, pero no espere que eso suceda. El plan es eventualmente despedir al primer ingeniero, si no renuncia o se vuelve (aún más) destructivo contra la compañía primero.

Simplemente no puedes dejar que estas tonterías continúen. Cuanto más lo haga, más doloroso será finalmente arreglarlo. No arreglarlo porque ya será doloroso es absolutamente la forma incorrecta de pensar sobre esto.

En este caso estaba usando el retórico "tú". Para responder a la pregunta de qué puede hacer usted personalmente, comience por llevar sus inquietudes al jefe, como dije anteriormente. Una vez más, es poco probable que resulte en algo útil.

El siguiente paso depende de cosas que no nos has dicho. Puede ser muy peligroso pasar por encima de la cabeza de tu jefe. Si es así, poco más puedes hacer aparte de evaluar si realmente quieres seguir trabajando allí. Si se trata de una empresa lo suficientemente pequeña en la que puede hablar cómodamente con la alta dirección, entonces adelante. Es muy posible que la gerencia superior ya tenga la sensación de que el administrador de software de bajo nivel es incompetente, pero por supuesto no le dirán eso. Esta podría ser la información adicional para que tomen medidas más decisivas.

Otra posibilidad lejana, si su objetivo principal es arreglar este lío y se ve a sí mismo como un trabajador a largo plazo en este lugar, es ofrecerse a asumir parte del desarrollo de herramientas internas usted mismo. Eso debería darle una razón legítima para hablar con el primer ingeniero, comprender cómo funcionan las cosas, dónde vive el código, etc. Eventualmente, usted será el encargado de las herramientas y la gerencia puede deshacerse del primer ingeniero. Luego, puede pedirles que contraten a alguien para ese rol para que pueda volver a hacer la transición a lo que quiere hacer. Nuevamente, esto no es algo que esté sugiriendo seriamente, pero es una alternativa si realmente quieres y estás dispuesto.