¿Cuánto de su día de trabajo se usa para codificar?

Question

He estado pensando en la estimación de software últimamente, y tengo un montón de preguntas sobre el tiempo dedicado a la codificación. Tengo curiosidad por saber de personas que han tenido al menos un par de años de experiencia en el desarrollo de software.

Cuando tiene que estimar la cantidad de tiempo que pasará trabajando en algo, ¿cuántas horas del día pasa codificando? ¿Qué ocupa las otras horas no codificadas?

¿Le parece que pasa más o menos horas que la codificación de sus compañeros de equipo? ¿Sientes que estás haciendo más o menos trabajo de lo que están?

¿Cómo son sus condiciones de trabajo? Oficina privada, oficina compartida, sala de equipo? ¿Codifica solo o como pareja? ¿De qué manera ha cambiado su condición de trabajo la cantidad de tiempo que dedica a la codificación cada día? Si puede trabajar desde casa, ¿eso ayuda o perjudica su productividad?

¿Qué metodología de desarrollo usas? ¿Cascada? ¿Ágil? ¿El cambio de una metodología a otra ha tenido un impacto en las horas de codificación por día?

Lo más importante: ¿está contento con su productividad? Si no, ¿qué cambio único harías que tuviera el mayor impacto en él?

Answer 1

Soy un desarrollador corporativo, del tipo que Joel Spolsky llamó "deprimido" en un par de podcasts de StackOverflow. Debido a que mi empresa no es una compañía de software, tiene pocas razones comerciales para implementar muchas de las medidas que los expertos en software recomiendan a las empresas para lograr la productividad del desarrollador.

No tenemos oficinas privadas ni monitores duales de 30 pulgadas. Nuestro sistema de control de fuente es Microsoft Visual Source Safe. Basta de charla. Por otro lado, puedo hacer muchas cosas que completan mi día y agrego algo de variedad a mi trabajo. Participo en análisis de negocios, gestión de proyectos, desarrollo, soporte de producción, implementaciones internacionales, soporte de capacitación, planificación de equipos y mejora de procesos.

Yo diría que tengo el 85% de mi día para programar, cuando puedo enfocarme y tengo una gran tarea de programación. Pero más a menudo obtengo aproximadamente el 50% de mi día para la codificación. Si el soporte de producción (no relacionado con la codificación) es pesado, solo puedo obtener el 15% de mi día para codificar.

La mayoría de las empresas para las que he trabajado no participaban activamente en la evaluación de procesos ágiles o desarrollo impulsado por pruebas, pero tampoco hacían un buen trabajo de cascada; la mayoría de sus desarrolladores trabajaban como vaqueros de corte y pegar con impugnidad.

En ocasiones trabajo desde casa y con niños, es horrible. Soy más productivo en el trabajo.

Mi productividad es buena, pero podría ser mejor si se eliminara el factor de interrupción y el costo del cambio de contexto mental. Los gastos generales de producción y gestión de proyectos crean ambos tipos de interrupciones. Pero ambas son partes necesarias del trabajo, así que no creo que pueda deshacerme de ellas. Lo que me gustaría considerar es una reestructuración del equipo para que las personas en los proyectos puedan enfocarse en los proyectos, mientras que los demás podrían bloquear las interrupciones si se dedican a apoyar. Y luego intercambiando cuando el proyecto haya terminado.

Por desgracia, nadie quiere hacer de soporte, por lo que la otra medida de mejora de la productividad que me gustaría para sería uno de los siguientes:

• mejor las herramientas de prueba/metodologías para acelerar las pruebas unitarias
• Mejores herramientas/habilidades de análisis de negocios para mejorar la calidad del nuevo desarrollo y limitar sus contribuciones a la carga de soporte de producción

Answer 2

para contestar algunas de mis propias preguntas:

El equipo actual no estoy en qué sólo la estimación bruta tarea, por lo que es difícil de rastrear horas por día. Diría que, para mi carrera, el tiempo dedicado a la codificación ha oscilado entre el 25% (en su mayoría, gestión) y el 85% + (trabajando desde casa 4 días a la semana, reuniéndose para una reunión durante medio día una vez a la semana). Si tuviera que adivinar, sin embargo, el promedio es probablemente en algún lugar cercano al 60%.

La mayor influencia para mí en el tiempo dedicado a la codificación es la presencia o ausencia de reuniones. Cuando trabajé en proyectos ágiles con todos en la misma sala, las reuniones tendían a ser ad-hoc y muy breves, por lo que el tiempo dedicado a la codificación era muy alto. También sentí que pasaba menos tiempo, a veces mucho menos, haciendo cosas que no codificaban cuando estaba en una sala de equipo, porque es mucho más fácil perder el tiempo, accidentalmente o no, cuando nadie tiene una vista clara de su monitor . :)

Answer 3

Realísticamente, probablemente promedie 4 o 5 horas por día. Aunque es "abultado", puede haber días en los que podría haber 8 o 9 horas.

De todos los desarrolladores de software que conozco, los que escriben el código de producción (a diferencia de la investigación) 4 a 5 parecen ser el máximo de la codificación real. Hay muchas otras cosas que continúan.

Y para ser sincero, hay una gran cantidad de procrastinación. Encuentro que es un poco como los escritores bloquean. a veces es difícil comenzar, pero luego una buena sesión de 2 horas es MUCHO trabajo realizado. Es solo toda la preparación que tienes que pasar, la experimentación para asegurarte de que estás tomando el enfoque correcto. La cantidad interminable de mirar por la ventana y consultar el correo electrónico, etc. ...

Answer 4

Paso cerca del 40% de mi día de codificación. El 40% se destina a actividades no codificadoras (como pelear con nuestro servidor de compilación incompleto o averiguar por qué NUnit falló nuevamente sin mensaje de error o tratando de descubrir por qué nuestro código ha dejado de hablar con el servidor de Oracle ...) El otro 20% generalmente se gasta postergando, o en reuniones.

¿Estoy contento con mi productividad? Absolutamente no. Trabajo 7 horas/día, y gasto aproximadamente 2.5 de esa codificación. Prefiero dedicar de 5 a 6 horas de mi día a la codificación, con solo una hora dedicada a todas las demás cosas (por desgracia, una cosa que haría que eso suceda, que el primer ministro deje de jugar con los scripts de compilación todos los días) - no va a suceder). Desafortunadamente, dado que soy un desarrollador corporativo, la gerencia no ve el tiempo desperdiciado. Debido a que realizo mucho más en ese 40% de mi día que la mayoría de los drones en el edificio terminados en una semana (incluido el PM), creen que soy productivo.

Answer 5

Trabajo una semana de 37.5 horas.
30 de esas horas (80%) Se supone que debo facturar a nuestros clientes.
En realidad, encuentro que uso alrededor del 60% de codificación en sistemas de clientes reales, el 20% experimentando con nuevas técnicas y leyendo blogs, y el 20% se desperdicia en la política de la oficina y la "socialización".

¿Estoy contento con él?
¿Desearía poder mirar la pantalla 30 horas a la semana codificando mis asignaciones?

Bien. Como el 20% del tiempo se usa para mejorar mi habilidad en el arte, en el 60% de codificación efectiva probablemente produzca más de lo que obtendría en el 90% de mi tiempo si no lo hiciera.
Por otra parte, tratar de explicar este hecho a los superiores;)

Answer 6

Bueno, en general, vienen en al menos quince minutos tarde, ah, yo uso la puerta lado - de esa manera no se puede Lumbergh véanme, je je - y, eh, después de eso solo tengo espacio alrededor de una hora .

... Sí, solo miro fijamente a mi escritorio; pero parece que estoy trabajando. Hago eso probablemente durante otra hora después del almuerzo, también. Yo diría que en una semana determinada, probablemente solo haga unos quince minutos de trabajo real, real.

Para mí, cambiar de proyecto es una gran causa de procrastinación. Cuando acabo de terminar un proyecto, tiendo a postergar el inicio del siguiente requisito que se me asignó. Mi mente se siente como en el modo de codificación, pero luego tengo que estimar los gastos para crear una especificación primero. Así que tengo que pasar de la codificación a llamar a clientes y cosas por el estilo, lo que me resulta incómodo.

Lo que más me ayuda a ser productivo es cortar cualquier distracción en las primeras horas del día y comenzar de inmediato con la tarea más importante del día. Necesito entrar en el flujo lo más temprano posible.

---

recomiendo echar un vistazo a Piedra de los programadores:

We know that stress impairs some cognitive functions. The loss of those functions can precisely explain why programming is hard, and show us many other opportunities to improve the ways we organize things. The consequences roll out to touch language, logic and cultural norms. Click here for the Introduction...

Answer 7

@Bernard Dy: He pasado probablemente el 30% de mi carrera en entornos corporativos (no estoy en este momento) . Por lo general, es después de una idea de inicio fallida (o no fallida, pero fallida), o algún tipo de agotamiento/cambio. Está bien por un ratito, es agradable conocer gente de orígenes totalmente diferentes (¿quién hubiera pensado que los abogados y actuarios podrían ser tan divertidos para pasar el rato?), Pero al final, me parece demasiado difícil de conseguir. levantarse por la mañana con motivación (o después de un temor navideño que se remonta), probablemente por razones como las que define (solo falta de cuidado). Pero es una buena experiencia y una fuente de ideas al menos. Y puedes conocer personas brillantes en todas partes (no solo los programadores que son inteligentes, siempre traté de descubrir quiénes eran los verdaderos cerebros detrás de un negocio).

Curiosamente, la única vez que he practicado una agilidad/XP estricta fue en un entorno corporativo; en ese caso, probablemente 7 horas al día eran códigos reales (en un par). Nunca he estado tan exhausto después de un día de ese. no estoy seguro de si eso es algo bueno, tal vez solo soy perezoso.

Answer 8

Hago outsourcing y básicamente código todo el día, tengo dos proyectos y no tengo mucho tiempo para hacer otra cosa, lo que significa que no puedo tomar más trabajo porque no pude terminar nada, eso es una buena política, debe tomar lo que pueda.

Recuerde también que debe tener tiempo libre y lo más importante es descansar lo suficiente porque si no lo hace no será muy productivo. La clave aquí es planificación y disciplina.

En mi tiempo no codificado lo gasté con mi esposa, también me gusta salir de la ciudad e intentar no pensar en mis proyectos, cuanto más hago este equilibrio, más productivo soy.

Cuando no trabajo mucho, me gusta leer blogs de programación y también me gusta estudiar programación.

Y, por último, me gustaría decir que, en mi humilde opinión, nuestra carrera no debe verse como un trabajo, en su lugar, debería verla como algo divertido.

Answer 9

Soy un desarrollador de software en un departamento R & D que trabaja 40 horas a la semana.

Me gasto como ... el 10% de mi tiempo realmente codificando. En mis horas no codificadas, principalmente pruebo, evalúo, comparo y anoto los resultados. También paso mucho tiempo escribiendo especificaciones para el código que escribiré e investigando para el código que escribiré, participo en reuniones de lluvia de ideas para los proyectos actuales, etc.

Podría decir eso de mis compañeros de equipo (también software desarrolladores) Yo soy el que más codifica en este momento; pero depende de la tarea en la que trabajamos en cada momento. No me gustaría cuantificar realmente la codificación como trabajo duro. Si hay una buena especificación, una investigación adecuada y un buen entendimiento del proyecto, la codificación es solo una formality y continúa casi sin problemas y rápidamente.

Aquí tenemos una oficina puntual, con dos equipos. Estamos codificando principalmente solos, raramente en un par. Mi trabajo cambia mucho la cantidad de tiempo que estaba codificando; en el pasado pasaba la mayor parte de mi tiempo codificando, sin una muy buena comprensión de la codificación. Si tuviera una tarea, inmediatamente comenzaría a codificar y volver a codificar cada vez que me diera cuenta de que había hecho algo mal, y así sucesivamente. Y fue muy ineficaz.

La metodología de desarrollo está en algún lugar entre la creación de prototipos y la espiral ahora. Ha cambiado claramente el número de horas que código.

Estoy satisfecho con mi productividad, relacionada con mis plazos y objetivos.