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

129

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í.

BeeBand
fuente
170
Hágale saber a su jefe que fue muy amable de su parte guardarlo para su revisión en lugar de mencionarlo cuando notó que era un problema.
Blrfl
13
La programación de mantenimiento requiere un cierto tipo de persona. Quizás no sea lo tuyo. Del mismo modo, el nuevo desarrollo requiere otro tipo de persona. Hablas de descubrir herramientas / consejos / trucos. ¿Cuántas de esas herramientas has creado para tu propio uso? Si la respuesta es ninguna, entonces realmente creo que no eres un tipo de persona de programación de mantenimiento. Si te has movido entre varios proyectos por falta de rendimiento, tómalo como un mensaje claro de que no estás calificado para el puesto en el que estás. Ve a buscar algo más adecuado para ti.
Dunk
40
Si tiene que adivinar que está siendo arrastrado por su desempeño, la administración está haciendo algo mal. Del mismo modo, si lo primero que oyes de tu bajo rendimiento es después de 2 años, la administración está haciendo algo mal.
Michael Shaw
32
@Bee: Por lo general, una vez que alguien recibe una mala crítica, es hora de irse. Pueden ponerlo en un "programa de desarrollo de empleados", pero no creo haber visto a nadie recuperarse una vez que llegan a esa etapa. El momento más fácil para encontrar un trabajo es cuando ya tienes uno. Entonces, si fuera usted, estaría actualizando mi currículum y comenzaría a buscar en otro lado, muy pronto. También debe tener mucho cuidado con el tipo de trabajo que toma. La experiencia de 7 años todavía deja opciones. Una vez que llegue a 10, las empresas esperarán experiencia en áreas particulares. Elija un área que le guste y en la que sea bueno. ¡Vaya! Ya te vi llegar a 10.
Dunk
8
No es suficiente para ser una respuesta, sino con respecto a la "forma de ser más rápido": usted declara que es un dominio en el que es nuevo. ¿Podría ser que su forma de arreglarlo es demasiado prueba y error, sin saber realmente qué está pasando? "en el fondo"? En tal caso, aprender los conceptos básicos a fondo lo ayudará a detectar los posibles problemas.
Matsemann

Respuestas:

80

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!

kmote
fuente
2
Qué respuesta tan brillante. Creo que todos sus puntos son aplicables a mí (y con respecto al n. ° 1, bueno, tal vez soy menos inteligente, escuché que hay diferentes tipos de inteligencia, así que tal vez eso esté relacionado con el n. ° 4. Tal vez soy un desarrollador de Linux embebido de Numbskull pero tal vez soy mejor en cosas web ... y ahora que lo pienso, esto en realidad podría ser realista). de todos modos, eres muy perceptivo.
BeeBand
14
3 y 4 son más grandes (para programadores) de lo que la mayoría de los jefes pueden imaginar. Si un programador tiene baja moral, no puede concentrarse en el trabajo. Para un programador, la moral es impulso y el impulso lo es todo.
TimG
77
Excelente respuesta Depuración de ti mismo es una gran frase, por cierto. Desearía poder votarte por segunda vez solo por eso.
Kyeotic
2
Su "seguiría" no funciona en el punto 1 ya que la paradoja de la amistad modela las relaciones entre dos personas como un simple borde bidireccional entre dos vértices en un gráfico, mientras que un gráfico de quién es "más inteligente" que quién tendría que considerar un gran variedad de otros factores, sin mencionar que las reglas de transitividad no se aplican. Estoy de acuerdo con los puntos 2,3 y 4. En el caso del OP, creo que su jefe es un imbécil que sufre el efecto dunning-krueger.
funkymushroom
1
programador, depúrate a ti mismo. me encanta :) buena respuesta también. útil para mí, no porque esté en esa situación, sino porque ahora puedo ver cómo evitarlo. +1
jammypeach
56

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 ...

Tono
fuente
2
Esa es una gran respuesta. Tengo que pensar en por qué no estoy disfrutando este trabajo. Principalmente son los archivos de registro que nos dan para acompañar el error, he llegado a detestarlos más que a nadie: empiezo siempre completamente y completamente en la oscuridad con cualquier error que me den. Creo que es este sentimiento 'en la oscuridad' lo que odio.
BeeBand
44
A menos que uno haya experimentado un problema similar en ese mismo proyecto, la mayoría de las personas comienzan "en la oscuridad" cuando reciben un nuevo error. Luego, según los síntomas, descubres cómo recrear el problema, lo que debería dar ideas sobre dónde comenzar a adivinar la causa del problema. Sigues paso a paso. Nada mágico, nada que odiar. Dices que odias los archivos de registro. ¿Creó usted mismo alguna herramienta para automatizar el análisis de esos archivos de registro? Ignorando el hecho de que los archivos de registro deberían ser útiles, si no lo fueran, no pasaría mucho tiempo antes de que creara una herramienta que me ayudara a analizarlos.
Dunk
1
@Dunk sí, creé una herramienta para analizar los archivos de registro de varias maneras. Más tarde descubrí que alguien ya había creado uno hace aproximadamente un año.
BeeBand
@Bee: Tu creación de una herramienta muestra alguna iniciativa requerida. ¿Nadie le da una visión general del entorno de desarrollo cuando hace la transición entre proyectos? Si existen herramientas, entonces parece que el líder del proyecto debería haberte informado sobre ellas.
Dunk
@Dunk re descripción general - no. El primer líder de mi equipo me mostró una herramienta particular, pero no indicó que fuera útil para corregir errores de un tipo específico o que pudiera traducirse a otros proyectos. Cuando me trasladaron a este nuevo proyecto de mantenimiento, nadie me habló del entorno de desarrollo, solo tenía que preguntar. Fue solo después de luchar para construir mi propia herramienta que le pregunté a un colega y él mencionó cómo podía usar la herramienta original. (Nota: esta es una herramienta diferente a mi comentario anterior).
BeeBand
38

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.

naftalimich
fuente
2
He visto equipos en mi carrera profesional que son exactamente como los has descrito. El código que mantienen es vasto y críptico, y la información sobre cómo funciona está celosamente guardada. Los nuevos miembros del equipo se dejan intencionalmente en sus propios dispositivos y terminan transfiriéndose para salvar sus carreras.
Anthony Giorgio
31

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

Mathew Foscarini
fuente
11
No es ilegal dar evaluaciones negativas de desempeño, pero tienen que ser objetivas y acordar criterios factibles para trabajar y apoyarlo.
pjc50
99
Pensé, tal vez estoy exagerando, cuando publiqué esa respuesta, pero leer tu publicación resonó con mis propias experiencias. La corrección de errores no es algo que se pueda medir con un contexto de rendimiento. He pasado 3 meses una vez para corregir un solo error. Por lo general, los tipos inteligentes son los que reciben los errores duros.
Reactgular
99
No puedo votar porque no veo evidencia de que seas un abogado y afirmes que brindas asesoramiento legal. Además, si otros empleados están arreglando X errores en promedio por mes, pero el OP está arreglando X / 10, eso es absolutamente objetivo y razonable.
Andy
77
@Andy gracias por compartir por qué votaste en contra. Estoy de acuerdo en que las proporciones de corrección de errores son un indicador, pero lo que es objetivo es decirle a alguien un viernes que tiene una crítica negativa el próximo lunes. Aparte de hacerlos sudar con tacto durante el fin de semana. ¿No es seguro asumir que el resultado deseado sería que el empleado no se presente el lunes para la revisión? ¿No clasificaría eso como despido constructivo? Espero poder cambiar su perspectiva, porque el despido constructivo es un problema constante en nuestra industria.
Reactgular
77
No hay forma de que un juez dictamine que esto es un despido constructivo. Puede hacer dobladillos sobre la letra de la ley, pero este tipo de ley está ahí para los casos en que un empleado está siendo acosado o maltratado, una situación activamente hostil. En base a lo que dice el OP, se les informó que recibirán una revisión negativa porque no está comparando con sus pares en cuanto a la tasa de corrección de errores; es una situación difícil, pero difícilmente hostil y ciertamente no ilegal. Tal vez el jefe podría haber sido más discreto, pero la retroalimentación no tiene que estar limitada a las revisiones oficiales de desempeño
pdubs
26

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!

Zan Lynx
fuente
3
Esta es una respuesta fantástica. Estoy muy impresionado.
Daniel Hollinrake
26

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.

zwol
fuente
44
"La depuración es dos veces más difícil que escribir el código en primer lugar". - Brian Kernigan (padre de C, UNIX)
TimG
44
@TimG: Y como cualquier otro programador, Kernigan estaba subestimando la dificultad.
mu es demasiado corto el
Wow, me gustaría señalar que esta es una pregunta realmente difícil y estoy realmente sorprendido de ver una respuesta tan buena y perspicaz aquí. Gracias.
maksymko
12

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í.

JB King
fuente
2
ended up getting micromanaged until I was terminated- Bueno, acabo de ver tu perfil SO y claramente te has recuperado de eso, así que encuentro tu respuesta alentadora. Voy a hablar sobre su primer punto el lunes: estoy recibiendo errores de áreas muy dispares.
BeeBand
10

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.

chrisaycock
fuente
2
sí, este no es mi código: es un vasto sistema embebido en expansión, diseñado por primera vez hace 10 años. Creo que tienes razón sobre los patrones: necesito volver a lo básico.
BeeBand
1
@BeeBand sería bueno saber cómo te ha ido. Espero que las cosas salgan bien.
Daniel Hollinrake
10

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?

pjc50
fuente
Sería interesante saber si BeeBand ya ha hecho esto. Al leer los comentarios y las respuestas, parece que es un ambiente bastante hostil.
Daniel Hollinrake
1
Bueno, puedo simpatizar con eso. Sé lo que es estar en una empresa donde el equipo de desarrollo está nevado por el trabajo. Afortunadamente, en mi caso trabajo con algunos colegas excelentes y nos cuidamos mutuamente. ¿Hay alguien con quien puedas emparejarte? El tiempo dedicado a entrenarlo y ayudarlo a ser más productivo valdrá la pena para todos. Por el sonido de las cosas que le importan y son conscientes, su empresa se beneficiaría de mantenerlo.
Daniel Hollinrake
8

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.

usuario2106285
fuente
7

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 ...

Kaz
fuente
1
El mayor problema con la concurrencia es que es mucho más fácil escribir código libre de errores que corregir errores en el código con errores. Especialmente si el código es casi correcto. Y los errores generalmente no están en un solo lugar, sino que se distribuyen en muchos.
gnasher729
5

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.

Jason Swett
fuente
Actualmente lo estoy leyendo por recomendación tuya.
BeeBand
3

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.

m3th0dman
fuente
Presumiblemente, se mide como problemas cerrados / unidad de tiempo . Puede ser razonable decir "bueno, algunos errores tardan más que otros", pero a menos que el OP esté trabajando en una parte particularmente difícil del código y todos los demás estén haciendo cosas fáciles, eso probablemente no va a aguantar.
Caleb
3

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.

dennisk1718
fuente
2

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).

Erik Reppen
fuente
2

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.

dcaswell
fuente