TL;DR: El cofundador de la empresa quiere hacer un "trabajo real", pero hace más daño que bien.
La empresa es una casa de software con sede en el Reino Unido, tiene unos ~20 empleados, obtiene ganancias estables, paga bien y ofrece excelentes condiciones de trabajo (atmósfera amigable, beneficios, etc.).
Me contrataron hace 3 meses para iniciar un proyecto nuevo, ambicioso y de largo plazo. Actualmente hay un total de 3 personas involucradas en el proyecto: un especialista más y un gerente senior (cofundador de la empresa). No hay roles de gerente: todos hacemos el 'trabajo real' y todos somos iguales (por ejemplo, las decisiones se toman por votación).
El problema es que el cofundador no es un programador competente. Puede que lo haya sido alguna vez, pero probablemente perdió tracción a lo largo de los años de no trabajar como desarrollador de software. Habla felizmente de cosas de poca importancia (por ejemplo, el estilo de codificación), pero cuando se trata de codificación, comete errores terribles. Estoy cansada de revisar dos veces cada pieza de su trabajo.
No puedo quejarme de él como persona (por ejemplo, no muestra signos de mala educación, celos, etc.), simplemente carece de habilidades. Es por eso que normalmente corrijo sus errores en secreto durante las fusiones, pero sospecho que esta no es una solución adecuada a largo plazo.
Dado que obviamente NO estoy en condiciones de aconsejarle, ¿cómo debo proceder? ¿Debería hablar con él? ¿O mejor dejarlo ir y esperar el desastre? Si eso importa, estamos hablando de un área de desarrollo de software estrechamente especializada y el tipo en cuestión es unos 10 años mayor que yo. Él también es un graduado de CS.
EDITAR: respondiendo las preguntas en los comentarios: trabajamos en un nicho, tecnología bastante difícil. Los errores mencionados son errores simples, como usar variables no inicializadas.
Lo bueno es que las cosas de poca importancia generalmente se pueden automatizar, especialmente el estilo de codificación. Vea cuánto de eso puede manejar su sistema de compilación. La introducción de un monitor de calidad de código (es decir, Sonarqube o similar) generará grandes dividendos en el futuro, especialmente en un proyecto joven como el suyo.
Demostrar que el código está roto. Al arreglar las cosas en secreto, tú
No está en condiciones de aconsejarle, pero puede señalar el problema y dirigir la discusión hacia donde desee.
Para cosas pequeñas como variables no inicializadas, un monitor de calidad de código o un analizador estático serán extremadamente útiles. Una vez en su lugar, solo es cuestión de acordar el nivel de calidad del código que desea para el proyecto.
Para problemas más grandes, crearía una prueba unitaria o un ticket para cada error que encuentre. Una vez que tenga un montón de estos, señalaría la pila creciente y preguntaría cómo planeamos abordarlos. Ahora es un buen momento para presentar Scrum si eres fanático.
Dependiendo de la dinámica de la relación, es posible que aún haga la mayoría de las correcciones usted mismo, pero él estará al tanto del problema y podrá estimar el costo del tiempo si alguna vez lo necesita.
Finalmente, para ser honesto, suena como un tipo que puede aceptar las críticas, así que también exploraría eso. Introduzca solicitudes de extracción y revisión por pares en su flujo de trabajo y vea cómo funciona.
No todos piensan que necesitan monitores de calidad de código. Si no puede venderlo directamente, es posible que deba dedicar tiempo extra para configurarlo y luego señalar la gran ayuda que ha sido y proponer adoptarlo. Una vez más, su kilometraje variará según su jefe; en mi experiencia demostrar siempre es mejor que vender (pero soy un pésimo vendedor).
escudo rojo
erik
aakashM
neuromante
erupción solar