¿Darle a un desarrollador una máquina de desarrollo más lenta da como resultado un código más rápido / más eficiente? [cerrado]

Supongamos que les doy a mis desarrolladores una máquina que grita rápidamente. VS2010 basado en WPF se carga muy rápidamente. Luego, el desarrollador crea una aplicación WPF o WPF / e que funciona bien en su caja, pero mucho más lenta en el mundo real.

Esta pregunta tiene dos partes ...

1) Si le doy a un desarrollador una máquina más lenta, ¿eso significa que el código resultante puede ser más rápido o más eficiente?

2) ¿Qué puedo hacer para brindarles a mis desarrolladores una experiencia IDE rápida, mientras les doy experiencias de tiempo de ejecución 'típicas'?

Actualizar:

Para el registro, estoy preparando mi respuesta imparcial a la gerencia. Esta no es mi idea, y ustedes me están ayudando a corregir las solicitudes equivocadas de mi cliente. Gracias por darme más municiones y referencias a dónde y cuándo abordar esto. He hecho +1 en casos de uso válidos, tales como:
- optimizaciones específicas de programación del lado del servidor
- laboratorios de prueba
- la posibilidad de comprar un mejor servidor en lugar de las mejores tarjetas gráficas

Absolutamente

También es cierto que los gerentes deben realizar todas las reuniones en Pig-Latin. Mejora sus habilidades de comunicación en general para que estén en desventaja al hablar oraciones simples. Tendrán que confiar más en las expresiones faciales y el lenguaje corporal para transmitir su punto de vista y todos sabemos que de todos modos es al menos el 70% de toda la comunicación.

Los directores financieros deben usar solo un ábaco y tiza. De lo contrario, terminan confiando demasiado en 'datos en bruto' y no lo suficiente en su 'instinto'.

Y se debe exigir a los vicepresidentes y superiores que celebren todas las reuniones de negocios importantes en entornos que distraigan, como campos de golf, mientras están semi intoxicados. Oh chasquido ...

La respuesta es (seré audaz y diré) siempre

NO .

Desarrolle con lo mejor que pueda obtener con su presupuesto, y pruebe en la gama de equipamiento min-max spec que implementará.

Hay emuladores, máquinas virtuales, máquinas reales con probadores que pueden probar el rendimiento para ver si es un factor.

1) Muy, muy poco probable. No, y sus desarrolladores pueden poner algo desagradable en su café por sugerirlo. Tiempo que sus desarrolladores pasan esperando que el código se compile o que el IDE haga lo que esté haciendo o el tiempo que no estén dedicando a mejorar el código. También interrumpe su flujo mental. Mantenga sus mentes en el problema y serán mucho más eficientes resolviendo ese problema.

2) Proporcione a cada una una segunda PC que represente las especificaciones más bajas que desea que admitan realmente, con un conmutador KVM para ir entre eso y su estación de trabajo real.

Me gustan los largos tiempos de compilación. Me da más tiempo para trabajar en mi currículum.

Esta es una idea terrible. Desea que sus desarrolladores sean lo más productivos posible, lo que significa darles una máquina lo más rápida posible, para que no se queden sentados todo el día esperando que las cosas se compilen. (Ligeramente OT, pero también ayuda a no bloquear el acceso a sitios potencialmente útiles con WebSense y similares). con especificaciones similares, y asegúrese de realizar una prueba temprana y, a menudo, para asegurarse de que no va por el camino equivocado en términos de opciones tecnológicas.

El desarrollo debe realizarse en el mejor entorno que sea factible. Las pruebas deben realizarse en el peor entorno posible.

Si me dieran una máquina lenta, me pasaría el día optimizando el proceso de desarrollo y no optimizando mi código entregado. Entonces: ¡NO!

¡Los programadores de sistemas integrados se topan con esto todo el tiempo! Y hay una solución de dos partes:

1. Sus requisitos deben especificar el rendimiento X en el hardware Y.
2. Prueba en hardware Y, y cuando no obtengas rendimiento X, errores de archivo.

Entonces no importará en qué hardware trabajen sus desarrolladores.

Una vez que haya hecho eso, supongamos que un equipo más rápido puede ahorrarles a sus programadores media hora al día o 125 horas en un año. Y supongamos que cuestan $ 100,000 al año con beneficios y gastos generales (ridículamente bajos para Silicon Valley), o $ 50 por hora. Que 125 horas * $ 50 / hora es $ 6250. Entonces, si gasta menos de $ 6250 al año en hardware de desarrollo rockin 'por programador, está ahorrando dinero.

Eso es lo que debe decirle a su gerencia.

Tim Williscroft dijo más o menos la primera mitad de esto en un comentario, y en un mundo justo, obtendría la mitad de los puntos que obtenga esta respuesta.

Agregado el 24 de octubre:

Mi ex empleador tenía esa teoría, y les ayudó a gastar alrededor de $ 100 millones.

Son un conglomerado con sede en Japón que estaba acostumbrado a contratar programadores en Japón, Corea y China. La gente allí es genial con el uso de hardware de desarrollo horrible, días de trabajo de 13 horas, dormir en sus escritorios y no tener una vida. Así que pensaron que cuando adquirieron una conocida empresa de Silicon Valley para hacer un sistema operativo de teléfono celular basado en Linux, esos californianos tontos que querían equipo moderno eran simplemente prima donnas y realmente no tenían una buena razón para ello (como la productividad).

Cuatro años más tarde, el sistema operativo funcionó como una mierda, todos los horarios se vencieron, y los clientes se enojaron y rescindieron los contratos de derecha a izquierda. Finalmente, el proyecto del SO fue cancelado, y un gran porcentaje de la fuerza laboral mundial del conglomerado fue despedido durante el último año. Y, francamente, no quisiera haber sido uno de los ejecutivos que tuvo que explicar a los accionistas a dónde se fue todo ese dinero y esfuerzo.

No fueron solo las máquinas de lento desarrollo las que causaron este fiasco. Hubo muchos otros errores estratégicos y tácticos, pero eran el mismo tipo de cosas en las que las personas que trabajan en las trincheras podían ver venir el choque del tren, y se preguntaban por qué los tomadores de decisiones no podían.

Y la marcha lenta fue sin duda un factor. Después de todo, si está bajo la pistola para entregar a tiempo, ¿es realmente algo inteligente retrasar deliberadamente el trabajo?

En programación, hay un viejo dicho que dice que " la optimización prematura es la raíz de todo mal ". Creo que has logrado crear con éxito otra "raíz" (o al menos la primera rama) de todo mal. De ahora en adelante, podemos decir "la desoptimización prematura del desarrollador es la raíz de todo mal".

En resumen, la respuesta es que esto solo ralentizará su tiempo de desarrollo y dificultará aún más el mantenimiento. Los tiempos de compilación tomarán más tiempo, la búsqueda de código en el disco será más lenta, la búsqueda de respuestas en línea tomará más tiempo y, lo que es más importante, los desarrolladores comenzarán a utilizar su código de forma prematura para incluso poder probar la funcionalidad necesaria.

Ese último punto es el tema más crítico y no se menciona en muchas de las otras respuestas. Puede obtener su primera versión bien, pero luego, cuando desee actualizar el código en el futuro, encontrará que la optimización prematura de los desarrolladores alejó su código del buen diseño y lo acercó a "tengo que hacerlo en menos trabajo para mantener mi trabajo "estilo de código. Agregar funciones adicionales se volverá más difícil porque las optimizaciones elegidas en ese momento pueden ser innecesarias y bloquear su código en una ruta de hacks semi-optimizados además de otros hacks semi-optimizados.

Como ejemplo de esto, imagine que el requisito mínimo del sistema de su versión actual es una máquina de procesador único de velocidad algo lenta. Coloca a los desarrolladores en esta caja y se les ocurre una solución intrincada de un solo subproceso que se basa en muchos hacks porque querían desarrollar el producto rápidamente. Ahora, 5 años después, tiene una nueva versión del producto que tiene un requisito mínimo de una máquina con doble procesador. Desearía poder separar limpiamente partes del programa que puede ejecutar en paralelo, pero la decisión que tomó hace 5 años que obligó a sus desarrolladores a crear un software hacky ahora le impide usar toda la potencia de su nuevo requisito mínimo. .

Lo que debe hacer es agregar una fase al final de su ciclo de desarrollo donde realice pruebas de aceptación en los cuadros de límite inferior. Ciertamente, parte del código será demasiado lento debido a la máquina más rápida del desarrollador, pero puede aislar esa parte y optimizarla allí. El resto de su código se mantiene limpio y mantenible.

Veo que su pregunta dice: "¿Puedo forzar a mis desarrolladores a que optimicen antes de tiempo dándoles máquinas de desarrolladores pobres pero que aún obtengan un buen código?" Y la respuesta es no.

Lectura interesante, todas esas respuestas.

Pero creo que la mayoría de las personas que responden aquí están perdiendo el punto. La pregunta, como lo leí, no es (solo al menos) acerca de dar realmente a los desarrolladores un P1 para hacer un código más rápido.

El punto es que una gran cantidad de software hoy es tan lento o incluso más lento que el software que usamos en el último milenio a pesar de las computadoras mucho más potentes. A juzgar por las respuestas aquí, la mayoría de los desarrolladores no entienden esa pista. Esto es muy obvio en las aplicaciones web. Este sitio es una muy buena excepción, pero muchos sitios tienen una portada en 1 mb. ¿Qué obtengo por esperar a que se descargue? No lo sé. Creo que parece tratarse de una ignorancia del desarrollador que no respeta el tiempo que el usuario necesita gastar en él, o peor aún si paga por mb. La cuestión es que todas esas páginas web ni siquiera contienen imágenes de alta resolución. A menudo es solo un código basura entregado desde un entorno de desarrollo. Bueno, por supuesto, no es un código basura, supongo, pero no me da ninguna ganancia como usuario.

En general, no se trata solo de optimizar el código, sino de elegir no incluir las cosas que se ralentizan más de lo que ofrece.

Hace unas semanas comencé una computadora portátil desde 1995. Windows 3.x estaba en funcionamiento en muy poco tiempo. La base de datos de la que debería obtener algunos datos comenzó antes de que la tecla enter se liberara por completo (casi al menos).

Sé que hoy obtenemos mucho más de nuestro software, pero también tenemos computadoras muchas veces más rápido. ¿Por qué la industria del desarrollo no decide mantener la velocidad del software desde 1995 y hacer que las personas compren nuevo hardware porque quieren una nueva funcionalidad? Hoy es más como si los programas y sitios web de todos los días obligan a las personas a comprar nuevo hardware para hacer exactamente las mismas cosas que antes. Pero, por supuesto, de una manera más elegante.

Tengo que decir que creo que el desarrollo de Linux parece manejar esto mejor. Las distribuciones de Linux han estado por muchos años muy por delante de Windows incluso en la fantasía con muchas cosas interesantes como ventanas animadas. La cosa es que a pesar de eso han trabajado en las computadoras de hoy e incluso de ayer. No solo en hardware de vanguardia.

A estas alturas supongo que muchos desarrolladores tienen un nivel poco saludable de adrenalina. Sí, encontré una manera de devolver algo de frustración de todos los que esperaban frente a:
servidor sql de oficina (iniciando la consola de administración) arcgis (iniciando y usando) acrobat reader (iniciando) agresso (usando, al menos como aplicación web) Windows (mirando y usando, bueno, todavía no he probado 7). Páginas web .net (descargando)

y así

Me siento bien :-)

Saludos
Nicklas

1) Si le doy a un desarrollador una máquina más lenta, ¿eso significa que el código resultante puede ser más rápido o más eficiente?

Hemos estado creando software durante las últimas 6 décadas, y todavía recibimos preguntas como estas. Parece más como otro intento de cortar esquinas. Sin ofender, pero vamos, ¿crees que la pregunta es incluso lógica? Piénselo en estos términos (si puede): desea construir un vehículo 4x4 que pueda operar en condiciones difíciles, lluvia, barro, lo que sea. ¿Va a colocar a sus ingenieros y a la línea de montaje debajo de los elementos solo para asegurarse de que el vehículo resultante pueda operar en ellos?

Quiero decir, ¡Jesucristo! Hay desarrollo y hay pruebas. Las pruebas se realizan en un entorno diferente y más duro, o el desarrollador sabe cómo armar un banco de pruebas en su propio entorno de desarrollo de una manera adecuada para las pruebas de estrés. Si no puede, reemplácelo con un mejor desarrollador.

2) ¿Qué puedo hacer para brindarles a mis desarrolladores una experiencia IDE rápida, mientras les doy experiencias de tiempo de ejecución 'típicas'?

Deberías preguntar eso a tus desarrolladores. Y si no pueden darle una respuesta objetiva y válida, debe reemplazarlos con desarrolladores reales.

Pero para entretener la pregunta, brinde a sus desarrolladores (suponiendo que tenga buenos desarrolladores), buenas herramientas y buen hardware, lo mejor que pueda pagar. Luego, configure un entorno de línea de base común más bajo en el que debe operar su software. Ahí es donde deberían realizarse las pruebas. Es una práctica de ingeniería mucho mejor tener un entorno de prueba que sea distinto del entorno de desarrollo (preferiblemente uno que le permita realizar pruebas de estrés).

Si sus desarrolladores son buenos, deberían haberle comunicado esto (suponiendo que se los haya pedido).

Resulta en un grupo de desarrolladores de bitchin. Esto es lo suficientemente difícil como es, no empeoremos la experiencia.

Sin embargo, le recomendaría que tenga un hardware similar a sus usuarios en un entorno de prueba o control de calidad para resolver cualquier problema de rendimiento. Es una buena idea.

Romperé la norma y diré que sí SI Y SOLO si están escribiendo software de servidor. Ríete todo lo que quieras, pero el equipo más eficiente que vi fue un grupo de muchachos Perl con terminales Wyse. Esto fue a fines de la década de 1990, era una tienda de fotografía de la Universidad y estaban escribiendo software de cuadrícula espacial (que básicamente solo calcula). Sin embargo, estaban hablando con algunos RS / 6000 de modelo tardío relativamente potentes.

Solo para agregar interés al evento, había un programador ciego allí. Estaba completamente impresionado.

Esta no es una mala idea, pero desea que sus desarrolladores tengan un entorno de programación rápido.

Posiblemente podría implementar esto dándoles a sus programadores dos máquinas: una caja de desarrollo rápida y una caja de productos más lenta (posiblemente virtual) para la prueba.

Algunos ajustes del proceso de compilación VS podrían hacer que la implementación en la caja de prueba sea la norma, con la depuración remota.

Hay otras formas de considerar forzar a sus codificadores a desarrollar un código más eficiente: puede incluir objetivos de rendimiento y uso de memoria en sus pruebas unitarias, por ejemplo. Establecer presupuestos para el uso de la memoria también es un objetivo excelente. También establecer presupuestos de peso de página para el código html.

El problema no es que el desarrollador construya código ineficiente en una máquina rápida, el problema es que no ha definido las métricas de rendimiento que deben medirse.

Debe definirse, como parte de los requisitos del producto, un objetivo específico que se pueda medir en todas las computadoras en función de la experiencia requerida del cliente. Existen muchos sitios web (Check SpecInt) que le permiten relacionar su computadora con otros tipos de computadoras.

Esto es bueno por muchas razones. Le permite definir el hardware mínimo compatible más fácilmente para que pueda limitar la cantidad de quejas de los clientes: todos sabemos que la mayoría del software se ejecuta en la mayoría de las computadoras, es solo una cuestión de rendimiento, si establecemos nuestras especificaciones para que las personas en el rango de requisitos mínimos tiene un rendimiento razonablemente aceptable, limita las quejas de los clientes, y luego, cuando un cliente llama, puede usar los puntos de referencia para determinar si realmente hay un problema, o si el cliente simplemente no está satisfecho con la forma en que se supone que funciona el producto.

Estoy convencido de que tener una computadora más lenta para el desarrollo da como resultado un código más rápido, pero esto tiene un precio. La razón es que he experimentado esto de primera mano: después de un largo tiempo de viaje, compré una netbook para trabajar en el tren, una netbook que es más lenta que cualquier computadora que he comprado en los últimos 5 años. Debido a que todo es muy lento, veo muy rápidamente cuando algo es insoportablemente lento en este netbook, y soy consciente de los puntos lentos mucho más rápido (no es necesario comparar todo el tiempo). Trabajar en una netbook realmente cambió la forma en que me desarrollé.

Dicho esto, no estoy abogando por hacer esto, especialmente en un entorno profesional. Primero, es desmoralizante. El hecho mismo de que casi todo el mundo dijera la idea ni siquiera tenía sentido demuestra que los programadores reaccionan mal ante la idea.

En segundo lugar, tener todo más lento significa que las cosas que puede hacer en una máquina rápida (toma aproximadamente 1 minuto) ya no son factibles en una máquina lenta, debido a la pereza, etc. Es una cuestión de incentivo.

Finalmente: el código producido puede ser más rápido, pero casi seguramente tarda más en producirse.

Punto 1, NO! Studio está diseñado para ejecutarse en máquinas decentes y ese requisito solo se ha vuelto más potente con cada versión. En realidad, puede bloquear algunas versiones de studio si activa intellisense y utiliza una caja de núcleo único no HT.

En el punto # 2 hay algunas características en los proyectos de prueba que le permiten limitar algunos recursos. No son perfectos, pero están ahí. VPC o imágenes VM de baja especificación para un trabajo bastante bueno de ser restringido también. He tenido usuarios que se sientan en máquinas malas para hacer pruebas ocasionalmente para que puedan ver las implicaciones de las funciones que han solicitado.

No, de hecho, generaría más errores porque no realizarán tantas pruebas y no utilizarán herramientas adicionales como los perfiladores. Bríndeles las mejores máquinas que pueda pagar (incluido el hardware de aceleración de gráficos si es un desarrollador de juegos o una tienda de gráficos) y haga que prueben dentro de máquinas virtuales. Las especificaciones de VM se pueden ampliar o reducir según sea necesario.

Creo que esta es una pregunta interesante, y no elegiría un "no" tan rápido. Mi opinión es: depende de qué tipo de equipo de desarrollo estamos hablando. Ejemplo: si está liderando un grupo que se postula para el concurso anual de programación ICFP, tal vez tener buenos resultados después de una pequeña cantidad de tiempo de desarrollo en un clúster HPC no significa necesariamente que la solución que encontró sea buena. Lo mismo puede decirse si está escribiendo algún algoritmo científico o numérico: en su viejo AMD Duron 600 MHz con 64 MB de memoria, se ve obligado a tener cuidado con la forma en que está haciendo las cosas, y esto puede afectar incluso algunos diseños opciones

Por otro lado, un programador / científico / lo que sea inteligente debe tener cuidado de todos modos. Pero me encontré escribiendo algunos de mis mejores códigos cuando NO tenía computadora y tenía que tomar notas en papel. Esto puede no aplicarse para grandes proyectos que involucran grandes marcos, cuando un IDE es estrictamente necesario.

Una cosa es segura: las máquinas rápidas y los buenos resultados inmediatos hacen que los programadores (malos) se echen a perder y pueden ser una de las razones de la basura que encontramos en las computadoras.

Trabajo en un paquete que demora aproximadamente una hora en compilar en mi máquina 8G de 8 núcleos (compilación completamente limpia). También tengo una computadora portátil relativamente baja que pruebo. La computadora portátil de gama baja no administra dos compilaciones completas durante un solo día de trabajo.

¿Soy más productivo en la máquina rápida con algunas pruebas deliberadas realizadas en la computadora portátil, o debo hacer todas mis compilaciones en la computadora portátil?

Tenga en cuenta que estos no son números inventados.

Es una demostración manipulada en la que normalmente no necesito hacer una compilación limpia todos los días (puedo hacer muchas pruebas en módulos individuales), pero incluso las compilaciones parciales muestran aproximadamente una diferencia de orden de magnitud en los tiempos de compilación / enlace .

Entonces, el problema real está en mi máquina más lenta, una construcción típica es lo suficientemente larga como para ir a tomar una taza de café, mientras que en mi máquina más rápida solo puedo tomar un poco de café.

Desde el punto de vista del trabajo, prefiero desarrollar en una máquina rápida. Puedo cumplir los plazos de manera mucho más confiable. Por otro lado, imagino que si la administración me obligara a desarrollar en mi máquina lenta, obtendría mucha más navegación web, o al menos leer libros.

Curiosamente, trabajé en una startup donde terminamos haciendo esto. Creo que en realidad funcionó bastante bien, pero solo debido a la situación específica en la que estábamos. Era una tienda mod_perl donde la recarga automática de clase realmente funcionaba correctamente. Todos los desarrolladores usaron vim como su IDE de elección (o usaron algún software de edición remota). El resultado final fue que se perdió muy poco tiempo (si lo hubo) esperando que el código se compilara / recargara, etc.

Básicamente, me gusta esta idea IFF: hay un impacto insignificante en el ciclo de desarrollo para todos los desarrolladores, y solo afecta la operación en tiempo de ejecución de su código. Si su código está compilado, preprocesado, etc. de todos modos, entonces está agregando tiempo para "reparar el error; probar; siguiente" ciclo en el que los desarrolladores están trabajando.

Desde el punto de vista interpersonal, las personas nunca se vieron obligadas a usar los servidores lentos, pero si usaba los servidores lentos, no tenía que hacer nada de su propio mantenimiento o configuración. Además, esta configuración existió desde el principio, no puedo imaginar tratar de vender esto a un equipo de desarrollo establecido.

Después de releer su pregunta original, se me ocurre que una cosa que me aterroriza perpetuamente son los entornos de desarrollo que difieren de los entornos de producción. ¿Por qué no usar una máquina virtual para la ejecución de código que puede paralizar durante el tiempo de ejecución sin afectar la estación de trabajo de desarrollo? Últimamente, he estado usando / amando VirtualBox.

Voy a romper la tendencia aquí también.

Anécdota: trabajé para una empresa holandesa de desarrollo de software que actualizó 286 computadoras a 486-es (sí, soy tan viejo). En cuestión de semanas, el rendimiento de todas nuestras bibliotecas internas se redujo en un 50% y los errores aumentaron ... Una pequeña investigación mostró que las personas ya no pensaban en el código durante el proceso de depuración, sino que recurrían al código sucesivo 'rápido' -> compilar -> prueba -> corregir (código) etc. ciclos.

Relacionado: cuando comencé una subsidiaria para esa misma compañía en los EE. UU., Terminé contratando programadores rusos porque estaban acostumbrados a PC con menos funciones / menos potencia y eran codificadores mucho más eficientes.

Me doy cuenta de que estos fueron tiempos diferentes, y que los recursos eran mucho más escasos de lo que son hoy, pero nunca deja de sorprenderme cómo, con todo el progreso que se ha hecho en el frente del hardware, el resultado neto parece ser que cada paso adelante es negado por una programación más descuidada que requiere especificaciones mínimas más altas ...

Por lo tanto ... creo que los programadores deberían verse obligados a probar sus aplicaciones en máquinas que no excedan la potencia de cómputo 'Average Joe' y las especificaciones de hardware.

El hardware es menos costoso que el tiempo de desarrollo.

La mayoría de los cuellos de botella se encuentran en la base de datos, no en la PC cliente, pero eso no excusa las pruebas en máquinas más lentas que el desarrollador. Use herramientas de prueba para probar la optimización.

Absolutamente no. Ofrezca a sus programadores la mejor computadora portátil que el dinero puede comprar, un teclado de su elección, múltiples pantallas grandes, una oficina privada, sin teléfono, refrescos gratuitos, todos los libros que quieran (que sean relevantes), viajes anuales a conferencias tecnológicas clave y Obtendrás excelentes resultados. Luego pruebe en las combinaciones de hardware / software / navegador / ancho de banda de límite superior e inferior.

Este es un pensamiento interesante (darles a los desarrolladores una máquina lenta puede llevarlos a optimizar más).

Sin embargo, la solución se enmarca de una mejor manera: ponga el tiempo de respuesta en los requisitos para los programas y tenga una máquina de gama baja disponible para pruebas.

Además, si tiene un compilador / lenguaje realmente genial, es posible que pueda idear diferentes formas de generar código y elegir el mejor. Eso solo sería ayudado por una computadora más rápida.

Otros han respondido que, en general, desea que los desarrolladores tengan máquinas rápidas. Estoy de acuerdo. No omita la RAM (desea tener la mayor cantidad de memoria posible), algunos procesos de compilación requieren mucho uso del disco.

¡Es posible que desee deshacerse de los antivirus en las unidades de compilación! Eso solo se ralentiza y puede ser un factor de desaceleración extremadamente fuerte.

Es posible que desee que los desarrollos se desarrollen en Linux si es posible. Las herramientas son mucho mejores para todo tipo de tareas adicionales (solo grep para algo en un archivo, etc.). Esto también elimina el antivirus.

Mi Macbook Pro en el trabajo tiene unos años. Entre Linux y Windows (para probar las peculiaridades de IE) vms, así como un par de navegadores web y terminales abiertos, la rueda giratoria OSX aparece mucho. Adivina lo que hago cuando gira, me siento y espero. En este caso, una máquina lenta reduce la productividad.

Para muchas aplicaciones, el problema es hacer que los desarrolladores prueben con conjuntos de datos del mundo real antes de que estén "listos". Para aplicaciones interactivas, se requeriría una máquina de prueba de línea de base / VM.

Trabajo en una máquina lenta con Windows95 y me permite escribir de manera eficiente inteligencia artificial MindForth en Forth y JavaScript.

Preguntar a los programadores si los programadores deberían obtener un buen hardware es como preguntarle a un hombre gordo si le gusta la comida. Sé que este es el intercambio subjetivo, pero aún así ... ¿vale la pena hacernos la pregunta? :PAGS

Dicho esto, por supuesto, estoy de acuerdo con la mayoría: NO .