[SATLUG] IO-InfoOnly: PHP Eats Rails for Breakfast

[K. Spoon]

On Wed, Dec 06, 2006 at 01:14:56AM -0600, Travis H. wrote:
> On Tue, Dec 05, 2006 at 07:29:32PM -0600, K. Spoon wrote:
> 
> **** IMPORTANT PARAGRAPH FOLLOWS ****
> 
> > On Tue, Dec 05, 2006 at 06:01:24PM -0600, Travis H. wrote:
> > > Of course, this assumes the code isn't being padded, that the
> > > code quality and density is equivalent... obviously anyone can
> > > unroll loops the cut-and-paste way...
 
> You missed a whole paragraph when reading, and thus, an important
> assumption in the scenario.

I didn't miss it... it was a stupid premise.  Like I said, few people
write elegant code on their first pass, and someone who's churning out a
lot of code is someone who's banking on the compiler or the QA team to
catch their mistakes.
 
> > If you absolutely must use SLOC to gauge performance, your emphasis
> > should be on producing *LESS*, not more.
> 
> I can easily produce 0 error-free lines of code every day, non-stop,
> for days, even weeks on end, in any language and on any project.
> Clearly that makes me the best coder you've met.  And, I can do it
> holding down ten or more similar jobs.  How much is it worth to
> you?  I'm feeling generous, so if it goes into six figures, I'll
> even come by and corrupt your source code repository. $$$$!!!!

If you can accomplish the tasks I set out for you by producing 0 lines
of code, not only will I pay you six figures but I'll even throw in
royalties on the software revenue.

Please go take a look at the anaconda source for RH's installer and then come
back here and tell me more is better.

Or, to use an example that hits a little closer to home since I seem to
recall that you work at Rackspace... Would you agree that a tech support
person who closes 100 tickets is more valuable than the one who closes
1?

Of course, this assumes the tickets aren't just being closed, that 
solution quality and problem density are equivalent... obviously anyone can
just go in and fix a DNS entry and close a ticket... 

-- 
K. Spoon <kell at spoonix.com>