¿Cómo se mide la productividad o las horas de trabajo en los trabajos de desarrollo de software? [cerrado]

Una persona nueva en el mundo laboral, esto es en lo que me concentraría:

Conozca las expectativas de su supervisor con respecto al tiempo y la asistencia. Algunos lugares tienen horarios de trabajo más flexibles que otros, algunos lugares tienen la expectativa de trabajar de 60 a 80 horas a la semana. Mucho de esto se centra en qué tipo de negocio tiene la empresa. Por ejemplo, hay empresas que facturan el tiempo a los clientes. Una empresa como esa va a tener diferentes expectativas que una que crea aplicaciones y las vende después. Y una agencia gubernamental puede tener expectativas diferentes o un programador en una empresa que en su mayoría tiene una fuerza laboral sindicalizada en una planta de fabricación. También puede depender de si se necesita soporte de producción en tiempo real o no. Si bien las expectativas de la empresa difieren, el lugar para obtener esas expectativas no lo es y ese lugar es su supervisor inmediato.

A continuación, descubra cómo es el proceso de trabajo. ¿Dónde verifica el código, cuáles son los estándares de codificación, qué herramientas se espera que use, tiene procesos de compilación automatizados o control de calidad con los que debe poder trabajar? ¿Qué tipo de pruebas hacen? ¿Qué se espera en términos de trabajar juntos? ¿Hacen programación en pareja? ¿Hacen revisión de código? ¿Son ágiles? ¿Cómo se asigna el trabajo? ¿Cómo se determinan los plazos?

A continuación, hable con su jefe inmediato sobre exactamente cómo quiere que se ponga al día y exactamente qué espera en términos de su trabajo. Es probable que al principio tengas muchas preguntas. Pregúntale si deberías acercarte a él o si hay alguien más a quien quiera guiar. Asegúrese de hablar con él sobre su primera tarea cuando esté terminada, incluso si no tienen una revisión de código formal. Es mucho mejor descubrir que vas en una dirección que no les gusta de inmediato que después de que se den cuenta seis meses después. Asegúrese de conocer la fecha límite de su primera tarea y comuníquese si ve algún problema para cumplirla.

Espere que su supervisor y usted no siempre estén de acuerdo en el enfoque. Sin embargo, recuerde que generalmente es su trabajo tomar la decisión final y usted debe aceptar esas decisiones con buena disposición, incluso cuando no esté de acuerdo. El momento de influir en una decisión es antes de que se tome. Recuerde que las necesidades o los deseos técnicos no son el único ni el más importante factor que influye en la mayoría de las decisiones. Trate de comprender qué más está afectando las decisiones con las que no está de acuerdo y eso lo ayudará a ser más convincente en el futuro. Necesitará construir una reputación de entrega de trabajo antes de que pueda tener mucha influencia en las decisiones, así que concéntrese en eso primero.

Recuerde también que en los negocios tenemos plazos que a menudo significan que no puede modificar ese último 5% de perfección. Lo perfecto es enemigo de lo suficientemente bueno. No estamos creando una obra de arte, estamos creando una pieza de software que hace algo y, a veces, es mejor publicarlo de manera imperfecta que no entregarlo en absoluto.

Es mejor hacer una pregunta que hacer una suposición equivocada. Es mejor dar malas noticias (como un problema que afecta una fecha límite) más temprano que tarde. Es mejor pedir ayuda (bueno, después de intentar resolver el problema por tu cuenta, a nadie le gusta un vampiro del tiempo tampoco) que luchar y no poder cumplir.

Asegúrese de consultar con su supervisor al menos una vez al mes (o preferiblemente con más frecuencia, pero depende de la personalidad de su supervisor) y vea qué tan bien está cumpliendo con las expectativas. Desarrollará más juicio sobre esto a medida que adquiera más experiencia, pero por ahora, realmente preste atención para asegurarse de recibir esa retroalimentación. Y cuando la retroalimentación sea negativa, haga un cambio. Su jefe tiene control sobre sus aumentos de sueldo y bonificaciones e incluso si va a seguir trabajando. Su opinión sobre tu desempeño es más importante que la tuya.

Finalmente comience a observar la cultura de la empresa. Podrá saber si hay momentos en los que está bien holgazanear o cuántas horas extra se espera para cumplir con los acuerdos o qué tan formalmente se comunican las personas.

Entonces, ¿cómo se miden la productividad y las horas de trabajo en nuestro dominio/campo?

No hay una respuesta fácil para esto. Si desea un trabajo con una productividad fácilmente medible, el trabajo del conocimiento es el campo equivocado.

Hay todo tipo de métricas inventadas y, en última instancia, sin sentido, líneas de código, cobertura de prueba, recuento de errores, recuento de funciones. Todos estos tienen inconvenientes significativos y debe sospechar de cualquiera que los use. Recomendaría no usarlos (incluso para usted mismo) como métricas, ya que puede jugar con ellos de manera trivial.

Lo que importa es "¿piensa mi supervisor que estoy cumpliendo con las expectativas?"

Esto es algo que debe hablar con su supervisor para entenderlo. Realmente no hay otra manera de saber "Estoy cumpliendo con las expectativas" que preguntándole a su supervisor. Aquí hay una buena manera de hacerlo.

Solo una nota, su actitud sobre esto es realmente crítica (y incorrecta):

Pero un cajero puede hacer su trabajo incluso cuando tiene sueño, y no necesita preocuparse por pensar si realmente merece el dinero al final del mes o no, ¡como yo!

Habiendo hecho tanto el desarrollo de software como el de caja, esto no es cierto en absoluto.

Sus artículos por minuto disminuirán significativamente si está cansado. Te llevará más tiempo resolver los problemas. Estarás físicamente cansado, lo que hará que seas más lento. Serás menos amigable con los clientes.

Estar cansado afecta tu desempeño laboral, en todos los campos.

Lo mejor que puede esperar aquí es "cualitativamente": después de un poco de experiencia en la industria, conocerá a algunos desarrolladores que obviamente son mejores que otros. Hay un meme bien conocido que dice que los mejores desarrolladores son 10 veces mejores que otros . Los números específicos se discuten mucho, pero ciertamente es cierto que hay algunos desarrolladores muy buenos, una gran cantidad de desarrolladores promedio y algunos malos también. El problema de detectar a los "mejores" desarrolladores es que sus habilidades varían: un desarrollador puede ser excelente porque escribe código que contiene muy pocos errores, mientras que otro desarrollador puede ser excelente porque escribe código que se ejecuta muy rápido.

Lo único de lo que sería muy cauteloso es de cualquier empresa que intente medir el rendimiento del desarrollador mediante métricas similares a "líneas de código escritas" o "errores introducidos". Cualquiera de ellos es demasiado fácil de jugar para que sea una medida útil de la habilidad de un desarrollador; para tomar un ejemplo específico, algunos de los mejores fragmentos de código que he escrito han sido los fragmentos que eliminaron líneas de código, por ejemplo, al generalizar algunos fragmentos dispares de código en una sola función, pero obviamente no lo habría hecho si mi productividad se hubiera medido de alguna manera por el número de líneas de código escritas.