Estoy obteniendo 4-5 veces más puntos de historia que el promedio, pero produzco errores a la mitad de la tasa. Los gráficos dicen que son 2 veces más errores, ¿cómo lidiar con eso?

43

Por lo tanto, generalmente se acepta que los programadores de nivel superior pueden producir un orden de magnitud de código más / mejor que sus pares más promedio.

También se acepta generalmente que la tasa de errores cometidos en el código es relativamente constante para los programadores.

En cambio, tiende a verse afectado por los procesos utilizados al escribir el código y después de que se escribe el código . (Según tengo entendido) Los humanos tienden a cometer errores a un ritmo bastante constante: los mejores programadores solo notan más y son más rápidos para corregirlos.

  • Tenga en cuenta que ambas afirmaciones anteriores provienen de Code Complete de Steve McConnell, por lo que no se trata de perspectivas diferentes.

Así que comencé a ver esto recientemente en mi código. Puedo obtener aproximadamente 4-5 veces la cantidad de código que muchos de mis compañeros (medidos por los puntos de historia estimados por el equipo), con una mayor calidad (según las métricas de rendimiento y la cantidad de cambios realizados después del check-in). Pero sigo cometiendo errores. Entre mejores pruebas unitarias, una mejor comprensión de lo que está haciendo el código y un mejor ojo para los problemas al hacer revisiones de código, no estoy produciendo entre 4 y 5 veces la cantidad de errores.

Pero sigo produciendo aproximadamente el doble de errores encontrados por QA que otros desarrolladores de mi equipo. Como puede imaginar, esto causa algunos problemas con personas no técnicas que realizan mediciones métricas (léase: mi jefe).

Intenté señalar que estoy produciendo errores a la mitad de la velocidad de mis pares (y corregir el doble), pero es difícil de vender cuando hay gráficos que dicen que produzco el doble de errores.

Entonces, ¿cómo lidiar con el hecho de que una mayor productividad conducirá a un mayor número de errores?

Telastyn
fuente
27
O simplemente disminuya la velocidad para que pueda hacerlo bien.
Brandon
29
Desde un punto de vista práctico, parece que le pagan más por evitar errores que por la generación de código. Así que pasa 1/4 de tu día escribiendo código para tu empresa, y pasa el resto del día escribiendo código para tus propios proyectos paralelos. Según el criterio que ha establecido, tu jefe debería amarte.
Rob
14
No entiendo por qué nuestra comunidad parece celebrar la "velocidad" más que la corrección. Y escribo "velocidad" entre comillas porque si tienes que volver para arreglar las cosas, entonces tal vez no sea una "velocidad" real. Al final, se le paga por entregar software de trabajo. Si al escribir código más rápido que el promedio, está produciendo errores, ya sea omitiendo las pruebas o no entendiendo los requisitos correctamente, entonces tómese un tiempo para "dedicar" y úselo para mejorar sus pruebas / comprensión de los requisitos (por ejemplo, ¿lo está haciendo? TDD?). Como dice el tío Bob, "si quieres ir rápido, ve bien".
MichelHenrich
99
La forma de arreglar esto es arreglando las métricas.
Robert Harvey
24
@MichelHenrich: Si está produciendo errores a la mitad de la velocidad de sus compañeros, entonces la velocidad no es el problema; La administración es el problema. Estás leyendo estas tontas métricas de la misma manera que sus jefes.
Robert Harvey

Respuestas:

41

Creo que estás mezclando tus preocupaciones. Y no hay nada de tu lado que debas cambiar.

La productividad es una pista de lo rápido que se completará un proyecto. A los gerentes de proyectos y a todos los demás les gusta saber cuándo se realizará el proyecto. Una productividad más alta o más rápida significa que veremos el proyecto entregar antes.

La tasa de errores no está vinculada a la productividad, sino al tamaño del proyecto. Por ejemplo, puede tener Nerrores por Ylíneas de código. No hay nada dentro de esa métrica que diga (¡o le importa!) Cuán rápido se escriben esas líneas de código.

Para unir eso, si tiene una mayor productividad, sí, "verá" los errores que se escriben más rápidamente. Pero de todos modos ibas a tener esa cantidad de errores, ya que está relacionado con el tamaño del proyecto.

En todo caso, una mayor productividad significa que tendrá más tiempo al final del proyecto para buscar esos errores o el desarrollador será más rápido en encontrar los errores que crearon. 1


Para abordar los aspectos más personales de su pregunta.

Si su jefe está observando estrictamente la cantidad de errores que produce en lugar de la tasa de errores que produce, una sesión educativa está en orden. El número de errores creados no tiene sentido sin una tasa de respaldo.

Para llevar ese ejemplo al extremo, dígale a su jefe que quiero duplicar su salario. ¿Por qué? No he creado absolutamente ningún error en su proyecto y, por lo tanto, soy un programador muy superior a usted. ¿Qué? ¿Va a tener un problema porque no he producido una sola línea de código para beneficiar su proyecto? Ah Ahora entendemos por qué la tasa es importante.

Parece que su equipo tiene las métricas para evaluar errores por punto de historia. Por lo menos, es mejor que medirlo por la cantidad bruta de errores creados. Sus mejores desarrolladores deberían estar creando más errores porque están escribiendo más código. Haga que su jefe arroje ese gráfico o al menos arroje otra serie detrás de él que muestre cuántos puntos de la historia (o cualquier valor comercial que mida) junto con la cantidad de errores. Ese gráfico contará una historia más precisa.


1 Este comentario en particular ha atraído mucha más atención de la que pretendía. Así que seamos un poco pedantes (sorpresa, lo sé) y restablezcamos nuestro enfoque en esta pregunta.

La raíz de esta pregunta es sobre un gerente que mira las cosas incorrectas. Están mirando los totales de errores sin procesar cuando deberían mirar la tasa de generación versus el número de tareas completadas. No nos obsesionemos con la medición contra "líneas de código" o puntos de historia o complejidad o lo que sea. Esa no es la pregunta en cuestión y esas preocupaciones nos distraen de la pregunta más importante.

Según lo establecido en los enlaces por el OP, puede predecir un cierto número de errores en un proyecto únicamente por el tamaño del proyecto solo. Sí, puede reducir este número de errores mediante diferentes técnicas de desarrollo y prueba. De nuevo, ese no era el punto de esta pregunta. Para comprender esta pregunta, debemos aceptar que para un proyecto de tamaño determinado y una metodología de desarrollo, veremos un número determinado de errores una vez que el desarrollo esté "completo".

Así que finalmente volvamos a este comentario que algunos entendieron completamente mal. Si asigna tareas de tamaño comparable a dos desarrolladores, el desarrollador con una mayor tasa de productividad completará su tarea antes que el otro. Por lo tanto, el desarrollador más productivo tendrá más tiempo disponible al final de la ventana de desarrollo. Ese "tiempo extra" (en comparación con el otro desarrollador) se puede utilizar para otras tareas, como trabajar en los defectos que se filtrarán a través de un proceso de desarrollo estándar.

Tenemos que tomar la OP en su palabra de que son más productivos que otros desarrolladores. Nada dentro de esas afirmaciones implica que el OP u otros desarrolladores más productivos están siendo descuidados en su trabajo. Señalando que habría menos errores si pasaran más tiempo en la función o sugiriendo que la depuración no es parte de este tiempo de desarrollo, se pierde lo que se ha pedido. Algunos desarrolladores son más rápidos que otros y producen trabajos comparables o de mejor calidad. Nuevamente, vea los enlaces que el OP presenta en su pregunta.


fuente
43
"Medir el progreso de la programación por líneas de código es como medir el progreso de la construcción de aeronaves por peso". -Bill Gates
Neil
40
Los grandes programas en realidad pueden producir más errores que el programador promedio, porque los grandes programas tienden a trabajar en problemas más difíciles.
hlovdal
44
Bugs / K lines o bugs / storypoint serían una tarifa justa. Correría lo más rápido posible si el jefe quiere usar errores / hora como tarifa.
Bart van Ingen Schenau
44
"Sus mejores desarrolladores deberían estar creando más errores porque están escribiendo más código". no, deberían evitar errores o terminar más funciones. A menudo eso significa que escriben menos código, o incluso eliminan franjas de código. (probablemente lo sepa, simplemente no lo escribió de esa manera) Ciertamente, en algunas industrias en las que he trabajado (por ejemplo, aeroespacial y nuclear), el único código que cuenta es el código que tiene cero defectos. Cualquier otra cosa es ruido.
Pete Kirkham
44
"En todo caso, una mayor productividad significa que tendrá más tiempo al final del proyecto para cazar esos errores o el desarrollador será más rápido en encontrar los errores que crearon". - Creo que esto es espurio y necesita un análisis más cuidadoso. Dicho de esta manera: si pasara más tiempo en cada función, sí, tendría menos tiempo para eliminar errores. Pero también habría menos errores para aplastar.
oculto
21

Dedique parte de ese tiempo extra a limpiar, pulir y probar su código. Todavía habrá errores, pero habrá menos. Eso lleva tiempo. La tasa de salida de su código disminuirá, pero su salida de código libre de errores aumentará, y eso dará como resultado una mejor productividad. Porque los errores son caros.

¿Puedes mantener tu código en una rama o en un entorno de prueba hasta que lo patees y descubras más errores? Los errores en una rama generalmente causan menos ondas que los errores en el código de producción.

Pero no estoy cavando exactamente sus afirmaciones que conducen a su pregunta. Y quizás tu jefe tampoco lo sea.

No creo que cada codificador produzca la misma tasa de errores. Su segundo enlace en realidad está completamente fuera del tema, ya que compara diferentes idiomas, no diferentes niveles de habilidades de codificador. El código completo menciona algunas mediciones de muestras grandes que analizan el proceso en lugar de la habilidad de los codificadores. Y cuando dicen que los codificadores de nivel superior producen más / mejor código, parte de eso significa que tiene menos errores. Depende de la aplicación. Entonces, sí, creo que ES una cuestión de perspectiva diferente.

Al final, si el jefe quiere un código más limpio, dale un código más limpio.

Philip
fuente
44
+1. No sé por qué la otra respuesta tiene tantos votos positivos. Parece que ya le has dado un buen razonamiento a tu jefe y él no está escuchando. Así que pase más tiempo probando y menos tiempo "liberando" líneas de código. Si eso no está bien, cambie de trabajo.
durron597
21

Me arriesgaré y seré el abogado del diablo. Eso no quiere decir que no simpatice con su situación, pero, bueno, mi simpatía no lo ayudará. Permítanme agregar a la perspectiva de Philip :

Su jefe se preocupa por la calidad del producto, en parte porque su nombre y reputación estarán vinculados a él. Parte de la calidad es la cantidad percibida de errores . Si vende un simulacro impresionante que perfora cuatro veces más rápido que cualquier simulacro de la competencia, pero que también se descompone el doble de veces, tendrá una mala reputación. Incluso si es discutible que el ejercicio funcione mejor, las personas se acostumbran a la velocidad, pero recordarán las averías.

En retrospectiva, la mayoría de los errores son obviamente prevenibles. Si solo fue un poco más cuidadoso, su jefe lo sentirá, podría evitar estos problemas y cualquier limpieza necesaria. Desde su perspectiva, es algo trivial y sensato preguntar, y cualquier discusión que hagas al respecto no funcionará y te hará quedar mal.

No puede medir su productividad superior. Reclama una mayor productividad basada en una métrica verificable, entonces, ¿cómo se sienten sus colegas al respecto? ¿Están de acuerdo, quizás a regañadientes, en que eres un programador más productivo o estás solo en tu opinión? Hará un punto más fuerte si tiene otras personas que respalden sus afirmaciones.

Eso es por perspectiva. Ahora, ¿cómo haces para 'arreglar' esta situación frustrante en la que te encuentras?

Disminuya la velocidad un poco. Mencione explícitamente a quien distribuya las tareas que intentará reducir la tasa de errores (*), para que no se sorprendan por su menor ingesta. En todo caso, reducir la velocidad reducirá la cantidad de errores asignados a usted por pura falta de suministro.

(*) Hay una diferencia entre, por un lado, reconociendo que hay son insectos a su nombre y que se va a tratar de disminuir esa cantidad y, por otro lado, admitiendo que usted tiene demasiados errores a su nombre y debe tomar acción.

No trates de convencer a tu jefe, porque no funcionará. Nuevamente, eso no significa que tenga que reconocer su punto; Puede presentar un contrapunto y mantener su opinión sin descartar sus preocupaciones. Porque si argumenta el punto y no puede probar satisfactoriamente su productividad superior (e incluso si puede), correrá el riesgo de insultar a sus colegas o parecer despectivo. No quieres ser ese tipo .

JvR
fuente
44
Mi respuesta favorita, y también la más cercana a un punto que me gustaría agregar: ¿Cuál es el valor de un número completo de puntos de historia y cuál es el costo de un error para la empresa? El OP puede encontrar con esas cosas ponderadas por las prioridades de los jefes que, de hecho, es más productivo crear solo el doble de código que otros desarrolladores, pero con muchos menos defectos.
Neil Slater
2
Su punto sobre el ejercicio depende de muchas cosas. En particular, su ciclo de trabajo. Si un taladro funciona las 24 horas del día, los 7 días de la semana, y funciona cuatro veces más rápido, y se descompone el doble de veces, debe, AL MENOS, considerar la productividad del taladro. Porque si cuesta menos del doble que un taladro normal, y puede usarlo, es un mejor valor. Ya sabes, economía. Le dice que considere el valor de su trabajo, en comparación con el costo de la misma. Su relación costo beneficio es dos veces mejor que la de sus pares.
nomen
1
@nomen Oh, pero estoy de acuerdo: la gente debería tener eso en cuenta. Pero ellos?
JvR
20

Suponiendo que produciría la misma "cantidad" de código que sus colegas en el 20% de su tiempo, podría gastar 4 veces más en realmente depurar el código y hacerlo perfecto, lo que reduciría aún más su índice de errores. Entonces podrías llamarte un buen programador.

La pregunta más importante es por qué codifica 5 veces más que los demás en lugar de apuntar a la calidad. ¿Es esto algo que tu ego te dicta o tu jefe te obliga?

También debe considerar los costos para corregir un error. Cuando lo encuentre temprano, es posible que aún esté "dentro" del código lo suficiente como para solucionarlo rápidamente. Si aparece solo después de otro mes de desarrollo, podría ser difícil de encontrar o incluso forzarlo a cambiar grandes partes del código ya programado.

Parece que tienes el conjunto de habilidades para producir código, y podrías hacerlo increíble si te enfocas en la calidad en lugar de la velocidad. Pruébalo un rato, supongo que te gustará.

El siguiente problema es obtener el reconocimiento (hablar dinero) para su mejor desempeño. Hable con su jefe y pregúntele cómo proceder, después de todo, es su compañía y su dinero, y si quiere que produzca menos errores, también debe decidir de qué manera sucede.

asombro
fuente
11
OP está entregando el 500% de los puntos de historia de los otros miembros del equipo con un 60% menos de defectos por punto de historia, y ¿quieres cambiar la forma en que trabaja?
Justin
66
" La pregunta más importante es por qué codificas 5 veces más que los demás, en lugar de apuntar a la calidad, [...] enfócate en la calidad en lugar de la velocidad " - Me alegraste el día, hombre. Quien haya votado esto: haga sus tareas básicas de matemáticas. Para decirlo sin rodeos: contrataría inmediatamente el OP y me negaría a contratarlo.
JensG
1
Las matemáticas pueden estar equivocadas, pero creo que el punto es válido. Prefiero contratar a alguien que busque una mayor calidad para trabajar en mi empresa actual. Sin embargo, las necesidades varían, especialmente según la industria y el tamaño de la empresa.
Michael Durrant
1
Prefiero contratar a alguien que haga lo que su jefe le pide que haga, en lugar de quejarse de eso en Internet. A veces, el jefe lo sabe mejor.
Dawood dice que reinstalará a Monica
8

Los desarrolladores pueden ser brillantes, incluso geniales, con una aptitud para comprender y codificar solo, sin ser buenos desarrolladores. Un buen desarrollador crea un trabajo de calidad y mejora todo el proyecto.

No digo que sea usted, pero uno de los programadores más frustrantes con los que he trabajado escribió más código que nadie en el equipo, y tuvimos buenas personas en el equipo. Seguimos los compromisos con un software de clasificación, por lo que fue casi una competencia para algunas personas. Produjo franjas de código, dejando atrás documentación CERO, bosques impenetrables, y de hecho hizo que mi código fuera difícil de entender (¡puedo hacerlo solo, muchas gracias!). Finalmente, casi descarriló el proyecto, porque se convirtió en un espectáculo individual. La gente no podía seguirlo. No estábamos sincronizados como equipo. De hecho, reescribimos algunas de sus características años después, solo para recuperar la capacidad de mantenimiento.

Lo que quería de él era reducir la velocidad y pasar más tiempo: 1) Mejorar la calidad de la base de código 2) Comunicarse con el equipo 3) Trabajar en cosas que ayudaron a otros, así como ayudarlo a terminar características / historias 4) Reparación loco

No estoy de acuerdo con medir la productividad por líneas de código, pero es una métrica clave. ¿Su contador de código incluye comentarios? Si es así, hay una manera fácil de mantener su salida de línea al tiempo que reduce su "proporción de errores"; simplemente aumente la calidad y cantidad de comentarios que escribe. Los comentarios rara vez tienen errores (aunque pueden) y, en general, no tenemos suficientes comentarios de calidad. Estoy no condonando código de la inflación, pero el acto de comentar es como una mini revisión de código, que obliga a pensar, refactor y mejorar.

Codenheim
fuente
1
Un buen punto No estoy de acuerdo en agregar comentarios (ya que un código más claro y legible es mejor), y medimos por punto de historia completo, no líneas de código. Siento que hago un buen trabajo con esto (las revisiones de código ayudan a las personas a ayudarme a aclarar las cosas), pero +1 porque ciertamente no todos lo hacen.
Telastyn
1
No me refiero a agregar comentarios de pelusa / repetitivo. Acabo de suponer que usted es como la mayoría de nosotros, y no comento lo suficiente. Sí, manténgase alejado de los comentarios sin valor, especialmente el arte ascii elegante, a menos que sea un buen humor :)
codenheim
44
En mi experiencia, los comentarios frecuentemente contienen errores.
Dawood dice que reinstalará a Monica
No es el tipo funcional y medible ...
codenheim
66
@DavidWallace, en mi experiencia, el código frecuentemente contiene errores. No significa que dejes de escribirlo.
Charles E. Grant
4

Tratar de iluminar la administración no es un comienzo. Hay un viejo cliché: "¿Vas a creerme a mí oa tus ojos mentirosos?" Lo que preocupa a tus jefes son los errores. Ninguna cantidad de racionalización les dirá que es aceptable. Es más del doble de arriesgado. Además, no eres el único afectado por tu conteo de errores. El control de calidad tiene el doble de trabajo tratando de identificar sus errores, por lo que la administración querrá que haga menos de ellos.

La mejor solución es reducir la cantidad de errores que produce , punto. No solo la administración será más feliz, sino que usted también lo será. ¿No quieres? Porque estoy bastante seguro de que por mucho que disfrutes alardeando de que superas a tus compañeros de trabajo por un factor de cuatro, te encantaría decir que lo haces haciendo la misma cantidad de errores, o incluso menos, que ellos.

Como usted dijo, "... la tasa de errores cometidos en el código ... tiende a verse afectada por los procesos utilizados al escribir el código y después de que se escribe el código". Si desea modificar la velocidad a la que produce errores, tendrá que cambiar los procesos que utiliza para escribir código.

Los programadores usan métodos de producción para producir código, al igual que una línea de ensamblaje usa métodos para producir algún objeto producido en masa. De acuerdo, las prácticas de la industria del software se parecen más a la reducción de chucherías de las ramas que se encuentran en el bosque. Pero como estamos produciendo máquinas, debemos emplear el mismo rigor y disciplina que se usa para las máquinas de alta velocidad de producción en masa.

Eso incluye las mismas técnicas utilizadas en la producción en masa para reducir la tasa de defectos: análisis de la causa raíz para determinar por qué se producen errores y cambiar el proceso para que no se produzcan. O al menos eso que atrapas antes que el control de calidad.

  1. Haga una lista de sus errores. Probablemente ya tienes uno gracias a los chicos de QA. Posiblemente categorizado también. Tipo de error, gravedad, el punto en el que se inyectó el error en el código, etc.

  2. Elija la categoría más grande de errores. Como su volumen es tan alto, primero debe orientar esa categoría. Otras categorías incluyen las más fáciles de encontrar y las más fáciles de hacer.

  3. Al saber dónde se introducen esos errores en el código, considere realizar cambios en esa fase (y anteriores) que eviten que ocurran esos errores, y formas de facilitar su detección en esa fase.

  4. Asegúrese de ver los incidentes no relacionados con la programación, ya que pueden marcar la diferencia en la calidad de su trabajo. Música de fondo, interrupciones, comidas, trabajar demasiado tiempo sin descanso, hambre, etc.

Lo que encuentre puede llevarlo a ir más lento. Por otro lado, puede ayudarte a producir aún más rápido, ya que tendrás menos necesidad de volver a trabajar las cosas que ya has dejado atrás. Tal como está, cuatro veces más código no está cerca de ser un orden de magnitud mejor que sus compañeros de trabajo, por lo que cambiar su proceso es definitivamente el camino a seguir.

Huperniketes
fuente
3

Cambie su objetivo de producir la mayor cantidad de código para ayudar a la empresa a avanzar más.

Como parece que tiene muchos colegas más tiempo adicional disponible, el mayor efecto que puede tener en una entrega más rápida de funciones y correcciones de errores es ayudar a sus colegas.

Ayude a sus colegas a

  • utilizando revisiones de código para mejorar la calidad y la educación del código.
  • creando automatización de procesos para hacer su trabajo más rápido y sus vidas más fáciles.
  • escribiendo mejores pruebas con ellos
  • atacando el código técnico para mejorar la base del código
  • ser el tipo que siempre está disponible para ayudar a otros.
  • herramientas de escritura / mejora que ayudan con la productividad del desarrollador
  • haciendo caso a la gerencia para mejores herramientas / equipos / condiciones de trabajo para sus compañeros de trabajo si tiene más influencia.
  • preparando y liderando sesiones educativas sobre cómo escribir un mejor código.
  • practicando la humildad
Michael Durrant
fuente
1

Entonces, ¿cómo lidiar con el hecho de que una mayor productividad conducirá a un mayor número de errores?

Su jefe es la única persona que puede responder esto en su caso. Hable con él, señale su mejor relación y deje que él decida. Si su decisión no tiene sentido, es hora de buscar una empresa con su forma de pensar.

Como profesional, debe poder trabajar con cualquier condición dada del cliente, solo asegúrese de que comprenda las consecuencias. Un buen gráfico de errores / historias puede ayudar a su jefe a comprender cuánto se hundirá su productividad si se toma el tiempo para producir menos errores.

También debe tener en cuenta estos puntos:

  • complejidad de las historias, por ejemplo, envoltorios simples de captador / definidor versus cálculos estadísticos o programación en tiempo real o incluso estadísticas en tiempo real ...
  • gravedad de los errores, si se trata de pequeños errores tipográficos en los campos de texto o resultados de cálculo incorrectos, el programa se bloquea
  • cuesta arreglar los errores, tanto si lo hace ahora, más tarde o si alguien más tiene que entender su código porque se fue
Tormenta de marta
fuente
0

La situación es que trabajas cuatro veces más rápido que el programador promedio, pero cometes el doble de errores en un período de tiempo determinado. En relación con la cantidad de trabajo que realiza, en realidad comete la MITAD de tantos errores como "promedio".

Puede intentar señalar sus bajos errores en la proporción de trabajo, o incluso los errores en el producto completado (que puede completar en un cuarto del tiempo normal). La mayoría de los jefes lo aceptarán.

Hay algunos jefes que no lo hacen porque trabajan con una mentalidad de errores de "tolerancia" por vez. Luego, puede reducir su ritmo de trabajo, hacer DOS VECES tanto trabajo como el promedio en un tiempo determinado, y cometer los mismos (o menos) errores porque tiene más tiempo para verificar su trabajo.

Tom Au
fuente
0

Si su jefe quiere que mejore la calidad de su trabajo, entonces mejore la calidad de su trabajo.

Debería apuntar a cero errores, no apuntar a producir solo el doble que el próximo mejor programador.

Dawood dice que reinstalar a Monica
fuente
66
Cero errores es un objetivo en gran medida inalcanzable que a menudo no es rentable.
Telastyn
77
Esa no es una excusa para no reducir su tasa de error. Si su jefe quiere que produzca un mejor código, entonces es hora de producir un mejor código, no de poner excusas al respecto.
Dawood dice que reinstalará a Monica
44
Solo dije que debes apuntar a cero errores, no que debes lograrlo. Piensa en tiro con arco. No soy bueno en tiro con arco: nunca he alcanzado el "10" en el centro del objetivo. ¿Debo apuntar al anillo "7", porque "10" sería demasiado difícil?
Dawood dice reinstalar a Mónica
66
Sí, pero tu jefe dice que tu trabajo NO es "suficientemente bueno". En otras palabras, deberías hacerlo mejor. No has dado una buena razón por la que no puedes hacerlo mejor. Toda esta discusión me parece que alguien está tratando de inventar excusas para producir código lleno de errores. "Estoy en un equipo de desarrolladores muy lentos y, por lo tanto, tengo que cometer el doble de errores que todos los demás". ¡Por favor!
Dawood dice que reinstalará a Monica
3
En cada ciclo de lanzamiento, está produciendo el doble de errores que sus pares. Los errores son caros de encontrar y caros de arreglar. Por lo tanto, su jefe tiene que presupuestar los recursos para solucionar sus errores; y es el doble para tus errores que para los del siguiente tipo. Por lo tanto, su jefe quiere que produzca menos errores, independientemente de lo que esté haciendo el resto de su equipo. Tal vez él sepa que tienes más experiencia que el resto del equipo y, por lo tanto, debería ser capaz de producir menos errores. En cualquier caso, no veo por qué te quejarías de tener un jefe que quiere que produzcas menos errores.
Dawood dice que reinstalará a Monica
0

Debes decirle a tu jefe que las métricas que está usando son bastante defectuosas. Si observa las pérdidas de balón de los guardias en la NBA, encontrará que tienden a tener un número mayor que los delanteros. Pero eso se debe a que están manejando más la pelota. Si un guardia no titular juega 1/5 tanto como un guardia inicial y gira la pelota más de 3 veces en promedio .vs. un guardia inicial que gira la pelota 7 veces por juego; a primera vista, podría parecer que el guardia inicial es peor. Pero, si divide el número de pérdidas de balón por el número de minutos jugados, entonces claramente el guardia inicial tiene números mucho mejores en función de los minutos jugados.

Del mismo modo, tiene números mucho mejores si la cantidad de errores se divide por la cantidad de puntos de historia completados. Entonces, eso es lo que le propondría a su gerente. Cambie la métrica para que sea la cantidad de errores divididos por los puntos de historia completados, o al menos agregue una nueva métrica para esto si se necesita la cantidad total de errores por desarrollador. Pero, dado que algunos puntos de la historia son mucho más difíciles y complejos que otros puntos de la historia, puede haber y habrá bastante variación, y el gerente también debe tenerlo en cuenta.

Lo que no creo que debas hacer es reducir la velocidad.

Bob Bryan
fuente
0

Medir el valor agregado

Argumenta que lo que realmente cuenta es el valor que agregas. Luego ve e introduce una medición aproximada (manual) de eso:

  • Estime el valor de la funcionalidad que produce
  • Resta tu salario
  • Reste el costo estimado de sus errores (al menos el costo para corregirlos)
  • Reste el costo estimado de todas las demás Deudas técnicas que produzca

El resto es su valor agregado. Del mismo modo para todos los demás.

Estas estimaciones son difíciles, pero incluso las aproximadas pueden hacer el punto. Y el simple proceso de discutir estas estimaciones es útil para el equipo y el proyecto.

Lutz Prechelt
fuente
-1

Los principales programadores tienden a escribir código muy regular que es fácil de depurar y comprender, utilizan las herramientas disponibles (análisis estático, errores del compilador, código de depuración) al máximo. Además, los mejores programadores ya aprendieron el valor de las pruebas unitarias a través de su propia experiencia.

Entonces, aunque la cantidad inicial de problemas por línea es la misma, los problemas se eliminan más rápido.

zzz777
fuente
la pregunta señala que esto no ayuda: "Traté de señalar que estoy produciendo errores a la mitad de la velocidad de mis pares (y soluciono el doble), pero es difícil de vender cuando hay gráficos que dicen que produzco el doble de errores ... "
mosquito
Esto es relativo y bastante subjetivo, ¿no? No sé qué significa el código "regular". Yo diría que los mejores programadores intentan utilizar todas las bibliotecas y construcciones de lenguaje disponibles para su máximo beneficio en términos de productividad y expresividad, lo que debería hacer que el código sea muy fácil de entender por otros programadores de alto funcionamiento ... pero podría hecho de ser extremadamente difícil de entender por menor a los programadores intermedios, especialmente aquellos que no están familiarizados con los conceptos arquitectónicos más avanzados, control de flujo, estructuras de datos ...
Aaronaught
En mi humilde opinión, la grandeza se define por el largo historial y el 90% de los ingenieros de software vivos nunca tuvieron la oportunidad de conocer a grandes. Traté de resumir mis impresiones de dos grandes programadores con los que trabajo. El código "regular" significa: (a) las mismas cosas se hacen de la misma manera en todo el código producido, (b) es fácil de interpretar una modificación, y (c) es definitivamente opuesto a "fácil de entender por otros programadores en funcionamiento ... ".
zzz777