¿Qué puede ralentizar a un desarrollador? [cerrado]

¿Qué cosas tienden a ralentizar a un desarrollador?

Intente abstenerse de publicar respuestas que:

• ahora son lentos pero útiles en la función. (TDD, Refactorización, ...)
• enumera una distracción .

Oh, esto es fácil:

1. Reuniones
2. Más reuniones
3. Reuniones sobre la última reunión
4. Reuniones para prepararse para la próxima reunión
5. Desarrollar una presentación en power point para una reunión
6. El desarrollo de una presentación de power point para una reunión que discuta características que no se han implementado, no debería implementarse, y por cualquier razón, ese tipo de ventas saltará por completo. No puedo predecir qué documento desea que se muestre en la aplicación en función de su ubicación actual sin una conexión a Internet o acceso a su disco duro. No realmente, solo deja de pedirlo también.

Una computadora lenta

Cualquier cosa que cause cambio de contexto .

StackOverflow, programmers.stackexchange.com, etc. :)

Yo diría agotamiento.

Cualquier intento de seguir un proceso que no es adecuado para la tarea en cuestión.

Esto puede ser todo tipo de cosas, pero las más comunes que veo incluyen:

• probar metodologías que no se ajustan al código que se está probando
• Procesos que son dramáticamente más ágiles o tradicionales que los entregables.
• directrices que están destinadas a un conjunto de herramientas diferente al conjunto de herramientas seleccionado
• Principios de diseño que están fuera de escala con las necesidades del proyecto.
• utilizando un conjunto de herramientas que no es adecuado para la tarea

Todas estas cosas pueden ser inmensamente valiosas en algunos proyectos o en algunas situaciones, pero algunas organizaciones intentan hacer todo de una manera y eso lleva a un mal ajuste en otros proyectos, que a menudo es la muerte de la productividad.

Política

por ejemplo: cuando más de una persona posee los requisitos (o peor, dos intereses creados diferentes), y realizan cambios competitivos y conflictivos a los requisitos mientras el desarrollo está en marcha.

Conversaciones de otros.

y ruido en general

Muchas respuestas hablan sobre el cambio de contexto y salir de la zona, y el ruido, especialmente la conversación, es una de esas cosas que me lleva a eso.

En mi mundo cúbico, estoy rodeado de ruido y conversación por todos lados. Una vez más, el equipo de mainframe mantiene reuniones de planificación constantes en la fila del cubo. A veces, se reúnen con consultores en una oficina a lo largo de la pared, y eso tiende a provocar gritos, gritos y risas, y tengo que ir y pedirles que cierren sus puertas.

Por otro lado, la mesa de conferencias del equipo web está al otro lado de mi pared del cubo oeste, así que soy parte de cada reunión, nos guste o no. También hay una impresora en el otro lado de la pared del cubo sur, y eso siempre es bueno para charlar con personas que pasan el rato esperando sus impresiones.

La respuesta inmediata y obvia de " ¿No puedes conseguir auriculares con cancelación de ruido?" No ayuda cuando lo que quieres es silencio.

A veces, para las revisiones de códigos, llevo mi montón de papeles a la cafetería (a la hora del almuerzo, por supuesto), pero hay una televisión que suele sonar. Lo apagaré si nadie está mirando. De lo contrario, iré a buscar un cubo vacío en otro departamento en otra parte del edificio.

Si desea que sus programadores hagan el trabajo que necesitan hacer, que es predominantemente pensar, reflexionar y considerar, necesitan un entorno en el que puedan hacerlo.

Escribir demasiadas líneas de código sin pruebas adecuadas.

Falta de café de alta calidad.

tener que hacer estimaciones perfectas que no deben desviarse una vez que comienza el desarrollo, en mi opinión, es un escenario de huevo de gallina

Arreglando la construcción rota de otra persona

Reuniones sin agenda.

Una maquina lenta.

Falta de un segundo monitor.

Un ratón viejo que tiene una bola en lugar de las nuevas y bonitas.

Falta de acceso a Internet en la máquina, lo que hace que las consultas MSDN / stackoverflow / etc. sean un poco molestas.

Pasé demasiado tiempo programando

Incluso si realmente te gusta programar, pasar demasiado tiempo en él eventualmente te quemará ...

Evita todo lo que te saque de "la zona". Eso significa su bandeja de entrada de correo electrónico, su aplicación emergente de Twitter, su chat corporativo, etc.

Tener una condición de trabajo silenciosa significa también evitar ese ruido de escritorio .

Cualquier solicitud de cambio que hubiera sido más fácil de implementar si lo supiera de antemano.

Código pobre

Tener que reescribir la parte de otra persona que podría haber hecho bien el trabajo en primer lugar es el mayor sumidero de tiempo que pueda imaginar.

The Much That Slow You Down es una buena publicación de blog para esto.

...

Muchos proyectos repiten características centrales de nivel de infraestructura una y otra vez, lo que ralentiza a la empresa al ofrecer características que la diferencian de sus competidores.

...

Es inevitable que los productos y las innovaciones ayuden a reducir el tiempo que los desarrolladores dedican a tareas no diferenciadoras. La pregunta es qué forma tomarán esos servicios y herramientas.

...

Bueno, últimamente la mayor desaceleración es porque estamos desarrollando varias cosas simultáneamente que deberían haberse hecho en un orden específico. Así que estoy esperando hasta que (los nombres cambien para proteger al inocente) John termine su componente que necesito para mi paquete SSIS y Harry se demore esperando que importe los registros porque necesita algunos datos para ver para probar su exportación (alguna vez intente escribir un informe de exportación complejo cuando no hay datos en ninguna de las tablas?) y todo el mundo se ralentiza porque el diseño no está hecho y las tablas de la base de datos que necesitamos para realizar nuestras tareas aún no se han creado y es posible que ni siquiera terminen siendo lo que dijeron que iban a ser, etc.

Responde preguntas en stackexchange.com, como esta.

A pesar de que pidió no enumerar las distracciones, pueden ser un factor importante. Observe su entorno de trabajo, verifique si están siendo interrumpidos con frecuencia o si se les pide que hagan otras cosas que no están relacionadas con el proyecto.

A veces, un desarrollador puede quedarse atascado porque está haciendo algo que nunca antes había hecho y no sabe dónde buscar ayuda. Si se trata de un equipo pequeño o individual, puede ser aún más difícil. Tendemos a ser un tanto orgullosos y no nos gusta admitir cuando no sabemos cómo hacer las cosas. Además, no nos gusta pedir ayuda a otros. No hay una manera fácil de lograr que un desarrollador lo admita, excepto tal vez para preguntar si pueden cumplir con la fecha límite, o qué necesitan para cumplir con la fecha límite, y luego esperar que sean honestos. Es posible que deba ofrecer traer otra ayuda o encontrar a alguien que pueda ayudarlo.

Falta de requisitos claramente definidos, lo que los lleva a tener que resolver las cosas o tomar decisiones.

• Tener que esperar unos 15 minutos para que la PC arranque en un estado utilizable
• Esperando a que la PC cambie de aplicación
• Siendo la única persona en la oficina que tiene que hacer su propio té / café.
• Un teclado roto (¡arreglado!)
• Trabajar fuera de la oficina del Director Gerente (CEO de EE. UU.) (Y tampoco en una oficina), con solo una partición intermedia (especialmente cuando hay una reunión)
• Solo se puede acceder al jefe por correo electrónico, pero todos los demás están en el edificio
• No se me permite usar un VCS, aparentemente debería estar en mi cerebro
• Pantalla pequeña
• No permitir tiempo para descansos que no sean almuerzo
• Tener que hacer copias de seguridad del servidor remoto a pesar de tener un administrador de sistemas en el edificio
• Que me digan que haga dichas copias de seguridad manualmente.
• Ser obligado a usar un estúpido sistema de gestión del tiempo que es innecesariamente complicado
• Solo tengo una idea vaga de los requisitos dos meses después del trabajo

Podría seguir, pero es viernes y quiero olvidarme del trabajo.

• Falta de documentación (Sistema, Empresa, etc.)
• Falta de código comentado
• Una comprensión incompleta del sistema.
• Política (es decir, reuniones innecesarias, papeleo, obstáculos por parte de la administración ...)
• Documentación de requisitos incompleta
• ¡Facebook!
• ¿Demasiado sueño?

Demasiada gente en el proyecto.

Se ha visto varias veces que la administración decide, basándose en datos no reales, que necesitan agregar más personas al proyecto. Eso termina en la gente que sabe lo que está pasando necesitando detener todo para tomar las manos de personas que saben poco sobre lo que está pasando. He visto más de un proyecto de tamaño de hongo y luego voy al baño rápidamente desde allí, mientras que antes iba bien, aunque tal vez un poco lento.

Así que pasas de llegar un mes tarde debido a que no hay suficiente velocidad / demasiado para hacer y no lo haces en absoluto porque arruinaste totalmente el presupuesto de todas esas personas adicionales.

Además de las cosas mencionadas por otros, el largo camino entre decidir compilar y ejecutar su código y obtener un resultado positivo / negativo . Idealmente, este RTT sería solo un segundo, pero he visto un ejemplo de horas. Por cierto, las pruebas unitarias intentan resolver este problema.

Otro relacionado con esto es una latencia general de su entorno de trabajo. Imagine que necesitaría trabajar a través de una conexión de escritorio remoto a la computadora en el otro lado del mundo, a través de una conexión espeluznante. He estado allí. He odiado esto

• Papeleo excesivo

• Tener una dependencia de alguien que nunca está cerca (como su jefe, si necesita hacer una pregunta pero siempre está en reuniones)

• Herramientas y equipos inadecuados.

• Las personas empujan su remo sin razón (cualquier cambio visible en la interfaz de usuario está sujeto a esto) o simplemente discutiendo sobre cosas triviales.

• Cafetera rota

• Ser asignado las tareas incorrectas

El aire acondicionado no funciona.

Por lo tanto, la temperatura en la oficina alcanza los 40 grados en el verano de -5 en el invierno.

El -5 no es bueno para escribir, ya que no puedo usar guantes y escribir. Los 40, solo ralentizan mi pensamiento.

Esta es una opinión muy personal y quizás controvertida, pero planea y piensa demasiado sobre el diseño inicial o escribir código de "calidad" todo el tiempo. Hay un dicho que dice que "semanas de codificación pueden ahorrarle horas de planificación" que podría ser cierto en algunos casos.

Sin embargo, a menudo veo que los programadores intentan esbozar un buen diseño antes de comenzar a codificar. Me parece que es más fácil "comenzar", ya que a medida que programa aprenderá más sobre su problema y solución, lo que le permitirá refactorizar su solución rápidamente en un buen diseño. La mayoría de los problemas que surgen son prácticamente desconocidos al comienzo de la codificación (al menos para mi débil mente), por lo que perder mucho tiempo diseñando por adelantado es solo una pérdida de tiempo.

Esta es también la razón por la que no me gusta TDD, pierdes demasiado tiempo escribiendo pruebas, lo que hace que sea menos probable que refactorices o que tomes mucho tiempo para reescribir las pruebas. Las pruebas unitarias son excelentes para algunos casos y algunas etapas de un proyecto, pero el comienzo de uno no es uno de ellos en mi humilde opinión :)

Haga que algo funcione rápidamente y mejórelo.

Bloqueo del programador : a diferencia de otras ralentizaciones, esta es más difícil de resolver.