Trabajo como desarrollador de iOS en una pequeña empresa de outsourcing en un equipo de 4 personas. Trabajamos en un proyecto que comenzó un par de años antes de que yo y otros dos desarrolladores nos uniéramos a la compañía. Antes de eso, el proyecto estaba siendo realizado principalmente por una persona.

Cuando comencé a trabajar en el proyecto, fue un completo desastre. Hubo mucha repetición de código. Vi los mismos 500 códigos codificados en 20 archivos diferentes con pequeñas variaciones. Además, no estaba exactamente bien organizado: todo el código de creación de UI se mezcló en los controladores de vista junto con la lógica.

Hice todo lo posible para refactorizar las cosas aquí y allá, eliminar piezas de código redundantes, mejorar la estructura de archivos del proyecto, etc. Parecía que al desarrollador anterior realmente no le importaban todas estas cosas o no tenía la experiencia. Hubo un tiempo en que trabajé solo en una característica bastante grande durante un par de meses. Debido a la naturaleza de esta función, tuve que tocar mucho código en toda la aplicación, así que intenté hacer algunas mejoras.

Cuando otros desarrolladores se unieron al proyecto, noté que usan un estilo de codificación diferente (a veces un estilo completamente diferente) y, a menudo, no usan características de lenguaje modernas como accesores de propiedad (esto es relativamente nuevo en Objective-C). A veces inventaban sus propias bicicletas en lugar de usar características similares del marco, o transferían conceptos de otros lenguajes de programación o patrones que aprendieron a nuestra base de código. A menudo no pueden nombrar los métodos o variables correctamente debido a un mal inglés (Objective-C es un lenguaje donde se hacen nombres largos).

A veces pienso que si no fuera por el IDE, creo que escribirían todo el código sin sangría ni formato.

Básicamente, odio el código que escriben. Está mal formateado / organizado, y a veces es radicalmente diferente del resto del proyecto. Me siento muy molesto cuando agregan sus espaguetis a mi obra de arte y afecta mi estado de ánimo en el trabajo y mi productividad.

Se siente cada vez más como que no pueden molestarse en aprender o no les importa: simplemente hacen lo que se les exige y se van a casa. Traté de darles algunos consejos cuando tuve la oportunidad (por ejemplo, comentó sus relaciones públicas o se comprometió en GitHub). Una vez pedí amablemente que siguiera el estilo de codificación y el formato de la mayoría del código existente (lamentablemente no tenemos un documento de estilo de codificación formal). Pero no funcionó ...

¿Cómo puedo abordar esta situación sin solo enfocarme en la 'mala cultura de la compañía', 'graduados sin experiencia', etc. y realmente comenzar a mejorar la situación?

Enseña y practica lo que predicas.

Sabes que esto es importante. Conoces el inconveniente cuando no se hace bien.

Ahora el desafío es convencer a los demás. Esto no se hará a través de una sola conversación, una reunión, conversaciones en el pasillo, consejos o dentro de una solicitud de extracción.

Esto necesita:

• El público reconoce por la administración que estos artículos son importantes
• Linters para que las personas puedan reunirse, discutir y acordar el estilo y luego dejar que las computadoras controlen
• Desarrolladores líderes que compran por completo y están dispuestos a enseñar a otros
• Reuniones, demostraciones, almuerzos y aprendiza, etc. para enseñar estos enfoques.
• Las personas que se miden sobre los artículos de calidad que menciona durante sus revisiones
• Estándares documentados y publicados
• Solicitudes de extracción que tienen muchos revisores
• Las solicitudes de extracción no se fusionan hasta que la calidad del código sea alta
• Código de emparejamiento frecuente
• Revisiones de códigos de grupo para relaciones públicas complejas

En palabra requiere

Liderazgo

La buena noticia es que todas estas actividades generalmente se reconocen como buenas prácticas, por lo que cuando va a promocionarlas u obtener la aceptación de la gerencia, debe tener una buena probabilidad de éxito y poder defenderse haciendo lo correcto. Sin embargo, es posible que la administración aún no acepte, ese es otro tema y pregunta.

He escrito mucho sobre este tema en SoftwareEngineering.SE en el pasado, y yo mismo estaba en situaciones similares. Por lo tanto, intentaré dar algunas sugerencias y resaltar algunos problemas que noté al leer su pregunta.

Pero primero, hablemos de un aspecto importante: su papel en la empresa.

Tu rol

Puede tener un mandato explícito de su jefe para mejorar las cosas, y también un lugar en la jerarquía donde otros desarrolladores tienen que escuchar sus órdenes . O puede estar entre pares, tener el mismo rol y la misma autoridad, su opción es solo ... bueno ... una opinión .

En ambos casos, lo que importa es menos su lugar en la jerarquía y más:

• Lo que otros desarrolladores piensan de ti. Si te tratan como un tipo molesto que les pregunta cosas estúpidas, no llegarás lejos. He visto muchos casos en los que los líderes técnicos y los gerentes de proyecto no tuvieron absolutamente ninguna influencia en el equipo, porque el equipo sabía (o pensaba) que esos "líderes" no tenían antecedentes técnicos necesarios para tomar las decisiones que estaban tomando. Por otro lado, he visto a varios desarrolladores que fueron escuchados por sus pares, porque sabían que esos desarrolladores son hábiles y experimentados.

• Qué tan sólido es su equipo y qué los motiva. Imagine una empresa donde cada desarrollador recibe un pago por KLOC / mes. ¿Le importaría algo a sus colegas sobre el estilo? Probablemente no, porque son raras las personas que quieren que se les pague menos. En general, si este no es un equipo, sino solo un grupo de personas que trabajan en el mismo proyecto, no podrá mejorar nada.

Dependiendo de eso, puede decidir si vale la pena hacer algún cambio. Si no tiene voz y no hay cohesión del equipo, simplemente busque otro trabajo. Si eres conocido como un desarrollador talentoso y respetado y existe un fuerte sentimiento de equipo, podrás mejorar las cosas de manera relativamente fácil, incluso si enfrentas la hostilidad de tu jefe u otros equipos.

En todos los casos, es esencial no presionar a su equipo. Trabaja con ellos, no contra ellos. No les dé órdenes, sino guíelos hacia la meta.

Ahora, las pistas.

Estilo

Una vez pedí amablemente que siguiera el estilo de codificación y el formato de la mayoría del código existente (lamentablemente no tenemos un documento de estilo de codificación formal). Pero no funcionó ...

Por supuesto que no, ya que esta no es la forma en que debería hacerse.

• El estilo es aburrido .

• El siguiente estilo es aburrido .

• Escribir un documento de estilo de codificación es aburrido ( y muy difícil ; ni siquiera intente hacerlo a menos que haya trabajado con el idioma durante más de diez años).

• Leer el documento de estilo es aburrido .

• Revisar el código por errores de estilo es aburrido .

• Trollear que mi estilo es mejor que el tuyo es emocionante , especialmente cuando no hay absolutamente ningún beneficio objetivo de un estilo sobre otro. En serio, cada persona cuerda sabe que la manera correcta de escribir if (x)es la forma en que lo escribí, no if(x)o if ( x )!

Por lo tanto:

• No hagas revisiones de estilo. Este es el trabajo de las damas de estilo. Esas lindas aplicaciones tienen algunos beneficios sobre su cerebro: verifican todo el proyecto en cuestión de milisegundos, no horas o días, y no cometen errores y no pierden errores de estilo.

• No escriba su propio estándar de estilo. Lo harás mal de todos modos, y tus compañeros de trabajo te convencerán de que tomaste malas decisiones.

• No obligue a los desarrolladores a corregir 2 000 errores de estilo.

• Hacer cumplir estilo automáticamente en commit. El código que tiene errores de estilo no tiene cabida en el control de versiones.

• Hazlo desde el inicio del proyecto. Configurar el control de estilo en un proyecto existente es difícil o imposible.

Para más información sobre eso, lea la primera sección de esta otra respuesta en SE.SE .

También:

• No seas muy estricto. Por ejemplo, escribir jslintcódigo compatible es bastante molesto, por lo que debe hacerse exclusivamente cuando sea absolutamente necesario (o si todos los miembros de su equipo están contentos de usarlo). Lo mismo ocurre con las herramientas de comprobación estática; por ejemplo, el análisis de código de .NET al nivel máximo podría ser muy opresivo y deprimente, a la vez que ofrece pocos beneficios; el mismo conjunto de herramientas a nivel moderado, por otro lado, demuestra ser muy útil.

Revisiones de código

Ahora que no necesita preocuparse por el estilo durante las revisiones de código, puede concentrarse en cosas más interesantes: mejorar (en lugar de arreglar) el código fuente.

Diferentes personas reaccionan de manera diferente a las revisiones de código. Algunos lo consideran una oportunidad. Otros lo odian. Algunos escuchan todo lo que les dices, toman notas y no discuten, incluso si pudieran estar en lo cierto. Otros intentan discutir sobre cada punto. Depende de usted encontrar una manera de tratar con cada desarrollador de acuerdo con su personalidad. Por lo general, es útil:

• Realice revisiones de código en privado, especialmente cuando el desarrollador es junior y escribe un código realmente malo.

• Muestre que no hay nada personal: está revisando el código, no las habilidades de la persona.

• Mostrar el objetivo real de una revisión de código. El objetivo no es mostrar qué tan malo es un desarrollador. El objetivo es proporcionar oportunidades de mejora.

• Nunca discutir. No estás aquí para convencer, sino para brindar tu experiencia.

• Nunca asuma que el revisor es el único que puede aprender algo de una revisión. También está aquí para aprender, tanto leyendo el código como pidiendo explicaciones sobre las partes que no comprende.

Una vez que se realiza la revisión del código, asegúrese de que la persona realmente mejore su código. Tuve algunos casos en los que los desarrolladores pensaron que la revisión del código termina cuando finaliza la reunión real. Se van y vuelven a sus nuevas funciones, tratando de aplicar lo que compartió con ellos solo para el nuevo código. Tener una herramienta de seguimiento decente para la revisión de código ayuda.

Tenga en cuenta que independientemente de su rol particular en la empresa y su experiencia en comparación con otros, su código también debe estar sujeto a revisión. Tampoco deberías ser el único que revisa el código de otros.

En un proyecto reciente en el que trabajé como líder técnico, me costó explicarles a mis compañeros de trabajo que es su función hacer las revisiones del código del otro, incluido el mío. El miedo a un interno que está a punto de revisar el código de su líder técnico desaparece tan pronto como encuentra los primeros problemas en el código, ¿y quién de nosotros escribe un código perfecto?

Formación

Las revisiones de código son una gran oportunidad para enseñar y aprender algunos de los aspectos de la programación y el diseño de software, pero otros requieren capacitación.

Si puedes entrenar a tus compañeros de trabajo, hazlo. Si su administración es hostil ante la idea de capacitación, hágalo informalmente. He realizado tales sesiones de capacitación en forma de reuniones informales, o, a veces, incluso como simples debates, a veces interrumpidos por la gerencia y perseguidos más tarde.

Además de la capacitación directa, asegúrese de conocer suficientemente bien los libros como McConnel's Code Complete y hable sobre esos libros con sus compañeros de trabajo. Sugiérales que lean el código fuente de proyectos de código abierto, bríndeles ejemplos específicos de código de alta calidad. Y, obviamente, escriba usted mismo un código de alta calidad.

Centrarse en el contexto, no en las personas.

¿Cómo puedo abordar esta situación sin solo enfocarme en la 'mala cultura de la compañía', 'graduados sin experiencia', etc.

Esos graduados tienen un objetivo: adquirir experiencia, aprender cosas, volverse más hábiles. Si, año tras año, escriben código malo y no saben nada sobre programación, probablemente sea porque su equipo o su empresa no les está dando esta oportunidad.

Si te estás enfocando en el hecho de que tu equipo tiene graduados sin experiencia, esto no ayudará. En cambio, concéntrate en lo que puedes hacer por ellos y con ellos. Las revisiones de códigos y la capacitación son dos de las técnicas para mejorar la situación.

La mala cultura de la compañía es una bestia diferente. A veces, se puede cambiar. A veces no puede. En todos los casos, recuerde que usted es parte de esta empresa, por lo que forma parte de la cultura de la empresa. Si no puede cambiarlo y lo encuentra inherentemente malo, tarde o temprano, tendrá que irse.

Obtenga sus métricas correctas

¿Cómo exactamente mides el código en este momento? ¿Mide el número de confirmaciones por día por desarrollador? ¿O el KLOC por mes por programador? O tal vez el código de cobertura? ¿O la cantidad de errores encontrados y corregidos? ¿O el número de posibles errores detectados por las pruebas de regresión? ¿O el número de reversiones realizadas por el servidor de implementación continua?

Las cosas que mides importan, porque los miembros del equipo están adaptando su trabajo a los factores que se miden. Por ejemplo, en una empresa donde tuve que trabajar hace unos años, lo único que se midió fue el tiempo que uno pasa en la oficina. No hace falta decir que esto no fue alentador para ofrecer un mejor código, o para trabajar de manera más inteligente, o ... bueno, para trabajar en absoluto.

Determinar el refuerzo positivo y negativo y ajustar los factores medidos a lo largo del tiempo es esencialmente la influencia que tiene sobre los miembros del equipo. Cuando se hace correctamente, permite obtener resultados que no se lograrán con una simple jerarquía.

Las cosas que te molestan, las hacen medibles. Mídalos y haga públicos los resultados. Luego trabaje junto con otros miembros del equipo para mejorar los resultados.

Por ejemplo, consideremos que los miembros del equipo cometen demasiados errores ortográficos en los nombres de las clases, los miembros de la clase y las variables. Esto es molesto. ¿Cómo puedes medir eso? Con un analizador, puede extraer todas las palabras del código y, usando un corrector ortográfico, determinar la proporción de palabras que contienen errores y errores tipográficos, digamos 16,7%.

Su próximo paso es ponerse de acuerdo con su equipo en la proporción objetivo. Podría ser del 15% para el próximo sprint, del 10% para el próximo, del 5% en seis semanas y del 0% en dos meses. Esas métricas se vuelven a calcular automáticamente en cada confirmación y se muestran en una pantalla grande en la oficina.

• Si no logra el índice objetivo, su equipo puede decidir pasar más tiempo arreglando errores ortográficos. O su equipo puede considerar mejor calcular la relación por desarrollador y mostrar esta información en la pantalla grande también. O su equipo puede encontrar que el objetivo era demasiado optimista y que debería revisarlo.

• Si logra la proporción objetivo, el siguiente paso es asegurarse de que la cantidad de errores y errores tipográficos no aumenten con el tiempo. Para eso, puede crear una tarea adicional en su compilación que verifique si hay errores ortográficos y fallará la compilación si se encuentra al menos un error. Ahora que eliminó este problema, su pantalla grande puede reutilizarse para mostrar las nuevas estadísticas relevantes.

Conclusión

Creo que todos los aspectos mencionados en su pregunta pueden resolverse mediante las técnicas que incluí en mi respuesta:

• Cuando otros desarrolladores se unieron al proyecto, noté que usan un estilo de codificación diferente (a veces un estilo completamente diferente)

  Debes aplicar el estilo automáticamente al confirmar.

• y, a menudo, no utiliza características de lenguaje modernas como los accesores de propiedad (esto es relativamente nuevo en Objective-C).

  Tanto la revisión de códigos como la capacitación están aquí para transferir su conocimiento del idioma.

• A veces inventaban sus propias bicicletas en lugar de usar características similares del marco

  Tanto la revisión de códigos como la capacitación están aquí para transferir su conocimiento del marco.

• o transferir conceptos de otros lenguajes de programación o patrones que aprendieron a nuestra base de código.

  Esto es una cosa excelente. Parece una oportunidad para que aprendas de ellos.

• A menudo no pueden nombrar métodos o variables correctamente debido a un mal inglés

  Las revisiones de código también deberían centrarse en la denominación adecuada. Algunos IDE también tienen correctores ortográficos.

• A veces pienso que si no fuera por el IDE, creo que escribirían todo el código sin sangría ni formato.

  Por supuesto que lo harían. El estilo es aburrido y debe automatizarse.

• Básicamente, odio el código que escriben.

  Recuerde de la parte de revisiones de código: “El objetivo no es mostrar lo malo que es un desarrollador. El objetivo es proporcionar oportunidades de mejora ".

• Está mal formateado / organizado, y a veces es radicalmente diferente del resto del proyecto.

  Comprobación de estilo automatizada .

• Me siento muy molesto cuando agregan sus espaguetis a mi obra de arte

  ¡¿Esperar lo?! ¡¿Obra de arte?! ¿Adivina qué? Algunas personas (incluido usted en seis meses) pueden encontrar su código lejos de ser una obra de arte. Mientras tanto, entienda que considerar su trabajo como una obra de arte y su trabajo como basura no ayudará a nadie. Incluyéndote.

• Se siente cada vez más como que no pueden molestarse en aprender o no les importa: simplemente hacen lo que se les exige y se van a casa.

  Por supuesto que harán lo que les sea requerido. Recuerde: contexto, no personas, y obtenga sus métricas correctas . Si el contexto requiere de ellos que sean mejores en lo que hacen, lo harán. Si el contexto requiere producir tantos KLOC por mes como sea posible y nada más, también lo harán.

Implemente estándares de codificación y cúmplalos, patrones de diseño, biblioteca de fragmentos de código que se pueden usar como pautas, etc.

Los estándares de codificación pueden variar desde decidir si usar espacios o pestañas, qué patrones de diseño probar y usar, convenciones de nomenclatura, etc. Esto será de gran ayuda incluso si todos codifican de manera diferente.

Si puede, implemente estándares de codificación y revisiones de código, para comenzar, revise cada registro. Con un equipo pequeño será difícil de vender para las personas que no entienden que gastar 2x o 3x adicionales en su código por adelantado le ahorrará 20x o 30x en el tiempo de desarrollo general, pero ese es otro concepto que vale la pena comprar. -en adelante.

No intentaría implementar todo de una vez, y haría todo lo posible para que también se les ocurran estándares, no solo la sangría, sino que intente que piensen en las cosas que han encontrado en su código que tienen les hizo la vida más fácil o más difícil.

Considere tener una reunión un día a la semana para revisar lo que salió bien o mal para cada persona durante esa semana, también podría ofrecer una oportunidad para que cada persona diga qué hizo otra persona que fue más útil esa semana, cosas así . Puede consultar los libros de XP / Agile para obtener más ideas como esta. Al ser un equipo pequeño, nuevamente, esto podría ser difícil de vender.

Mencionaste problemas de idioma. Si estos trabajadores son locales (ya sea contratistas en el sitio o contratados a tiempo completo) eso no debería ser un gran problema, pero si son contratistas en el extranjero que trabajan de forma remota, permítanme decir que en mi experiencia personal esto nunca será va a ser reparado, ya sea hasta que la gerencia se dé cuenta de que no funcionará o considere abandonar la empresa No se meta en una situación en la que sea responsable de su trabajo y no pierda el tiempo tratando de arreglar las prácticas de desarrollo del equipo. Lo más probable es que su trabajo se convierta en pasar el 100% de su tiempo haciendo que su código funcione. Muchos contratistas extranjeros son grandes programadores, por cierto, solo me refiero al caso en el que la empresa contratante le envió el tipo de talento que usted describió.

Los síntomas que describe sugieren una falta de cohesión del equipo .

En tal situación, los estándares de codificación, la capacitación, los procedimientos o las herramientas no serán la bala de plata que podría mejorar sustancialmente la calidad. Primero debe desarrollar un espíritu de equipo, una comunicación abierta y constructiva y una propiedad compartida del producto.

Síntomas

• "simplemente hacen lo que se requiere y se van a casa": sonido, están desmotivados. ¿No estaban más entusiasmados cuando llegaron?
• "ellos" contra "nosotros" / "yo" / "yo": falta de confianza mutua?
• "Di algunos consejos: comenté relaciones públicas en Git": el tono de la crítica escrita a veces se malinterpreta como agresivo o arrogante a pesar de la intención constructiva. ¿Por qué no discutirlo cara a cara?

Eres un equipo pequeño: ¡aprovecha esta ventaja! Algunas ideas para comenzar:

• Tomar decisiones importantes colectivamente. Discuta abiertamente el desacuerdo. "Discutir" no es imponer un punto de vista, sino escuchar e intentar encontrar un terreno común.
• Has refactorizado partes importantes del código, por lo que tienes una propiedad muy sólida. Déjalos comprar. Déjalos decir algo.
• Y para temas muy delicados pero altamente subjetivos como el formato de código, simplemente externalice el deber a una impresora bonita automatizada que se formateará de acuerdo con el estándar y sin sentirse en cada check-in.

Cita del día:

Si quieres ir rápido, ve solo. Si quieres ir lejos, ve juntos

Su pregunta se puede responder con "Cambiar su empresa o cambiar su empresa". Para aquellos que no lo saben, esto significa que usted se queda y lucha para lograr el cambio que desea ver en su empresa, o cambiar la empresa para la que trabaja (es decir, irse y trabajar en otro lugar).

La segunda parte es la más simple. Te vas y encuentras una empresa que comparte los mismos valores con los que trabajas. El primero no es tan simple debido a ... la gente.

Lo que hay que hacer es cambiar a las personas. Pensar que están rotos y que necesitas arreglarlos no va a funcionar. Las personas son seres emocionales. Esto puede degenerar fácilmente en guerras personales. Entonces...

En primer lugar, debe averiguar por qué la situación es como es. Habla con todos. Descubrir. Lo que ves ahora es el resultado de decisiones tomadas a lo largo de los años (o tal vez no tomar algunas decisiones importantes en el momento adecuado). No juzgues y no saltes a conclusiones.

¿Fue causado por desarrolladores inexpertos? ¿Fue causado por la administración tratando de reducir costos mediante la contratación de graduados baratos en lugar de desarrolladores más experimentados y caros? ¿Se trata de personas que son vagas y mal intencionadas o personas vencidas por un sistema roto? ¿Los plazos lo obligan a hacer "lo que se debe hacer" para que funcione o las personas simplemente pierden su tiempo y no les importa demasiado en qué están trabajando? etc.

El problema con este campo de desarrollo de software es que las personas aprenden en el trabajo. Si trabajan en un entorno horrible, aprenderán malos hábitos. Y los hábitos tienden a mantenerse y son difíciles de eliminar. Entonces no saben mejor porque eso es todo lo que saben. No a todos los desarrolladores les apasiona lo que hacen para invertir tiempo en mejorar o buscar mejorar. Algunos se metieron en este negocio por varias otras razones. Entonces descubra por qué las personas son como son.

Luego está la gestión. ¿La administración desconoce la situación o simplemente no le importa? Descubrir. Es absolutamente necesario contar con el apoyo de la administración si desea mejorar las cosas. Si algo que tardó 3 meses en construirse de repente comienza a tomar 4 meses porque ahora necesita escribir pruebas, hacer revisiones de códigos, discutir en la pizarra con el equipo para decidir sobre buenas soluciones, programas de emparejamiento, etc., puede ser Asegúrese de que la gerencia notará la diferencia horaria. Algo que cambia de 3 a 4 meses es fácil de observar y medir. Tener una base de código sólida, un producto que se pueda mantener, una buena arquitectura estable, cosas que contribuyan a una mejor estructura del producto no es tan fácil de medir. La cantidad de tiempo que las mejores prácticas lo compran a largo plazo no se puede medir por adelantado, tal vez ni siquiera después del hecho. Por otra parte, un retraso de un mes es obvio. Por lo tanto, cuente con el apoyo de la gerencia en esto. Prepárese para hacer una venta difícil.

También mire el contexto del negocio. ¿Afecta esto a tu forma de trabajar? ¿Tiene oportunidades que deben seguirse a cualquier costo, incluido el sacrificio de la calidad del código o las mejores prácticas?

Cambiemos de perspectiva por un momento.

Me siento muy molesto cuando agregan sus espaguetis a mi obra de arte y afecta mi estado de ánimo en el trabajo y mi productividad.

Lo siento ... tu que? ¿Arte? Sé que la mayoría de nosotros estamos aquí para el reconocimiento de nuestros pares y solo lo obtienes si eres un buen desarrollador, pero ¿tu código se muestra en un museo al lado de una pintura? ¿Tiene que causar emociones en las personas que lo miran? ¿Lágrimas de alegría y felicidad? Sí, soy sarcástico y exagero deliberadamente porque quiero decir que tengo un sentido de la realidad. No te apegues emocionalmente a tu código.

Solía ​​trabajar con un tipo que felizmente arrojaría al equipo, proyecto y compañía debajo del autobús solo para imponer su "arte" a todos. Él era el "poseedor de la verdad" y, por definición, todos eran inexpertos, ciegos, no estaban dispuestos a aprender, no les importaba o simplemente eran estúpidos. No te conviertas en ese tipo. Como desarrollador de software, su trabajo es escribir un buen código, un código probado, un código que se pueda mantener, un código que agregue valor comercial y que pueda continuar haciéndolo bajo constantes cambios futuros. Y tiene que hacer todo eso por debajo del presupuesto y las limitaciones de tiempo. Eso es lo que significa ser un desarrollador de software profesional. A menos que sea una galería de arte, el arte es malo para los negocios. Sea pragmático y mantenga una visión equilibrada de las cosas. " Cómo ignorar el código incorrecto que escriben mis compañeros de trabajo y simplemente enfocarme en el trabajo"cerró su pregunta por la forma en que planteó el problema. Retroceda y mire todo el asunto.

¿Cómo puedo abordar esta situación sin solo enfocarme en la 'mala cultura de la compañía', 'graduados sin experiencia', etc. y realmente comenzar a mejorar la situación?

TL; DR: Mire cuidadosamente la situación para descubrir por qué las cosas terminaron en esa situación. Acepte que la situación es así y vea cómo puede mejorar desde allí. Descubra cuál es la opinión de todos sobre esto. Escoge tus batallas. Forzar el cambio no funciona. Colabora para hacer los cambios. Debe intentar mostrar cómo se pueden mejorar las cosas, no señalar qué tan malas son. Convence a todos de que lo que quieres hacer es por un bien mayor a largo plazo. Sube a bordo.

Y hazlo en pequeños pasos.

Si traes demasiado cambio de repente, la gente se sentirá desanimada y se dará por vencida. Los cambios llevan tiempo. Cambia tu empresa o cambia tu empresa. ¡Buena suerte!