Soy referente técnico pero perdí el liderazgo en decisiones técnicas

Esta línea destruyó mi confianza en los líderes de su empresa:

No más desarrollo basado en pruebas y no más pruebas unitarias.

Esa es una mala decisión, no puedo imaginarme trabajando en un lugar que se comporte o crea eso. Desperdiciará de 10 a 100 horas corrigiendo errores, porque quieren ahorrar 1 hora al no usar el desarrollo basado en pruebas o las pruebas unitarias.

Eso es mala programación, mal negocio y delata una falta de comprensión del pensamiento sistémico. No se puede confiar en esas personas. Son incapaces de tomar buenas decisiones de manera confiable en CUALQUIER área del negocio.

Sin el pensamiento sistémico, los líderes a la larga te harán daño.

Sal ahora.

Recuerde que la codificación no existe en el vacío. Incluso el código que es menos que ideal puede resolver problemas empresariales o humanitarios reales.

La calidad no es una propuesta de todo o nada. Sin duda, hay situaciones en las que un equipo es tan joven que la introducción de complejidades puede matar la productividad y la moral, y no cumplir ni siquiera con los objetivos básicos de todo el proyecto.

Supongo que usted mismo no comenzó su carrera haciendo TDD, simulación, programación de interfaces, inyección de dependencia, composición sobre herencia, control de versiones distribuidas y cosas por el estilo.

Trate de comprometerse. Haga un plan con los jefes para introducir prácticas modernas de desarrollo de software a lo largo del tiempo. Ofrezca enseñar al resto del equipo sobre estos principios, utilizando tutoría individual, almuerzo y aprendizaje o capacitación autodirigida.

Vea si hay características agradables que el equipo pueda usar para experimentar con técnicas que son más nuevas para ellos, donde supervisaría la calidad del código, las revisiones, la aprobación de las pruebas y cualquier otra cosa que considere necesaria.

Se trata de encontrar un equilibrio entre la productividad inmediata y las prácticas de desarrollo sostenible a largo plazo.

Eso, por supuesto, tomará tiempo y tendrá que determinar si ese tiempo vale su inversión personal. Si los jefes no están dispuestos a comprometerse, es probable que esa decisión se tome por usted.

He peleado esta batalla más de dos veces.

Esto es lo que se dará cuenta en algún momento: ningún ejecutivo quiere admitir (y probablemente incluso a sí mismo) que está produciendo basura. O enfrentarán el dolor y realizarán los cambios necesarios para producir un buen producto, o "justificarán" la decisión con una combinación de problemas sobre una crisis presupuestaria y racionalizaciones irracionales como las que describió anteriormente.

La organización ha hablado, y no se puede luchar contra esto Y entregar un buen producto al mismo tiempo.

O haces las paces con poner tu nombre en algo que sabes que no está a la altura de tus estándares, o encuentras un lugar en el que tus talentos y estándares serán de beneficio.

No es su producto, básicamente necesita conformarse o seguir adelante.

Como autónomo, deberías haber experimentado esto antes. Tienes que trabajar dentro de lo que te permita la gente que te paga. Es obvio que no les gusta tu estilo de liderazgo y eres perjudicial para su equipo, así que después de revisar sus opciones (sin ti), esto es lo que se les ocurrió.

Asegúrese de que le paguen e intente marcharse en buenos términos cuando esté listo, pero no se enoje por un producto que no es de su propiedad.

Solo una sugerencia, pero las habilidades de programación no lo son todo cuando se trabaja con un equipo en cualquier tipo de función principal. Es posible que te vaya mucho mejor si buscas proyectos en solitario que realmente puedan hacer brillar tus habilidades. Esta es una de las razones por las que a menudo rechazo trabajos que involucran a un equipo desconocido que no podría hacerlo por sí mismo (si fueran competentes y eficientes, no me necesitarían). Prefiero empezar de cero, ya sea solo o con mi propio equipo. Menos dolores de cabeza y más satisfacción laboral (más dinero también por lo general).

Pon tu dinero dónde está tu boca. Abandonar.

Renunciar al puesto informando a toda la cadena de gestión que no puede cumplir con lo que se le contrató y, como tal, como trabajador independiente, prefiere renunciar al contrato que apoyar un esfuerzo de desarrollo por debajo del estándar. Infórmeles que se trata de un incumplimiento de contrato (suponiendo que usted haya sido contratado para tomar esas decisiones) y, como tal, no ve justificado perder su tiempo, y su dinero, en su salario.

No hay mucho que puedas hacer. A menos que tenga motivos ocultos (necesite el dinero para otros proyectos), esa es la forma más sincera de manejar esto, dado que personalmente lucha con cómo va el proyecto.

Alternativamente, póngase en contacto con un nivel más alto e intente encontrar una manera de hacer que las cosas funcionen a un nivel aceptable. Sin embargo, es posible que trabajen con personas que prefieren voltear hamburguesas en McDonalds, visto eso en muchas compañías más grandes. Una vez me contrataron para enseñar C# a los desarrolladores de VB. Un plan de estudios de un mes condensado en 3 días ("no podemos tenerlos sin trabajar durante un mes, y todos son desarrolladores experimentados"). Bueno, los desarrolladores experimentados no conocían la diferencia entre una matriz y una tabla hash/diccionario en un nivel fundamental, por lo que se desperdició todo el tiempo. Ese es el nivel en algunas empresas.

No puedes luchar contra eso. El pescado comienza a apestar desde la cabeza, que es la gestión. Lo pagan, con el tiempo. Pero no es tu trabajo cambiarlo. Si no puedes soportarlo, vete.

Me centraría en cosas diferentes. Porque:

No más desarrollo basado en pruebas y no más pruebas unitarias.

Esto apesta pero es comprensible. Es un gran cambio de paradigma y se adapta mejor a un proyecto nuevo que a la continuación de uno antiguo.

No hay revisiones de código tan exigentes.

Eso también es comprensible. En mi humilde opinión, el nivel de exigencia debe aumentarse gradualmente para que las personas aprendan nuevas habilidades.

Algunos copian y pegan de la versión anterior de la aplicación, con el fin de ir rápido para otros desarrolladores.

Eso es comprensible y puede estar bien, si esas viejas piezas de desorden se separan bien del resto del proyecto.

Ahora, ha enumerado las cosas que han dejado caer, pero la lista no se puede juzgar sin saber cuánto de sus recomendaciones se quedaron en su lugar. Si esos 3 fueron los pilares de tu metodología, no queda nada de tu diseño y eso es malo. Si esos fueran solo 3 de 15, entonces la mayor parte todavía está en su lugar y eliminar esos 3 es realmente lo que dice en la etiqueta: amortiguar el impacto para los programadores restantes.

Pero la otra parte es la más alarmante para mí:

Tuvimos una reunión (sin mí, por lo tanto), y dejamos caer algunas metodologías que recomendaste.

Te pidieron que diseñaras algo y luego modificaron el diseño sin consultarte. Esa es la bandera roja. Ya sea para ellos o para usted, porque podría ser usted quien simplemente se niegue a escuchar sus argumentos hasta el punto de que tengan que emitir una orden directa.

Si estima que han abandonado la mayor parte de su plan, puede significar que no entienden nada. Quieren que su código mejore, pueden pagar su salario, pero no pagarán el costo real: el esfuerzo. Es como un tipo que compra suplementos de proteína con la vana esperanza de que un producto le dará músculos mágicamente sin hacer ejercicio. Los suplementos proteicos no funcionan así y tampoco eres un producto mágico que puede arreglar su proceso sin cambiarlo. Es aterrador cuántas personas piensan que las balas mágicas son reales.

Por otro lado, la producción de software comercial no se esfuerza por lograr la perfección absoluta, es solo suficiente esfuerzo (lo que significa tiempo, lo que a su vez significa dinero) invertido en la perfección hoy para ahorrar aún más esfuerzo (léase: tiempo, léase: dinero) en el largo plazo. Cada reparación cuesta dinero y es justificable solo si dejar el error cuesta aún más. Lo que realmente necesitas para ser bueno es el compromiso. No todos están hechos para el trabajo (ciertamente, ser demasiado perfeccionista no ayuda), la única forma de averiguarlo es probarlo.

Depende de usted decidir si la cantidad de libertad de diseño restante es suficiente. Si cree que lo han contratado para hacer un trabajo y ahora le dicen que no puede hacerlo, quedarse allí puede ser una pérdida de tiempo para todos.

Siempre puedes tratar el trabajo como una lección. Aléjate, observa y aprende. Incluso si eres técnicamente perfecto, aún necesitas la habilidad de "trabajar con otras personas". Diablos, trabajar con personas que no son tan buenas como tú requiere aún más de esa habilidad.

No me concentraría demasiado en las decisiones que se tomaron. La información importante aquí es: se encargaron de tener una reunión sin usted sobre cosas que eran de su responsabilidad. Muestra una pérdida de confianza en ti.

Necesitas entender de dónde vino eso en primer lugar. Te ves técnicamente adecuado considerando lo que se te pidió: los convenciste como tal. Pero no te contrataron porque eres técnicamente bueno, te contrataron para solucionar un problema que tenían y pensaron que podías hacerlo.

Puedo ver varios problemas que podrían ocurrir con esta disonancia (el hecho de que creas que te contrataron por una razón, en comparación con la verdadera razón):

1. Falta de goles:

   • ¿Te dijeron lo que esperaban de ti?
   • ¿Preguntaste qué querían?
   • ¿Te perdiste algo que te dijeron?
   • Tal vez haya escuchado: "¡Queremos software de calidad!" cuando querían decir "¡Queremos un software que la gente use!".

2. falta de transparencia: llegas a este nuevo trabajo y aplicas todas las mejores prácticas conocidas en tus campos.

   • ¿Cómo se comunicó al respecto?
   • ¿Fuiste demasiado rápido?
   • ¿Todo el mundo era consciente de las consecuencias porque siempre hay una compensación?
   • ¿Explicó que la curva de aprendizaje perjudicará la productividad?

3. Apoyo desde abajo: Su metodología impactó la vida de su equipo, necesitan estar convencidos de que van en la dirección correcta.

Solo puedo especular en este punto, pero puedo ver por qué, en el espacio de unos pocos meses, los desarrolladores se asustaron porque no ven el valor agregado (todavía) de los cambios y sus jefes se asustaron porque las funciones no están disponibles. tan rápido como pensaron que lo harías y los desarrolladores se están vengando de ellos, descontentos.

Debe aprender de esta experiencia para la próxima vez, ya que las cosas están bastante avanzadas en su caso.

Pero si algo hay que salvar es la confianza y la paciencia. Si algo,

• Siga la corriente reconociendo los problemas que plantearon.
• Acepte la mayoría de sus cambios y agregue sus puntos más valiosos (solo con la condición de que vea un futuro aquí)
• Haga un cronograma para reintroducir las mejores prácticas de manera lenta pero segura, explicando qué problemas están solucionando esos métodos (no se necesitan paracaídas en los automóviles, pero un cinturón de seguridad puede ayudar;)

Convence a la gente para que esté de tu lado, cueste lo que cueste, porque si no puedes hacerlo, tu batalla está perdida.

No estoy seguro de los detalles exactos de su situación, pero creo que tener experiencia técnica y poder liderar un equipo para hacer las cosas de una manera específica son dos cosas separadas. El libro 'Extreme Ownership' profundiza en la dinámica del equipo, tal vez sea útil.