<html><head><style> body {height: 100%; color:#000000; font-size:12pt; font-family:Times New Roman;}</style></head><body>As a developer, I can say that when you're "in the groove" you don't want ANYTHING to knock you out of the groove. When you've got your brain wrapped around a problem and are focused on writing code to make your vision run, a slow machine will break your concentration every time. The items in the Programmer's Bill of Rights, while humorous, are also very true.<br><br>I can also say that programmers as a group expect to be treated better than the average desk jockey. If you give us hardware that is "adequate" for someone who spends their day typing memos in Word, we're going to be looking for another employer as soon as possible. That's not elitism...that's professionalism. If you run your servers on hardware manufactured in the 1990's, you can expect poor performance. If you want good code from productive coders, give them good hardware.<br><br>----- Original Message -----<br>From: Dave Hala Jr <dave@58ghz.net><br>To: Central Iowa Linux Users Group <cialug@cialug.org><br>Sent: Wed, 7 Jul 2010 17:05:56 -0500 (CDT)<br>Subject: Re: [Cialug] OT Developer productivity - was: Which software to usefor a SAN<br><br>I'm sitting here wondering if the *measured* real world performance<br>isn't as important as the *perception* of its performance. For example,<br>if you ask a developer how the performance is and they say good, then<br>your job is done. If they say "it compiles slow", then it really doesn't<br>matter if its actually slow or not, that's the place where you need to<br>make an improvement.<br><br>On Wed, 2010-07-07 at 16:51 -0500, Matthew Nuzum wrote:<br>> On Wed, Jul 7, 2010 at 4:28 PM, Jeff Davis <me@digitaljeff.com> wrote:<br>> As as admin and previously been a developer, I want the<br>> developers as<br>> "comfortable" as possible. I want the infrastructure to have<br>> as little pain<br>> as possible so they are as productive as possible. If a<br>> developer is losing<br>> 15 minutes a day on an annoyance and I can fix it in an hour,<br>> I'm going to<br>> find the time to fix it. It goes both ways... so if I'm<br>> seeing<br>> something that looks to be<br>> a code problem I can hit up a developer for time right now<br>> without<br>> having to send<br>> a meeting invite and involving two BAs and a Project Manager.<br>> GTD<br>> sans bureaucracy.<br>> <br>> <br>> I wonder if there's a way you can measure wait times for users. By<br>> that I mean how long the user has to wait for their system. For<br>> example, how fast does it take helpful tool tips / intellisense / auto<br>> complete information to appear (1 second is too long). If your system<br>> does continuous builds as you work so you can see errors as you go,<br>> how long does a build take? (30 seconds is too long). How long does it<br>> take to launch the application you're developing?<br>> <br>> <br>> You should probably go watch your devs work. Find one who is<br>> especially productive and just sit behind them and watch for 10 min.<br>> Don't talk, interrupt, try to help - just watch. Maybe, if you can do<br>> this, use screen sharing or mirroring to watch from a different<br>> location (but let them know).<br>> <br>> <br>> Make careful notes about how long the developer is waiting and when.<br>> I'd worry less about boot time or startup time for the tools as long<br>> as they run fast once the dev gets going.<br>> <br>> -- <br>> Matthew Nuzum<br>> newz2000 on freenode, skype, linkedin, identi.ca and twitter<br>> <br>> "Never stop learning" –Robert Nuzum (My dad)<br>> <br>> _______________________________________________<br>> Cialug mailing list<br>> Cialug@cialug.org<br>> http://cialug.org/mailman/listinfo/cialug<br><br>_______________________________________________<br>Cialug mailing list<br>Cialug@cialug.org<br>http://cialug.org/mailman/listinfo/cialug<br><br></me@digitaljeff.com></cialug@cialug.org></dave@58ghz.net></body></html>