¿Es común tener tiempo de inactividad en un trabajo de programación? [cerrado]

En mi empresa, encuentro que hay algunos días en los que hay muy pocas tareas que hacer. Me propongo investigar para aprender cosas nuevas sobre mi oficio en estos días.

Yo diría que, en promedio, tengo aproximadamente un día por semana que no hay mucho que hacer (o alguna combinación de tiempo durante la semana).

Me gustaría saber si esta es una situación común en los entornos de desarrollo de software, y la respuesta a esta pregunta varía entre el trabajo a tiempo completo y el contrato.

Sí, diría que puede haber mucho tiempo de inactividad si terminas en una situación en la que esperas una respuesta de un cliente o gerente sobre cómo proceder cuando te encuentras con un problema de diseño.

Otra instancia es cuando un servidor se bloquea en su entorno de desarrollo y no puede continuar el desarrollo hasta que se haya resuelto.

Una última situación en la que he experimentado un tiempo de inactividad (como consultor) cuando había una brecha extraña entre cuando un proyecto finalizaba y comenzaba el siguiente.

Dicho esto, también creo que es una señal de mala gestión cuando sus trabajadores no están totalmente utilizados. Debería tener otras tareas en las que debería poder trabajar en caso de que el servidor se bloquee. Por lo general, en mi empresa, si llegamos a un obstáculo con algo, vamos a actualizar el wiki del proyecto y / o vamos y hacemos el aprendizaje asignado (todos tienen un tema específico que se supone que deben aprender en el tiempo de inactividad).

En lo que respecta a los empleados asalariados y contratados, creo que los empleados asalariados tienen más tiempo de inactividad y trabajadores contratados / consultores, pero ese es simplemente el caso de los trabajadores contratados que tienen un costo más alto para la empresa y solo los traen cuando se necesita. programadores más / específicos.

Por lo que dices, parece que tienes un 20% de tiempo de inactividad, que es mucho y daría a entender una mala gestión.

Es común en la industria, pero si un equipo se maneja bien, entonces los gerentes deben tener una 'tubería' fácilmente disponible de proyectos internos y / o de menor prioridad que puedan asignarse a pedido. Idealmente, estos involucrarán nuevas tecnologías y / o bibliotecas. En mi experiencia, la asignación de personas para trabajar en la documentación del código o la actualización de wikis no es bien recibida por los desarrolladores, que por naturaleza normalmente son más felices cuando realmente desarrollan algo.

Otro enfoque que he visto es enviar a las personas a cursos de capacitación de tiempo completo de hasta dos semanas por vez, para mejorar el equipo de desarrollo con el conocimiento que se necesitará en el futuro.

En general, si usted es un contratista y se encuentra sin trabajo activo en una empresa, será mejor que comience a buscar otro puesto, porque probablemente será el primero en ser despedido si la empresa llega a una recesión.

Desde mi experiencia, es relativamente común. Aunque solíamos tener, gratis sin nada que hacer, días generalmente después de la finalización de alguna fase del proyecto, cuando se está evaluando ... generalmente duraría hasta una semana más o menos, incluso antes de que recibiéramos una respuesta de ellos, y luego continuamos nuestro trabajo en el proyecto.

Sin embargo, no puedo decir si esto es una práctica en toda la industria.

En mi empresa tengo un par de semanas así (sí, semanas) por cada dos meses más o menos. No estoy seguro de si es común estar semanas sin trabajo, pero sí, siempre puedes mejorar durante el tiempo libre.

En mi lugar de trabajo tenemos tiempo de inactividad cuando:

1. La red / los servidores son problemáticos
2. Nada inmediato que hacer (por ejemplo, esperar a que las reuniones establezcan requisitos)
3. Esperar a que alguien termine algo que necesita para hacer su trabajo (aunque esa no es exactamente la mejor idea)

Cuando se comparte el tiempo de inactividad, que para mí es aproximadamente el 5% del tiempo, generalmente voy a hablar con la gente, me quito la cabeza, escucho algunas bromas.

Cuando me encuentro sin nada importante que hacer, tengo un directorio con toneladas de libros, que leo cuando se me permite, o entre largas sesiones de compilación (o algo equivalente), etc.

Pero a pesar de que hago esto, tengo que reconocer algo (lo que me hace un pecador):

Nuestro trabajo como programadores es desarrollar nuestras carreras en casa para que nuestro jefe no nos despida o algo así. No es el trabajo del jefe para que pueda mejorar a sí mismo con su dinero (el tiempo que usted está pagando).

Pero de todos modos, como alternativa, a veces en lugar de leer, hago otras cosas, como idear scripts o ideas útiles, escribir documentos y presentaciones sobre mejoras metodológicas, etc.

Eso también cuenta como superación personal porque te hace pensar y te hace útil para otros desarrolladores, que incluso podrían recordarte por eso algún día, cuando cuenta. Pero lo importante es que vale la pena el dinero que le pagan mejor que leer libros ...

En mi experiencia, depende completamente de la industria y de quién lidera el proyecto.

Algo me dice que las respuestas a esta pregunta estarán muy sesgadas, ya que las únicas personas con tiempo para leer y comentar en este sitio son aquellas que no tienen mucho trabajo por hacer. En mi trabajo anterior, NUNCA hubo tiempo de inactividad. Tuvo mucho que ver con lo bien que se desacoplaron y organizaron los proyectos. Si no está bien organizado, trabajar en múltiples proyectos al mismo tiempo puede generar problemas al tratar de fusionar los cambios y, en realidad, es más rentable no hacer nada por un momento que complicar demasiado las cosas.

La mayor parte del tiempo de inactividad con el que me encuentro suele ser al final del año financiero y / o al final del año (temporada de diciembre, ya que la mayoría de los clientes se van de vacaciones). La compañía "cierra" por varias razones y TI no tiene implementaciones durante 2 a 3 meses. Por lo tanto, no hay cambios.

Sucede: durante este tiempo, evaluamos todos los cambios / proyectos experimentados en el año, descubrimos dónde mejoramos o faltamos y encontramos una solución para mejorar mejor para la próxima temporada / período.

No te preocupes