¿Cómo les digo a mis colegas que el código base que han creado es un desastre total y que sus prácticas son antiguas?

tl; dr

Esto no es un problema técnico, es un problema de personas. Trátelo como tal.

¡No voy a cambiar nada!

Ha tenido un comienzo realmente malo y no tiene nada que ver con el código.

Parece que le faltan habilidades con las personas. No comienzas a cargar en un nuevo trabajo diciéndole al equipo actual lo malos que son.

A la gente no le gusta el cambio. Y realmente no les gusta del "chico nuevo".

Quiero comenzar desde el nivel bajo (por ejemplo, "este fragmento de código es lento/incorrecto/ineficiente") y luego pasar lentamente al nivel alto (por ejemplo, iteraciones frente a cascada). Pero temo que piensen que los estoy atacando, lo cual no es el caso.

No estoy seguro de en qué cultura vives, pero decirle a alguien "este código está mal, yo soy mejor y deberías hacerlo de esta manera" siempre será un ataque.

¿Qué hacer?

1. Deja de pensar "yo contra ellos". A menos que planee renunciar, usted es parte de este equipo. No son esos "desarrolladores horribles" contra "yo, la superestrella" y si le comunicas esto a tu equipo, vas a tener problemas. Nadie respetará tus ideas. No importa si el equipo trabaja como individuos. Sigue siendo un equipo e incluso lo describe como tal.
2. Averigüe si se están cumpliendo las expectativas. ¿El equipo cumple con las expectativas/deseos del gerente? Si es así, no vas a encontrar mucha motivación de nadie para mejorar. "Si no está roto, no lo arregles". Pero si el equipo tiene dificultades para cumplir con los objetivos de rendimiento, entonces tiene una forma diferente de abordarlo y puede presentar todo como "oye, no estamos cumpliendo con los plazos. ¿Quieren intentar cambiar esto? Creo que hacer X podría ayúdanos a hacerlo".
3. Tú no eres el gerente, tu jefe lo es. Parece que desea administrar todo el proceso usted mismo. Esto funciona muy bien, para gerentes/líderes de equipo. Obtener la opinión de su jefe es importante.
4. A la gente le importan más los resultados que los sentimientos confusos. Su gerente se preocupará mucho más por su perspectiva si realmente demuestra por qué lo que está diciendo es mejor que el estado actual. No solo "¡porque Internet lo dijo!" pero en realidad a través de la demostración.
5. Pide ayuda a la gente. Encuentre formas de generar confianza en el equipo. Pedir ayuda/orientación es una manera muy fácil de hacer esto. Incluso si es menor, hazlo con tu equipo. Te respetarán mucho más si realmente demuestras que escuchas sus opiniones.
6. Predicar con el ejemplo. Las personas que no quieren cambiar normalmente no asimilan nueva información y dicen "sabes que tienes razón, nunca consideré que la forma en que lo estaba haciendo era inferior, ahora estoy iluminado y cambiaré mis formas". Las personas cambian cambiando cosas pequeñas, lentamente, de manera sostenida. Puedes demostrar esto.
7. Elige tus batallas sabiamente. Su ejemplo parece que su problema fundamental es que el equipo tiene personas que son malas en su trabajo. ¿Es realmente tan malo si el código es ineficiente? ¿Está realmente afectando el rendimiento final? O sería importante centrar el próximo proyecto en iteraciones frente a cascada (tenga en cuenta que si se enfoca en los tipos de cosas ágiles frente a cascada, es mejor que su jefe se involucre).

Este no es el enfoque correcto. Todo lo que harás es alienar a tus compañeros de trabajo. ¿Cuánto te gustaría que alguien se encargara de analizar todos tus errores?

Su mejor apuesta es trabajar con su gerente o supervisor, y la forma en que lo hace es importante. En lugar de señalar todas las cosas que sus compañeros de trabajo están haciendo incorrectamente, debe preparar cuidadosamente una lista de las formas en que cree que se podrían mejorar sus procesos y cómo se beneficiaría su empresa. En otras palabras, no ataque a las personas: señale lo que está mal en sus procesos y las formas en que el equipo podría mejorar si esas cosas se arreglan.

Si el gerente ve y comprende el valor detrás de lo que está diciendo, es probable que tome medidas; tal vez no sea la acción exacta que desea, pero es probable que las cosas mejoren. De lo contrario, puede continuar tratando de liderar por inspiración y, con suerte, las cosas mejorarán por sí solas. Sin embargo, si desea preservar algún tipo de relación laboral con sus compañeros, no intente decirles cómo trabajar si la forma en que trabajan no es su responsabilidad.

Definitivamente no comenzaría en un nivel bajo: "este código es ineficiente" o similar. Eso solo va a causar mucha actitud defensiva por muy poca ganancia.

Mezclar y combinar un proyecto ágil y un proyecto en cascada es increíblemente difícil. La gente de la cascada quiere establecer la interfaz entre sus proyectos (formato de archivo, diseño de tabla, API, lo que sea) por adelantado, luego salir y escribir en esa interfaz. Desea comenzar con la interfaz más simple posible, las piezas que sabe con certeza que necesitará, y luego acudir a ellos diciendo que necesita agregar o cambiar algo y hacer que reaccionen. Para ti, esto es responsable, ágil y rápido, porque no pasaste una eternidad discutiendo sobre el diseño en un momento en el que no podías saber las respuestas. Para ellos, esto es vaquero, sacudiéndolos, cambiando constantemente el suelo debajo de ellos. Es una receta para el desastre.

Le sugiero que plantee esta dificultad a la siguiente persona con la que tenga que trabajar. Háblenlo y decidan juntos si primero diseñarán completamente su superposición/interacción juntos, o comenzarán de manera simple y estarán preparados para cambiarlo a medida que avanzan. realmente escuchaa la resistencia que obtienes del otro revelador. No se equivocan automáticamente. La agilidad es genial cuando eres dueño de todos tus límites, pero puede causar trabajo extra cuando no los tienes. En algunos proyectos, ese trabajo adicional aún es menor que los días o semanas de especulaciones y discusiones que llevaron a la creación de un diseño subóptimo con el que estabas atrapado. Pero no en todos los proyectos. En este caso, podría tener sentido diseñar completamente el límite entre usted y el otro desarrollador antes de que alguien comience. Entonces adelante, sea ágil dentro de su silo.

Para el problema más amplio, que cree que (a) escriben código de mala calidad, (b) deberían ser ágiles como usted, (c) deberían usar una base de herramientas coherente y moderna, y (d) deberían hacer más pruebas y compartir más código entre proyectos - pise con mucho cuidado aquí. Has intentado simplemente ser genial y ver si quieren copiarte, y no lo hacen. No está del todo claro para mí que usted vea los beneficios para ellos de mantenerse en la forma en que han estado. Nunca los persuadirás para que cambien de actitud sin comprender por qué (más allá de la inercia) no lo hacen. Probablemente también necesitará el apoyo explícito de su gerente para liderar una unidad de "mejores prácticas" que cambie drásticamente el código existente y enseñe a estos desarrolladores cómo hacerlo a partir de ahora. ¿Hacerlo por tu cuenta? Simplemente van a seguir ignorándote porque no

He tratado de apegarme a los siguientes principios en mi pasado, y pareció funcionar bien:

• Me obligué a comenzar con un "período de aprendizaje tranquilo": durante unos meses más o menos,

  Cálmate y aprende. No juzgues nada. Intégrate en el equipo y en la empresa. Se Productivo. Generar confianza y reputación. Demuestra tu competencia.

  (Supongo que ya has probado una toma similar también). A menudo ves cosas que crees que son malas, pero unas semanas más tarde aprendes por qué son como son.

• Si nota problemas o enfrenta cosas que cree que no son óptimas,

  Recopilar datos: horas dedicadas a un cambio simple, errores que aparecen, correos electrónicos molestos que se envían, etc.

  Cualquier cambio que planee sugerir necesita hechos para demostrar que es necesario y útil. Me gusta tomar notas en mi "diario" personal (uno de esos viejos libros en blanco hechos de papel real).

  En uno de mis proyectos tuve la sensación de que hacer un cambio era muy caro sobre todo porque no había pruebas automatizadas y las pruebas manuales eran muy engorrosas. Así que hice un seguimiento de las horas que pasé en cada tarea, manteniendo las horas para la implementación real separadas de las horas de prueba.

• Después de un tiempo tus observaciones (o notas) te ayudarán

  Obtenga una imagen clara de cuáles son los principales problemas. Localízalos (¡solo!)

  No puedo imaginar que puedas hacer eso "de abajo hacia arriba" como mencionaste. Es más bien de arriba hacia abajo: surge un problema y tratas de encontrar la causa raíz.

• Solo aborde un problema a la vez. Utilice los datos que tiene a mano e intente

  Elaborar una sugerencia para mejorar este tema,

  mostrando el problema y la ganancia potencial al usar sus datos. Utilice un buen momento y elija la forma menos ofensiva. Además, trate de sugerir un cambio lo más pequeño posible con el mayor impacto positivo. Los pequeños cambios tienen muchas más probabilidades de ser aceptados/aprobados por el equipo que los grandes.

• Nunca señale con el dedo. Conviértase en un amigo valioso de cada miembro de su equipo.

  Tú también cometes errores, por cierto. Y supongo que, la mayoría de las veces, las cosas malas que encuentras no han sido "hechas" por un "chico malo". Han evolucionado porque no se cuidó lo suficiente de impedirlo. Siempre es un buen consejo no culpar a las personas por un problema, sino abordar los procesos, la forma en que el equipo trabaja en conjunto, etc.

Bienvenido al mundo de los negocios.

El cambio lleva tiempo. En una gran empresa, puede tomar décadas si lo que tienen funciona lo suficientemente bien (y de hecho puede haber sido líder en la industria hace años cuando adoptaron esas prácticas). Trabajando para IBM, sigo usando algunas herramientas cuyos back-end se remontan a la era de la "pantalla verde", porque SÍ funcionan, están muy integradas con otras herramientas (y, por lo tanto, son difíciles de reemplazar individualmente) y porque nadie ha encontrado fondos y tiempo suficientes para invertir en el cambio de una manera que no implique un riesgo inaceptable.

Cuestiones similares también se aplican al nivel de la práctica comercial. Cambiar de herramienta implica un riesgo... ya sea el riesgo de subestimar el costo y no cumplir con sus compromisos, o el riesgo de sobreestimarlo y parecer que no fue lo suficientemente agresivo. La gerencia quiere poder hacer predicciones, por lo que pueden tener miedo de comprometerse de cualquier manera y quedarse con lo que tienen.

El cambio puede venir, pero tiene que empezar de a poco y construirse hacia el exterior. Empiece dando un ejemplo de cómo el nuevo enfoque le ayuda a USTED, durante un período prolongado. Eventualmente, tiene suficiente evidencia para convencer a un líder de equipo para que lo intente en un grupo pequeño (o se convierte en un líder de equipo que puede hacerlo), de una manera que no afecte negativamente al resto de la empresa. Construya hacia afuera desde allí. Espere que el cambio tome tiempo; los acorazados no arrancan, paran ni giran muy rápidamente.

Lo mismo ocurre con la calidad del código y las prácticas de codificación. Recuerde que la coherencia (ser capaz de leer y mantener el código de los demás) triunfa sobre la belleza y aprenda a trabajar con el estilo de codificación que prefiera. (Un buen programador puede leer casi cualquier estilo, aunque el tipo que pensó que los puntos y comas debían estar al principio de las declaraciones puede haber sido una excepción). Recuerde que si está manteniendo el código de producto existente, debe minimizar el riesgo de introducir nuevos errores, lo que significa que se prefieren los parches locales a menos que pueda demostrar razones FUERTES de que los parches más grandes serán más fáciles de crear, más fáciles de mantener y tendrán beneficios para los clientes. Para poner eso en perspectiva, recuerde que muchos clientes ejecutan código antiguo en lugar de la última versión, y actualizan solo cuando es absolutamente necesario, precisamente porque no son

Y, sí, los parches mínimos se suman a un código feo. Eventualmente, eso se arregla, pero no antes de la próxima versión principal y no a menos que haya un problema real con el código anterior.

Cuando llegue la oportunidad de implementar algo nuevo, ENTONCES puede considerar impulsar las ventajas de un nuevo enfoque. Pero el mantenimiento, por definición, está en deuda con los procesos antiguos y cambia muy lentamente. Desafortunadamente, las mejores prácticas académicas tardan mucho en adoptarse... y, a menudo, cuando lo son, algo más es lo último y lo mejor.

Realice un pequeño cambio a la vez, hasta que esté en posición de implementar cambios más grandes. Muestra, no solo cuentes. Sea paciente y persistente. Recuerde que las cosas son como son porque SÍ funcionan, y aprenda a operar el sistema actual lo suficientemente bien como para poder explicar exactamente cuáles serían los beneficios y los riesgos de cambiar.

O haz lo de alto riesgo de comenzar tu propia empresa y hacer las cosas a tu manera... lo que te enseñará rápidamente por qué todos están tan nerviosos por los riesgos que aún no saben cómo cuantificar; un joven punk vendrá con el enfoque de moda de esta semana y tendrás que explicarle que la compañía necesita esperar una oportunidad limpia para cambiar... y mientras tanto necesitas que él trabaje en lo que tienes ahora , y si no puede hacer eso, no tiene futuro en la empresa.

Buenas respuestas hasta ahora, especialmente de Roger, Enderland♦ y Kate Gregory, pero me gustaría agregar algo más.

TLDR

Comience con las metodologías de alto nivel porque darán como resultado una mayor calidad de la parte de bajo nivel. Haga que su gerente y sus compañeros de trabajo entiendan lo que se beneficiarán al agregar metodologías de alto nivel, hágales querer que cambie , la única manera de que su cultura cambie es haciendo que ellos quieran que cambie .

respuesta original

Le sugiero que en lugar de comenzar criticando el código ineficiente de sus empleadores, comience lentamente, cooperando con su gerente, con nuevas metodologías, una por una, donde se explica detalladamente la ganancia de cada paso. La cultura de una empresa sólo puede cambiar si los empleadores quieren que cambie , entendiendo por qué debe cambiar , y terminan con ellos queriendo que cambie .

Orden sugerido de metodologías:

Standups - Comenzando muy lento

Comience con stand-ups . Si puede hacer que su gerente y sus empleados entiendan que migrar información sobre lo que se está haciendo y por quién y en qué proyecto, entonces es menos probable que su empresa se joda si alguien de repente no puede continuar con su trabajo, convirtiéndolo en un dolor en el culo para el próximo patrón que tiene que recoger su trabajo. Si sus compañeros de trabajo piensan que será más fácil para ellos hacerse cargo del trabajo de otra persona migrando la información y dedicando solo cinco minutos al día a hacerlo, entonces es un posible comienzo.

TDD - Todavía pueden hacer sus cosas, pero de una manera más estructurada

Creo que es un buen próximo paso. Es difícil, y casi inútil , hacer pruebas unitarias en código heredado (en realidad, la definición, según algunos expertos, de un código heredado es una base de código que tiene pocas o ninguna prueba unitaria), pero escribir pruebas unitarias para nuevos métodos asegura que los nuevos métodos realmente harán lo que se espera de ellos, lo que dará como resultado menos errores en los que los desarrolladores tengan que pensar, menos gastos para la empresa (su gerente debería estar al corriente de eso), y da forma al flujo de los sistemas en lugar de al revés. Infórmese sobre el desarrollo basado en pruebas (TDD) y descubra cómoTDD hará que la vida de sus compañeros de trabajo sea más fácil y terminarán haciéndolo, especialmente porque pueden hacerlo solos y no tienen que interactuar con nadie más que lo haga. La parte más importante es que una prueba unitaria se puede escribir en cuestión de segundos o minutos, si se hace antes, por lo que no suena tan aburrido, y en realidad ineficiente y sin sentido, si se escribe después.

Inventar el concepto de SOA: deshágase de los sistemas estrechamente acoplados

La arquitectura orientada a servicios (SOA) garantizará una arquitectura débilmente acoplada que permite que cualquier persona reemplace y mantenga los módulos fácilmente, sin necesidad de conocer las otras partes de los sistemas. Pregúnteles a sus compañeros de trabajo si están dispuestos a mantener los sistemas súper acoplados de otra persona después de cinco años de desarrollo y mantenimiento, y pregúnteles si están más interesados ​​en entender cada concepto del sistema o si prefieren solo tener que comprender subconjuntos muy pequeños del sistema, incluso permitiéndoles reescribir esa parte muy específica desde cero si lo desean, porque solo es posible con una arquitectura súper orientada a objetos o SOA.

Revisión de código: migre el conocimiento sin necesidad de interactuar demasiado con otros

Puede preguntar a sus compañeros de trabajo si les gustaría ser más valiosos. Tener conocimiento en los diversos sistemas que están alrededor los hace más valiosos. Emigra el riesgo que le gustará mucho a su empleador, y le da a sus compañeros de trabajo una gran ventaja si uno de ellos no puede continuar con su trabajo. 15 minutos al día cambiarían mucho, y les permitirías señalar los defectos de los demás, sin hacerte parecer el malo , a menos que sea tu turno de revisar, entonces está bien porque bueno, se suponía que debías revisar. el código.

La lista continua

El punto es comenzar con las cosas de alto nivel; terminará en una calidad más alta de las cosas de nivel inferior.

Las cosas que dije de cada cosa posiblemente no convenzan a todos, pero la clave es lograr que tus compañeros de trabajo quieran cambiar, de lo contrario no lo harán. Déjelos ver por qué deberían cambiar al encontrar las partes pegadizas de las metodologías de alto nivel y las cosas mejorarán.

Ha enumerado tres problemas. La mayoría suenan como prácticas recomendadas aceptables (no tiene nada de malo), pero hay una en la que creo que debería centrarse, porque puede ser el problema principal, como lo verán todos en la empresa: "El proceso de desarrollo general es lento". ..." También das la razón, ineficaz.

La palabra "ágil" se usa, pero como todo esto, es relativo. Debe centrarse en algunos problemas reales que todo el mundo está teniendo. ¿Cuánto tardan las solicitudes de cambio? ¿Los cambios están incompletos, es decir, "La nueva solución apareció en la Sección A pero no en la Sección B. ¿Por qué no?" Estas son las cosas que les importan a los usuarios. Obtendrá más aceptación del resto de la empresa si los resultados de los cambios sugeridos los benefician. Por supuesto, poder implementar cosas más rápido puede ser mejor para todos.

Mencionas código duplicado. Es un no-no entre los programadores, pero para proyectos más grandes y especialmente aquellos con mucho código heredado, la refactorización no será fácil. Suena genial en teoría, hasta que descubres que nadie va a conceder al equipo el tiempo para hacerlo a expensas de las solicitudes actuales. Argumentar contra la deuda técnica no es fácil.

Como tarea inicial, intente reunir al equipo y discutir el desarrollo de estándares de codificación. Eres la persona nueva, así que lo reconociste de inmediato. Mira cuál es la reacción de todos. Es posible que reciba un rechazo porque no pueden ponerse de acuerdo o "lo intentamos pero nadie cumplió". Tal vez el lío actual sea motivación suficiente para que todos quieran hacer algo al respecto. Una vez más, es posible que no tenga tiempo.

Si ves que a este grupo le cuesta llevarse bien, empieza por algo básico; ir a almorzar juntos. En estas situaciones informales, puede encontrar cuáles son los problemas reales. Puede ser falta de conocimiento o quizás el ambiente creado en esta empresa está más preocupado por apagar los incendios diarios.

No te rindas, pero tampoco esperes que cambie de la noche a la mañana. Tienes una gran tarea frente a ti, mi amigo.

A menos que sea su trabajo cambiar sus prácticas laborales Y lo tenga por escrito, no lo haga, porque como han dicho otros, no funcionará.

La persona que debería estar haciendo eso es su gerente. Es el tipo al que tienes que persuadir. Pruebe con un llamamiento pragmático a la eficiencia, con ejemplos.

¿Si no está interesado? Aprende a vivir con eso (y asegúrate de que tu trasero esté cubierto) o encuentra otro trabajo. Es horrible, lo sé. Estado allí.

(Posiblemente no se trate de personas, sino de política, o alguien se habría dado cuenta de estas prácticas hace mucho tiempo).

Parece que realmente sabe lo que está haciendo, pero tenga cuidado de no empezar con el pie izquierdo con sus nuevos colegas. Si eres tan bueno, deberías poder hacer contribuciones positivas a los repositorios de cada persona. Es probable que a los mejores programadores no les importe que mejore su código, así que si puede trabajar con ellos, hágalo. Los que rechazan sus mejoras probablemente no sean los tipos con los que desea trabajar.

Pero una palabra de advertencia: asegúrese de que sus contribuciones no tengan compensaciones negativas. Si sus sugerencias tienen inconvenientes, se le culpará a usted si las cosas salen mal.

Mi estándar personal es que insisto en que cualquier cambio que haga en el código desarrollado por otros, donde no estoy diseñando cosas, no tiene ningún inconveniente (o si existen potencialmente intangibles, es decir, "¿es más legible?", que son mínimo.) Usando esto como mi estándar, todavía puedo:

• refactorizar código, escribir y mejorar unittests, generar excepciones más específicas
• corrija los errores creados debido al uso de código obsoleto y reemplace las estructuras que se están eliminando gradualmente con las construcciones más nuevas
• reduzca las líneas de código mediante el uso de funciones y métodos integrados que cubran el caso de uso, mejore la eficiencia del código al eliminar la materialización de estructuras de datos donde no sea necesario y reemplace el flujo de control incómodo con un flujo de control más optimizado
• mejorar las cadenas de documentación/documentación (desde la ortografía hasta la semántica) y realizar mejoras en el estilo del código (¡ya que tenemos una guía de estilo!)

Y hago todo lo anterior sin cambiar las entradas y salidas del código establecido, por lo que no se rompe nada en la producción.

Al hacer esto, puede construir una reputación de saber lo que está haciendo. Al hacer esto, construirá credibilidad con los trabajadores del conocimiento con los que está trabajando. Si eres capaz de reemplazar los componentes torpes o defectuosos por otros mejores, te apreciarán aún más. Al desarrollar su credibilidad, desarrollará su capacidad para persuadirlos de que adopten las prácticas que cree que tendrán grandes beneficios.

He estado en una situación similar dos veces y he descubierto como muchos otros que no hay absolutamente ninguna forma de mejorar las cosas a menos que tus colegas quieran cambiar.

Hay una manera simple de probar si están dispuestos o no, sugerir que el equipo asista a una conferencia o tome un curso sobre los temas de programación relevantes. Incluso puede haber grupos de usuarios o incluso grupos de interés de programación general que tienen reuniones abiertas de vez en cuando que su equipo podría visitar. Sugiera algún material de lectura o videos para que la gente los vea (los videos del tío Bob funcionan maravillosamente en esta situación).

Con esto no tienes que señalar ningún problema o error que crees que están haciendo, la respuesta del equipo a estas sugerencias te dirá todo lo que necesitas saber sobre su interés en mejorar las cosas. Si están entusiasmados con probar estas cosas, tienes una oportunidad, si no están interesados, debes ahorrarte el sufrimiento y salir de allí lo antes posible.

Hay que pensar en lo que motiva a la gente. "Sería más fácil para mí reemplazarlo en su trabajo si se hubiera adherido a las siguientes prácticas:" no es un gran motivador: la mayoría de las personas no quieren ser reemplazadas. Hacer un esfuerzo adicional para codificar de manera que alguien más se haga cargo tiene su valor, incluso fuera de una filosofía de contratar y despedir, ya que el código no está vinculado a personas en particular, lo que permite que la parte superior reaccione de manera más flexible a las cargas de trabajo cambiantes.

Pero en una situación de "nadie excepto $x va a tocar este código de todos modos antes de que finalice el proyecto", la pregunta de mantenibilidad por cualquiera versus esfuerzo tiene diferentes respuestas.

Con respecto a la reutilización de código: una filosofía de C++ es proporcionar las herramientas para crear soluciones genéricas. El 95% del "código reutilizable" que producen los aspirantes a programadores no se reutiliza. Y la razón de esto es que, para muchas tareas sencillas, el costo de "reutilizar" es más alto para un programador experimentado que simplemente escribir de forma improvisada, específicamente para el código en cuestión.

Si le dice a un autor de éxitos de ventas que puede duplicar su producción usando sus plantillas de texto que ya están preverificadas en busca de errores ortográficos y gramaticales y que solo necesita colocar los nombres y verbos correctos, y también ha parametrizado una serie de lugares para adverbios, ¿te imaginas lo emocionado que estará?

¿Te imaginas lo emocionado que estará si alguien más puede mantener su novela si está debidamente documentada y parametrizada?

Y nadie quiere consultar manuales y documentación para algunas cosas triviales que puede escribir en lo que al menos se siente como tomar menos tiempo y, sin duda, requiere menos esfuerzo mental.

Si tiene un equipo altamente calificado de constructores de órganos trabajando en un instrumento, encontrará que cada uno tiene su conjunto de herramientas personal que él mismo perfeccionó a lo largo de los años. Y cada uno tiene sus propias especialidades y estilos de trabajo característicos.

Si dice "aquí está la gerencia. Decidimos que vamos a estandarizar las herramientas de Paul. Hemos comprado/fabricado 20 juegos de herramientas exactamente como los de Paul, y ahora todos trabajarán con ellos en el futuro". Aunque todo el mundo esté de acuerdo en que Paul es el mejor organero de la empresa, pocos estarán contentos con ese cambio. Es probable que las herramientas no funcionen bien para los constructores sin experiencia, y funcionarán de manera diferente a sus propias herramientas para los experimentados.

Ni siquiera Paul estará feliz porque todos seguirán corriendo hacia él y culpándolo.

El objetivo de un equipo no es que todos puedan ser reemplazados, sino que logren trabajar en un todo coherente. Si está tratando de simplificar los procesos hasta el mínimo común denominador con el que se siente satisfecho, no está mejorando el rendimiento ni la moral laboral.

Desarrolla tu estilo. Haz tu parte en el equipo. Si lo está haciendo bien y de manera convincente, eventualmente conducirá a "preguntemos al usuario 1807, esto suena como algo que podría haber empaquetado previamente en su bolsa de trucos".

Lo que debe verificar después de estar allí alrededor de medio año no es cómo se hace el trabajo sino cómo se comunica: ¿siente que las reuniones de comunicación/equipo ocurren de manera que las ruedas realmente sustanciales no corren el peligro de reinventarse muy costosamente? ?

Pero ser capaz de precisar eso de una manera en la que la gente esté de acuerdo con usted, incluido "podríamos y lo haremos mejor", es algo que necesitará años para llegar.

Haz las cosas, como un jugador de equipo, a tu manera. Verás cómo eso ayuda o no a los proyectos, otros verán cómo ayuda o no a los proyectos. La gente aprende, y eso te incluye a ti. y gestión.

Hacer las cosas consistentemente de manera diferente a lo que uno está inclinado a hacer es una cuestión de disciplina. La autodisciplina está bien, pero no estás en la situación de disciplinar a otros.

Si se hace evidente para la gerencia que este podría ser un buen paso, usted será el líder del equipo en algún momento. No tiene sentido tratar de incitar a la gerencia a obtener ese resultado: un líder de equipo que no es aceptado por el equipo no logrará nada impopular. Obtendrías paredes de piedra. Así que sé un buen líder de equipo para ti mismo y un buen miembro del equipo para los demás.

Problema #1: conjunto de individuos

Si un desarrollador puede proporcionar y mantener una API coherente, ¿por qué preocuparse por las convenciones? Es la persona que conoce el código. Nadie más va a mantener la implementación. Preocúpate principalmente por la API.

Problema #2: reinventar la rueda

De hecho, esto es un problema. El código común debe separarse en un repositorio de empresa o equipo. Esto debe decidirse en el transcurso de varias reuniones dedicadas con todo el equipo.

Problema #3: no ágil

Por favor reconozca que ese agileno es el único y mejor enfoque posible para el desarrollo de software. Asegura desarrolladores mediocres .