estimation - ¿Cuánto de su día de trabajo se usa para codificar?
time-management (9)
Me paso aproximadamente el 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.
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 debe estimar la cantidad de tiempo que dedicará a trabajar en algo, ¿cuántas horas del día dedica a la codificación? ¿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 tus condiciones de trabajo? Oficina privada, oficina compartida, sala de equipo? ¿Codifica solo o como pareja? ¿De qué manera ha cambiado tu condición de trabajo la cantidad de tiempo que pasas codificando 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?
Para responder algunas de mis propias preguntas:
El equipo actual en el que participo solo hace una estimación de tarea bruta, por lo que es difícil hacer un seguimiento de 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. . :)
Siendo realistas, 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 mucha postergació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.
Soy un desarrollador corporativo, del tipo que Joel Spolsky llamó "deprimido" en algunos de los podcasts de . 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.
Diría que obtengo 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 trabajé no se involucraron activamente en la evaluación de procesos ágiles o desarrollo basado en pruebas, pero tampoco hicieron 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.
Lamentablemente, nadie quiere hacer soporte, por lo que la otra medida de mejora de la productividad que desearía sería una de las siguientes:
- Mejores herramientas / metodologías de prueba 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
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 feliz por eso?
¿Ojalá pudiera 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, intente explicar ese hecho a los superiores;)
Bueno, en general llego al menos quince minutos tarde, ah, uso la puerta lateral, de esa manera Lumbergh no puede verme, je je, y después de eso, llegué al espacio durante aproximadamente una hora.
... Sí, solo miro fijamente a mi escritorio; pero parece que estoy trabajando. Lo hago 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 eliminar 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 The Programmers ''Stone:
Sabemos que el estrés afecta algunas funciones cognitivas. La pérdida de esas funciones puede explicar con precisión por qué la programación es difícil y mostrarnos muchas otras oportunidades para mejorar la forma en que organizamos las cosas. Las consecuencias se extienden para tocar el lenguaje, la lógica y las normas culturales. Haga clic aquí para la Introducción ...
@Bernard Dy: He pasado probablemente el 30% de mi carrera en entornos corporativos (no lo soy 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 practiqué estrictamente ágil / XP fue en un entorno corporativo; en ese caso, probablemente 7 horas al día era un código de manos real (en un par). Nunca he estado tan agotado después de un día de eso. no estoy seguro de si eso es algo bueno, tal vez solo soy perezoso.
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, esa es una buena política, deberías tomar lo que puedas.
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 pasé con mi esposa, también me gusta salir de la ciudad y tratar de no pensar en mis proyectos; cuanto más hago que 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, sino que debería verla como algo divertido.
Soy un desarrollador de software en un departamento de I + D que trabaja 40 horas a la semana.
Paso como ... el 10% de mi tiempo realmente codificado. 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 desarrolladores de software) que 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 una buena comprensión del proyecto, la codificación es solo una formality y se desarrolla 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.