it-swarm-es.com

¿Qué puede ralentizar a un desarrollador?

¿Qué cosas tienden a ralentizar a un desarrollador?

Intente abstenerse de publicar respuestas que:

12
Tamara Wijsman

Oh, estos son fáciles:

  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. Desarrollar una presentación en power point para una reunión discutiendo características que no se han implementado, que no deberían implementarse, y por alguna razón, ese tipo de ventas saltará por todos lados. 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, en serio, deja de pedirlo también.
49
wheaties
44
TheLQ

Cualquier cosa que cause cambio de contexto .

27
Rydell

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

25
Ryan Rinaldi

Yo diría agotamiento.

17
Maniero

Cualquier intento de seguir un proceso que no se adapte a 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 de lo que justifican 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 se adapta a 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 conduce a un ajuste deficiente en otros proyectos, lo que a menudo es la muerte de la productividad.

15
Bill

Política

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

13
Chris Buckett

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 fila más allá, el equipo de mainframe mantiene reuniones de planificación constantes en la fila del cubo. A veces, se encuentran con consultores en una oficina a lo largo de la pared, y eso tiende a provocar gritos, gritos y risas fuertes, y tengo que ir y pedirles que cierren las puertas.

En el otro lado, la mesa de conferencias del equipo web está al otro lado de la pared de mi cubo oeste, así que soy parte de cada reunión, me 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 entre personas que esperan sus impresiones.

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

A veces, para revisar el código, llevo mi pila de papeles al comedor (en horas que no son almorzar, por supuesto), pero hay un televisor que generalmente suena a todo volumen. Lo apagaré si nadie está mirando. De lo contrario, 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 principalmente pensar, reflexionar y considerar, necesitan un entorno en el que puedan hacerlo.

9
Andy Lester

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

8
Fortyrunner

tener que hacer estimaciones perfectas de las que no se debe desviar una vez que comienza el desarrollo, en mi opinión, es un escenario de huevo de gallina

5
MetaGuru

Falta de café de alta calidad.

5
Robert Harvey

Arreglando la estructura rota de otra persona

5
rwong

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 evitar ese ruido de escritorio también.

4
GmonC

Reuniones sin agenda.

Una máquina lenta.

Falta de un segundo monitor.

Un ratón viejo que tiene una bola en lugar de los bonitos nuevos.

Falta de acceso a Internet en la máquina, lo que hace que consultar MSDN/stackoverflow/etc sea un poco molesto.

4
ist_lion

Pasó demasiado tiempo programando

Incluso si realmente te gusta la programación, pasar demasiado tiempo en ella eventualmente te agotará ...

4
nanda

Código deficiente.

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 puedo imaginar.

3
n1ckp

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

3
JeffO

Respondiendo preguntas en stackexchange.com, como esta.

2
tactoth

Aunque pidió no enumerar las distracciones, pueden ser un factor importante. Observe su entorno de trabajo, verifique si los interrumpen 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 algo 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 hacer que un desarrollador admita esto, excepto quizás 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 ofrecerse a traer otra ayuda o encontrar a alguien que pueda ayudarlos.

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

2
user6061

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

...

Muchos proyectos repiten características de nivel de infraestructura central una y otra vez, lo que ralentiza a la empresa en la entrega de 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.

...

2
Tamara Wijsman
  • 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 de la dirección ...)
  • Documentación de requisitos incompleta
  • ¡Facebook!
  • ¿Dormiste demasiado?
2
soran awla

Bueno, últimamente, la mayor desaceleración se debe a que 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 a los inocentes) John termine su componente que necesito para mi paquete SSIS y Harry se ralentiza 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á terminado y las tablas de la base de datos que necesitamos para hacer nuestras tareas aún no se han creado y es posible que ni siquiera terminen siendo lo que dijeron que iban a ser, etc.

2
HLGEM
  • Tener que esperar unos 15 minutos para que la PC se inicie en un estado utilizable
  • Esperando que la PC cambie de aplicación
  • Ser 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 en el medio (especialmente cuando hay una reunión)
  • El jefe solo es accesible 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 dar tiempo para descansos que no sean el almuerzo.
  • Tener que hacer copias de seguridad del servidor remoto a pesar de tener un administrador de sistemas en el edificio
  • Que le digan que haga dichas copias de seguridad manualmente.
  • Ser forzado a utilizar un sistema de gestión del tiempo estúpido que es innecesariamente complicado
  • Solo tengo una vaga idea de los requisitos a los dos meses de iniciado el trabajo

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

2
Alan Pearce

Demasiadas personas en el proyecto.

Lo he visto varias veces donde la gerencia decide basándose en datos no reales que necesitan agregar más personas al proyecto. Eso termina en las personas que saben lo que está pasando y necesitan detener todo para tomar las manos de las personas que saben poco sobre lo que está pasando. He visto más de un proyecto de tamaño de hongo y luego ir al baño rápidamente desde allí, mientras que antes iba bien, aunque quizás un poco lento.

Así que pasas de llegar con un mes de retraso debido a que no tienes suficiente velocidad/demasiado que hacer a no cumplir en absoluto porque has arruinado totalmente el presupuesto de todas esas personas adicionales.

1
MIA

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

Otro relacionado con esto es una latencia general de su entorno de trabajo. Imagina que necesitarías 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í. Odio esto.

0
Ilia K.
  • Papeleo excesivo

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

  • Herramientas y equipos inadecuados.

  • Personas que empujan el remo sin motivo (cualquier cambio visible en la interfaz de usuario está sujeto a esto) o simplemente discuten sobre cosas triviales.

  • Máquina de café rota

  • Que le asignen las tareas incorrectas

0
JohnL

El aire acondicionado no funciona.

Entonces, la temperatura en la oficina sube hasta 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, simplemente ralentizan mi pensamiento.

0
Mumbles

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

Sin embargo, a menudo veo a los programadores intentar esbozar un buen diseño antes de comenzar a codificar. Me doy cuenta de que es más fácil simplemente "ponerse en marcha", a medida que programe, 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 mente débil), por lo que perder mucho tiempo diseñando desde el principio 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 te hace menos propenso a refactorizar o lleva mucho tiempo reescribir las pruebas. Las pruebas unitarias son excelentes para algunos casos y algunas etapas de un proyecto, pero el comienzo de una no es una de ellas en mi humilde opinión :)

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

0
Homde

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

0
Darknight