¿Hay alguna manera de acelerar la solución de errores? Acabo de recibir una advertencia de mi jefe [cerrado]

Mi jefe acaba de decirme que recibiré una evaluación negativa del desempeño el lunes. Quiere hablar conmigo sobre por qué soy tan lento y por qué mi tasa de corrección de errores es tan baja.

Me encanta programar y resolver problemas, pero realmente encuentro mi trabajo realmente difícil.

De hecho, he sido programador durante unos 10 años. Pero este es mi primer trabajo Linux integrado de subprocesos múltiples: llevo aquí 2 años y es obvio para todos que todavía estoy luchando. Y creo que me he desmoralizado tanto y me siento tan marginado que he perdido mucho fuego al inicio del trabajo.

¿Alguien ha estado en una situación similar y cómo hace para aumentar su tasa de corrección de errores?

Actualización: tuve la revisión. Me pusieron en un 'programa de desarrollo de empleados' de 3 meses (del tipo mencionado por Dunk). No estoy seguro de si puedo cambiar esto. Pero incluso si tengo que seguir adelante, he aprendido mucho de esta experiencia.

Otra actualización

Han pasado aproximadamente 6 semanas desde la primera revisión. Mi consejo para cualquiera que enfrente la misma situación es ser lo suficientemente humilde como para recibir críticas y aprender de sus errores. Y no tener miedo de parecer tonto. Haz montones y montones de preguntas. Hazle saber a la gente que estás tratando de aprender y sigue preguntando hasta que lo entiendas. Pero prepárate para que no funcione. Estoy construyendo una cartera de código ... además de darle lo mejor de mí.

Otra actualización

Dudo en poner esto aquí, ya que me preocupa no poder recomendar futuros empleadores a mi perfil de stackoverflow ... Pero de todos modos, podría ser de interés para alguien que lea esta pregunta, pero en realidad perdí mi trabajo hace unas semanas. Estoy en medio de repasar todas las habilidades que necesito, he tomado mucho de los consejos que se dan aquí.

Muchas respuestas han cuestionado los métodos / tácticas / métricas / etc. de su jefe. Pero eso no viene al caso. Quizás eres lento. Cada sala de desarrolladores tiene que tener UNO que sea más lento que el resto, ¿verdad? (Eso es solo teoría de conjuntos). Así que supongamos que eres tú. La respuesta es, ¿POR QUÉ eres lento? (Claramente, esa es la pregunta que tiene que responder antes de que pueda resolver su pregunta sobre cómo llegar más rápido).

Podría haber todo tipo de razones, pero aquí hay algunas explicaciones posibles a considerar:

1. Eres menos inteligente que ellos . Es posible, ¿verdad? (Los estudios han demostrado que TODOS somos menos populares , menos interesantes y (seguiría) menos inteligentes que nuestros amigos). Entonces, tal vez eres de cerebro lento. Por otra parte, en su caso, creo que esto es poco probable. Un vistazo rápido a su perfil de StackOverflow muestra que tiene un historial de hacer preguntas inteligentes sobre una amplia gama de temas. Así que obviamente eres un pensador y probablemente bueno en eso.

2. Estás muy delgado. Ese mismo perfil SO muestra que sus preguntas cubren una amplia gama de tecnologías en los últimos 2 años (gráficos, web, python, c ++, c, linux, incrustados, hilos, sockets, etc.). Personalmente, sé que cuando me puse en la situación de tener (o querer) profundizar en una multitud de corrientes diferentes, me encuentro nadando muy rápido (o, más bien, muy lento ). Quizás lo que realmente necesita aquí es ENFOQUE . Y tal vez una buena dosis de priorización . ¿Hay alguna forma de relegar las ollas menos importantes al quemador trasero y subir el fuego del plato principal?

3. No te estás divirtiendo. Cuando el fuego se apaga, la máquina de vapor está destinada a desacelerar. Admitiste en tu publicación que tu moral ha sufrido un duro golpe últimamente. Desafortunadamente, te has tragado el vórtice de succión de armónicos negativos autorreforzantes, una fuerza que puede destruir puentes . Es una espiral demasiado familiar: tarea difícil -> estrés -> plazo vencido -> más estrés -> mecanismo de afrontamiento deficiente -> más estrés -> procrastinación -> más plazos vencidos -> críticas / chismes (reales o imaginarios) - > aún más estrés. Te dan la imagen. Esto rara vez lleva a algún lugar útil. Tome una lección de mis días en el rafting: cuando una corriente circulante succiona bajo el agua en la parte trasera de un rápido clase 4, su chaleco salvavidas NOboya de regreso a la superficie. La mejor estrategia (aunque no intuitiva) es encontrar el fondo del río y salir de la marea. Entonces, mi consejo para usted es: encuentre algo de terreno , amigo (amigos, iglesia, nuevos hábitos saludables, etc.) y utilícelo para deambular fuera del remolino.

4. No estás en tu zona. Michael Jordan hizo un jugador de béisbol bastante cojo. (De acuerdo, él todavía era mejor que yo, pero definitivamente era un jugador de ligas menores). Quizás "Linux multihilo incrustado" simplemente no es tu actuación. Pero el desarrollo de software es un campo extremadamente amplio (como bien sabes; cf # 2 arriba). ¿Su empresa es lo suficientemente amplia como para poder encontrar otro nicho? En mi último trabajo fui contratado como un desarrollador de software integrado. (No tenía experiencia en ese ámbito, pero les dije que era un "aprendiz rápido"). Me hundí rápidamente como una piedra. Pero seguí trabajando duro y seguí buscando problemas que hicesaber cómo resolverlos Al final resultó que, gradualmente, pude migrar a nuevas responsabilidades en las que podía brillar, y por las cuales finalmente recibí considerables elogios. Entonces quizás necesites cambiar tu marca.

El punto es: si eres lento, hay una razón. Pero, oye , ¡eres ingeniero de software, amigo! ¡Depúrate!

Su jefe puede estar en lo correcto: es posible que tenga un "rendimiento inferior" (más en un minuto). Pero puede que no sea solo su nivel de competencia el que tiene la culpa. No creo que sea un alcance sugerir fuerzas fuera de su control que le están causando estrés, lo que está teniendo un efecto negativo en su rendimiento.

Echemos un vistazo a algunas de las razones por las que su jefe ahora puede estar trayendo esto:

Cultura y politica

Puede haber fuerzas más allá de su control que requieren que su jefe ahora exprese su preocupación. Es importante comprender el sistema en el que está trabajando. Su trabajo es hacer que su jefe se vea bien. La única forma de hacerlo es entender las presiones bajo las que está.

Capacidad

Es posible que la habilidad no esté a la altura, como usted dice, dijo abiertamente. Esto es lo que haría en esta situación:

Obtenga comentarios específicos de su jefe sobre cómo mide el rendimiento. ¿No estás cerrando tantos errores como la persona X? ¿Hay un número determinado de errores que deberías resolver? Si trabaja solo, debe asegurarse de que las personas que miden su desempeño lo midan de manera justa y no se basen en alguna idea preconcebida.

Si su desempeño es lento y se basa en una brecha real, identifique esa brecha y elabore un plan detallado junto con su jefe con el objetivo de cerrarlo.

Esta revisión también es una buena oportunidad para mencionar el hecho de que no está satisfecho. Es bueno que hayas identificado que no amas este trabajo. Pero averigua por qué. ¿Qué parte de tu trabajo te gusta y qué no? Puede ser que este trabajo no sea para ti ...

Algunos entornos de trabajo son inviables. He visto entornos en los que nadie podía sobrevivir (a excepción de aquellos que estaban al principio) porque había muchas cosas indocumentadas y las preguntas se desanimaban con mucha vehemencia.

Realmente necesita ser honesto consigo mismo con respecto a las expectativas y los recursos proporcionados para ayudarlo a cumplirlos. El problema puede no ser usted.

Mencionas que hay personas que realizan trabajos similares a los tuyos que, supongo, no tienen dificultades, pero que tienen más de 5 años de experiencia para tus 2. ¿Cómo te sientes en comparación con tus compañeros? ¿Son estrellas de rock que te superan por completo (a este respecto), o son como tú? Quizás simplemente conocieron el sistema cuando era más simple ... Usted mencionó tener 8 años de experiencia en programación antes de esta línea de trabajo. ¿Cómo te fue allí? Si lo hiciste genial, entonces eso debería decirte algo.

La parte que me llamó la atención es el hecho de que te describas a ti mismo como estando en la oscuridad con respecto a todos los errores que se te presentan. Puede ser que la base del código sea tan vasta e inexplorada que las expectativas no sean razonables.

Para que hayas llegado tan lejos como has hecho, significa que has hecho algo bien y tienes algo a tu favor.

La conclusión, creo, es que necesitas sentirte bien contigo mismo y con lo que estás haciendo. Y si eso significa seguir adelante, que así sea.

Es mejor seguir adelante que tener un trabajo que arruine tu vida.

Primero, tenga en cuenta: esta respuesta solo puede aplicarse a ciertas regiones donde es ilegal despedir a un empleado sin indemnización. Dicho eso ...

Este podría ser un caso de despido constructivo y que es ilegal.

La táctica es desmoralizar y disminuir la autoestima de un empleado hasta que renuncie al trabajo. Es una forma de que la empresa ahorre dinero al no tener que pagar la indemnización o resolver el problema de tener que enfrentar al empleado y despedirlo.

Quiere hablar conmigo sobre por qué soy tan lento y por qué mi tasa de corrección de errores es tan baja.

Esta falla es muy ambigua. Es imposible que cualquiera de las partes alegue que la otra está equivocada. Te tomaste un mes para arreglar un error. ¡Y qué! Esto lo coloca en una posición defensiva, al tener que presentar hechos para respaldar su afirmación de que se requirió un mes. Dada su habilidad actual, experiencia y conocimiento como factores. Como empleador, el trabajo del empleador es administrar el tiempo y los esfuerzos de sus empleados. El empleador debe ser la persona involucrada en el riesgo asociado con la reparación de los errores. No el empleado. Siempre tuvo la opción de asignar el error a otra persona.

Si usted es un contratista, y en su contrato establece que será responsable de la reparación de errores, entonces es una historia completamente diferente.

¿Está mal que el empleador se queje de que está tardando demasiado? Absolutamente no, pero él no puede responsabilizarte por ello, y no puede despedirte por ello. Él puede decirle "No tenemos más errores que requieran sus habilidades, y se lo deja de permiso", pero deben decirle en el momento en que surge un nuevo problema que puede solucionar. De lo contrario, deben terminar con la separación. Lo que no puede hacer es darte un trabajo que no puedes manejar y luego quejarte. Creo que esto es ilegal.

Me encanta programar y resolver problemas, pero realmente encuentro mi trabajo realmente difícil.

Hay una gran diferencia entre tomar un trabajo que le resulta difícil y su empleador que le da trabajo que es demasiado difícil. Si cree que las tareas que se le asignaron se hicieron para desalentarlo de tener una carrera en la empresa, esto podría ser ilegal.

De hecho, he sido programador durante unos 10 años. Pero este es mi primer trabajo Linux integrado de subprocesos múltiples: llevo aquí 2 años y es obvio para todos que todavía estoy luchando.

Por eso creo que te has encontrado en medio de un despido constructivo. No están contentos contigo, así que te apilan hasta que te vayas.

Y creo que me he desmoralizado tanto y me siento tan marginado que he perdido mucho fuego al inicio del trabajo.

Un empleador es responsable de proporcionar un ambiente de trabajo seguro y positivo. Sin más información (probablemente personal) es difícil para los extraños decir lo que realmente está sucediendo aquí. Solicite una consulta gratuita a un abogado de empleo. Podrán decirte si estás jugando.

Referencias

No soy un abogado, pero Google buscó algunos documentos sobre el tema del despido constructivo que vale la pena leer antes de ingresar su revisión el lunes. El punto principal aquí es tener cuidado con una reducción en el salario, la humillación y los cambios repentinos en su carrera en la empresa.

Hechos relevantes a tener en cuenta:

• No apoyar adecuadamente a un empleado durante condiciones de trabajo difíciles.
• Disciplina excesiva de un empleado Imponer un cambio en el lugar de trabajo de los empleados a corto plazo
• Imposición de una reducción de sueldo o salario

Preguntas y respuestas legales: despido constructivo

Razones para reclamar el despido constructivo

Wikipedia

elementos de un despido constructivo

Quizás te están comparando con uno de los programadores originales de un proyecto. Sé que, como desarrollador original de uno de los proyectos en los que trabajo, tengo una gran ventaja al corregir errores. No creo que se deba a la falta de documentación, es solo que puedo saltar intuitivamente a posibles problemas porque mi cerebro conoce todo el código.

Si te comparan con eso, entonces no vas a estar a la altura. Siempre le llevará más tiempo ponerse al día con el proyecto y no sabrá dónde están todos los puntos de interacción potenciales.

Leí tu comentario sobre no descubrir herramientas y trucos que otros programadores están usando para resolver problemas. Quizás para su próxima corrección de errores necesite probar la programación de pares. Esto puede ser increíblemente útil. Túrnense para manejar el teclado. Hacer un montón de hablar.

Puede usar un cuaderno o una pizarra para trazar rutas de funciones, subprocesos y vidas de bloqueo, y marcar dónde observa varios bits de comportamiento y dónde puede insertar nuevas sondas.

Resolver este tipo de problemas de subprocesos de bajo nivel puede ser realmente difícil y tengo mucha simpatía por ti. He tenido que analizar varios gigabytes de archivos de registro antes para detectar un problema de dos líneas. ¿Y sabes qué? Lo observé durante días antes de pedirle ayuda a un ingeniero junior que había sido interno el año anterior, y se le ocurrió un nuevo enfoque y descubrió el problema en una hora. Entonces, después de dedicar un tiempo a un error, obtén nuevos ojos sobre él. ¡Puede ayudar mucho!

Una de las disfunciones de gestión más comunes en esta industria es no comprender que la depuración es intrínsecamente difícil . Tengo casi 20 años de experiencia y todavía tengo que pasar una semana completa para encontrar el error de una línea que hace que el programa se bloquee una vez de cada cincuenta. Y luego, si mi gerente no entiende estas cosas, me molestan por tomarme una semana para cambiar una línea de código.

¿Qué puedes hacer al respecto?

• Tome notas mientras depura. Solo tenga siempre abierta una ventana del editor y escriba su flujo de conciencia. No tiene que tener sentido para nadie más que para ti. Puede descubrir que esto lo ayuda a depurar más rápido, pero también significa que tiene algo concreto que señalar para demostrar que no estuvo jugando Nethack en toda la semana.

• Compara notas con todos tus compañeros de trabajo. ¿Cuánto tiempo tardan típicamente en corregir errores? ¿Sus errores permanecen arreglados? ¿Con qué frecuencia cambian una pequeña cosa y se encuentran enterrados bajo una pila de consecuencias en cascada? Las respuestas a estas preguntas le darán una idea de si realmente está luchando en relación con el resto del departamento.

• Haga amigos con el personal de control de calidad y el personal de atención al cliente. Ellos son los que tienen la mejor idea de cuán importantes son los errores. A menudo, esto tiene poca o ninguna correlación con la dificultad de los errores, por lo que puede jugar un poco al sistema e intentar que se le asignen todos los errores de alta importancia y baja dificultad. (Esto no es realmente hacer trampa. Un equipo bien organizado siempre persigue esos errores primero).

• Si su jefe no le ha estado dando retroalimentación adecuada sobre su desempeño durante dos años consecutivos, ese es un problema que primero debe mencionar en esta revisión de desempeño, y luego, cuando se le dé la vuelta, para hablar con el jefe de su jefe. Sé cortés y, sobre todo, no dejes que vean lo enojado que estás, pero recibe críticas específicas por escrito.

Si bien es posible que le encante programar y resolver problemas, puede plantearse la cuestión de qué tan bien está aplicando lo que está aprendiendo a otras áreas. ¿Alguna de las últimas docenas de errores que ha solucionado es lo suficientemente similar como para que lo que lo ayudó a solucionar uno sea útil en otro? Esto es parte de mirar hacia atrás sobre lo que hiciste y cuánto tiempo te llevó hacerlo. Solo una idea a considerar.

En segundo lugar, miraría cómo estás haciendo tu trabajo. ¿Te interrumpen regularmente y cuando intentas corregir el error A, te dicen que los errores B y C tienen mayor prioridad? Considere cuidadosamente qué tipo de cambios en la forma en que realiza su trabajo pueden ayudarlo aquí, ya que eso probablemente sea parte de lo que su jefe querrá saber.

Algunos lugares de trabajo me dicen que no les gustó cuánto tiempo me llevó hacer parte de mi trabajo. Por supuesto, estos eran aquellos lugares en los que si hacía una cosa, se me soltarían 5 cosas nuevas en mi regazo y, por lo tanto, era fácil sentirse abrumado. Si bien es posible que ya no trabaje allí, no tenía una buena solución sobre cómo centrar mi atención en algunas cosas para no sentir que estoy tratando de dominar 1,000 cosas a la vez. Si puedo saber algunas cosas clave para hacer y cómo se juzgará mi trabajo, entonces soy mucho mejor que si tuviera una lista de "tareas pendientes" de una milla de largo y a nadie parece importarle si consigo partes de eso hecho. Por lo tanto, podría ser que hay un componente cultural en esto dentro de la organización, aunque sería cuidadoso al pedir que las cosas cambien aquí.

Después de dos años en el trabajo, debería ser obvio para todos (usted, su jefe, sus colegas) cuál es su posición. Es decir, nunca deberías descubrir que te ha ido mal solo una vez al año; Un ambiente de trabajo ideal proporcionará retroalimentación continua.

De todos modos, con respecto a cómo depurar código multiproceso: no ha mencionado si este es su código o el de otra persona. Hay algunos nuevos depuradores y analizadores estáticos que pueden manejar la concurrencia. Pero realmente, conocer los patrones será su mejor opción, ya que sabrá qué buscar.

Si comprende cómo funcionan las secciones críticas y las condiciones de carrera y el punto muerto, entonces estará en una mejor posición para detectar cosas inesperadas. Si ve "comunicación" entre dos subprocesos sin variables de condición, o si los recursos se mutean sin un orden particular, o si se declara una variable local staticsin razón aparente, ¡entonces tiene un error potencial! Así que aprenda las mejores prácticas de su dominio y estará en una mejor posición para juzgar cuando algo está fuera de lo común.

No luches solo a menos que tengas que hacerlo. Recluta colegas. Haz que te ayuden en la búsqueda de insectos. Pregúnteles sobre su proceso de pensamiento y herramientas. Quizás mencione esto en su revisión como parte de su plan para mejorar. Si todos los que te rodean están mejorando en este sistema , ¿quizás saben algo específico?

Mi jefe acaba de decirme que recibiré una evaluación negativa del desempeño el lunes. Quiere hablar conmigo sobre por qué soy tan lento y por qué mi tasa de corrección de errores es tan baja.

Tenga en cuenta que en cualquier empresa no disfuncional las cosas no suceden en este pedido. Si su jefe está preocupado por su desempeño, debe establecer objetivos a corto plazo y hablar sobre sus resultados para averiguar dónde está el problema.

En cambio, decide darte una crítica negativa y luego descubrir por qué. Parece que no está dispuesto a involucrarse en el problema, y ​​solo quiere resultados en la tabla.

No intentes resolver errores más rápido. Procure evaluar su propia capacidad, verifique cómo trabajan sus colegas, cómo saben lo que saben y tenga en cuenta que esta no es una empresa ideal.

En cuanto a consejos prácticos, utilizo fragmentos de código y mi propio mediawiki para tomar notas. Siempre tengo en mente qué libros leer a continuación y qué dirección tomar para continuar mi aprendizaje. El aprendizaje es el camino hacia un mejor trabajo y una vida más feliz.

Primero, un aumento de confianza:

¿Por qué sufrir? Puede encontrar fácilmente un trabajo en el que piensen que es "dios" simplemente porque puede hacer cualquier cosa incrustada en Linux, independientemente de su tasa de corrección de errores.

De todos modos, es imposible establecer un límite de tiempo para cazar un error. La caza de insectos es una habilidad, sin duda, y la eficiencia en ella es muy valiosa.

Es posible que te falte algún truco básico que otros conocen, lo que te hace más lento.

Por ejemplo, si usted y yo estamos trabajando en algún middleware de Linux, y estoy usando Valgrind para encontrar problemas de corrupción de memoria y condiciones de carrera de datos, mientras que solo confía en gdb y printf, probablemente patearé su trasero, incluso si Eres más inteligente que yo.

Además, ¿cómo entiende su concurrencia ? Si ha estado desarrollando durante diez años, pero la mayor parte de esa experiencia no fue con código multiproceso, eso podría ser un problema.

Debería estudiar el subprocesamiento múltiple en detalle: más que solo saber cómo usar las API, sino realmente "obtenerlo" a un nivel profundo. Si está haciendo programación multiproceso, debe ser ese desarrollador que pueda mirar una base de código desde una milla de distancia y detectar escenarios de condiciones de carrera, puntos muertos, inversiones prioritarias, inanición ...

Hace poco leí el libro Trabajar eficazmente con código heredado y me ha dado un gran impulso de confianza al abordar un problema en cualquier base de código.

Si el código con el que está trabajando no es perfecto, creo que este libro sería de ayuda. He descubierto que la mayoría de las veces para corregir un error, primero necesito refactorizar el código circundante para incluso entenderlo , y luego, una vez que entiendo el código, y con suerte hacer que el código sea comprobable, rastrear y arreglar el problema es menos difícil. (A veces incluso reescribo el código solo para comprenderlo, pero luego revierto mis cambios para reducir el riesgo de introducir nuevos errores. Luego inserto mi corrección de errores. Esa técnica se basa en un truco del libro).

Creo que mi sugerencia solo aborda parte de su problema, y ​​algo indirectamente, pero vale la pena leer el libro, pase lo que pase, ya que trabajar con código heredado es inevitable para cualquier desarrollador.

Pregúntele a su superior cuál es su velocidad para corregir errores y cuál es la velocidad media del equipo para corregir errores. Más importante, pregúntele cómo se mide la velocidad de corrección de errores ...

Esta es una especie de métrica no es realmente una métrica; si lo fuera, sería aún más poco confiable que LOC (aunque midiendo cosas diferentes). Y sin una medición adecuada, no hay razón para acusarlo de nada.

Reconoce que trabajas CON empleadores y / o clientes NO para ellos. No dude en mencionar eso en las entrevistas, solo para dejar las cosas claras desde el principio.

Usted es un profesional con una gran inversión en su pequeña empresa, es decir, usted mismo.

Está dispuesto a trabajar mientras haya una Unión de Intereses que lo impulsa a salir del estante cada día.

Si esa propulsión no está allí por un período de tiempo prolongado, continúe.

Está desperdiciando su tiempo y energía en un empleador vago que no mantiene su interés activo / habilidades actualizadas / tareas desafiantes y / o interesantes para que usted trabaje. Ese es el trabajo de la gerencia. Aparte de eso, son pura sobrecarga .....

Mantenga su pasión, ya que esa es la clave.

He estado en situaciones similares porque tenía miedo de pedir ayuda. A juzgar por lo que dijiste en este comentario ...

"Pero lo que es frustrante es que hay ciertas herramientas / consejos / trucos que solo descubrí después de estar allí un año y medio. Me cambiaron de un equipo a otro (supongo que porque tenía un rendimiento inferior) y estoy descubriendo estas herramientas 'ocultas' de vez en cuando ".

... puede que hayas tenido el mismo problema que yo. La depuración es tan artesanal como escribir código que no requiere tanta depuración en primer lugar. Ver a otros desarrolladores trabajar a través de un problema de depuración puede ser muy educativo. Pídales ayuda cuando tenga problemas para resolver algo. Especialmente si estás cubriendo terreno que no tenías antes. Y hágalo idealmente antes de que llegue el momento de entrar en pánico porque no está haciendo nada.

Dicho esto, estoy de acuerdo con los comentarios de que la gerencia estaba haciendo algo mal. Si alguien está luchando con algo, debe recibir ayuda antes de que comience la diversión de la crítica negativa. Demonios, si alguien en un equipo está luchando y nunca recibe ayuda, diría que todos los miembros de ese equipo están haciendo algo mal (aunque eso podría ser un resultado directo de las personas que observan sus tasas de corrección de errores demasiado de cerca).

Lo que falta en el OP es cualquier mención de un proceso o método repetible que se esté siguiendo para resolver errores.

Entonces, primero, documente el proceso que sigue. Asegúrese de documentar lo que cada paso del proceso debe lograr.

Puede delinear el proceso con tareas como esta:

1. Asegúrese de comprender exactamente cuál es el problema que se informa.
2. Intenta reproducir el problema.
3. Comience a descomponer el problema en pedazos más pequeños.
4. Piense en las posibles causas del problema.
5. Pon a prueba esas hipótesis

Sería útil saber si los errores han existido durante mucho tiempo o si se están introduciendo con cambios recientes. Si los errores se han introducido con cambios recientes, hacer revisiones de código y / o simplemente leer el código que la gente está creando puede ayudar.

Creo que si puede definir claramente el problema, por ejemplo, "Tengo problemas para pensar en hipótesis para probar al tratar de resolver errores", entonces puede obtener consejos más específicos.