¿Qué hace que un entorno de desarrollo sea realmente genial?

Buen proceso de software. La aplicación del desarrollo basado en pruebas hace que los ciclos de lanzamiento sean más rápidos y más predecibles, lo que deja más tiempo para trabajar en problemas interesantes y genera menos estrés. La cobertura de prueba que requiere hace que la separación limpia entre capas sea más probable, por lo que la complejidad total es más lineal y menos combinatoria. La automatización de las versiones de lanzamiento y las pruebas de control de calidad reducen el tiempo de entrega, por lo que los errores se pueden encontrar lo antes posible y solucionarlos al menor costo. Una buena cobertura de pruebas automatizadas también permite una mayor flexibilidad al escalar grupos de software porque todos, incluso los nuevos contratados, pueden realizar cambios de manera segura con bajo riesgo de perjudicar a los clientes o retrasar las fechas de lanzamiento debido a regresiones.

No hay mal proceso de software. Si bien los bucles de comunicación y retroalimentación del proceso son buenos, el scrum no funciona bien cuando se realiza correctamente: las reuniones periódicas son una interrupción diaria del estado del flujo que reduce la productividad. Con un scrum matutino, puede evitar el cambio de contexto, aunque los ingenieros dejan de trabajar temprano para poder irse a casa, relajarse, dormir y descansar a tiempo para la reunión. El scrum es peor cuando se hace incorrectamente donde los 15 minutos de pie pueden degenerar en una sesión de 2 horas.

Buen proceso de informe de errores. Es mucho menos doloroso cuando las versiones de control de revisión están asociadas con errores, todos los artefactos relevantes se adjuntan a los informes, el entorno está adecuadamente documentado y cualquier organización de control de calidad (como profesionales que hacen mucho con errores, debe esperar más de ellos que clientes) hizo está allí. Algo de esto dicta un código post mortem automatizado que se ejecuta en los entornos de implementación de los usuarios finales.

Buena gestión de la configuración de herramientas de construcción y dependencias. Soy aficionado al nombre de / opt / company con subdirectorios comunes y de plataforma llenos de subdirectorios de la versión del paquete x (boost_1_5_1_0, boost_1_45_0, etc.). Las nuevas máquinas de construcción se pueden configurar con un par de controles de revisión. Cualquier paquete nuevo se puede desplegar con una actualización. Los entornos de compilación pueden coexistir para múltiples revisiones importantes de productos en la misma máquina con sus archivos MAKE o lo que sea que apunte a las versiones apropiadas. Esto incluso funciona para los compiladores, por lo que no tiene que lidiar con la versión obsoleta suministrada por el proveedor en la máquina de alguien que rechaza los indicadores de advertencia preferidos o genera información de depuración incorrecta.

No hay límites artificiales en entornos de construcción. Apesta cuando el producto se implementa en Linux y los desarrolladores obtienen computadoras portátiles que solo tienen permitido ejecutar versiones aprobadas de Windows o una distribución paleolítica de Linux que no ejecuta X en la máquina y no interactúa con el software de administración de configuración de la compañía para las dependencias .

Suficientes tareas que son de dificultad apropiada para los niveles de experiencia de los empleados. Las personas son más felices y productivas cuando trabajan en cosas que son un poco exageradas.

Suficiente autonomía. Los ejecutivos con cero experiencia no deberían dictar el proceso de software a equipos con décadas de experiencia individualmente y más de un siglo colectivamente. “Agregar calidad más tarde” y “Solo probar el producto completo” son apropiados para tiras Dilbert, no para el mundo real.

Tranquilo. Preferiblemente en forma de oficina con puerta. El estudio de IBM encontró que los ingenieros con oficinas privadas silenciosas eran un 40% más productivos que los que trabajan en bullpens abiertos y ruidosos. Los lectores astutos notarán que donde los costos de los ingenieros pueden costar entre $ 150 y $ 300,000 por año, las compañías pueden perder entre 60 y 120,000 dólares por año en productividad por ingeniero, lo cual es mucho más costoso que levantar algunas paredes.

echa un vistazo al presupuesto de productividad personal de Yodle. Dan $ 1500 para gastar en lo que quieras.