30 Oct
2011
30 Oct
'11
12:44 p.m.
On 10/30/2011 10:27 AM, Toby Thain wrote:
I think a lot of the problem is much less "work" related than that.
Most developers I've met want super-fast development machines at work so
they can play games, watch videos, and do all sorts of other crap that
has nothing to do with actual work.
Yes, I've fired a few of these types of people. With the American
work ethic of late, though, they seem to be in the vast majority.
-Dave
--
Dave McGuire
New Kensington, PA
> [I]t's
not because it's "stupid" (which it isn't), it's because
> developers don't WANT to work on slow machines.
Wouldn't make much difference to me. Because, at least when I do it, my
activities are:
1) A *lot* of thinking
2) A little bit of typing
and
3) Stuff-all else that taxes a machine (the most demanding thing would
be a web browser and occasional unit test runs).
Are there common things that a programmer waits for? Compiles have
hardly been a burden in the past decade... The machine should nearly
always be waiting for the programmer while they think about what they
are doing. ("More thought, less code" is a whole other rant.)
I'd be equally productive on a 10 year old box; but I'd have the benefit
of knowing if I were doing something silly, performance wise. A poorly
phrased database query in a web app will be a problem on the fastest
server, as client load increases. And judging by the bloatware around,
examples surely abound in client side development. How can fast testing
machines not hide performance problems? Performance/resource bugs are
bugs too.