Comments on: Interviewing programmers on philosophy http://rc3.org/2009/03/16/interviewing-programmers-on-philosophy/ Rafe Colburn on software development (and other topics) Mon, 21 May 2012 23:52:43 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Chris Adams http://rc3.org/2009/03/16/interviewing-programmers-on-philosophy/comment-page-1/#comment-4982 Chris Adams Wed, 18 Mar 2009 00:37:41 +0000 http://rc3.org/?p=9269#comment-4982 <p>My experience matches Rob's: they had free response areas most of the times I wanted a "this will make it easier for us to deal with changes" option but a first-class option would have been nice.</p> <p>I was also struck by how much my answers have changed as I've spent time using duck-typed languages. Inheritance is a lot less hazardous when you're not doing it because everything passed to key methods requires a common ancestor.</p> My experience matches Rob’s: they had free response areas most of the times I wanted a “this will make it easier for us to deal with changes” option but a first-class option would have been nice.

I was also struck by how much my answers have changed as I’ve spent time using duck-typed languages. Inheritance is a lot less hazardous when you’re not doing it because everything passed to key methods requires a common ancestor.

]]> By: Rob Drimmie http://rc3.org/2009/03/16/interviewing-programmers-on-philosophy/comment-page-1/#comment-4978 Rob Drimmie Tue, 17 Mar 2009 15:48:07 +0000 http://rc3.org/?p=9269#comment-4978 <p>One thing that really stuck out to me was that none of the options for question 12 were related to maintenance. The primary thought I have when designing any sort of object hierarchy is "how much of a pain is it going to be when I have to come back in 6-12 months to change something?"</p> <p>That is almost covered by both the "making it harder to change code" and "making it easier to understand code" options, but I really wanted a "making it easier to change code" option because that's actually what I'm trying to do - mostly because client requests result in not-irregular changes.</p> One thing that really stuck out to me was that none of the options for question 12 were related to maintenance. The primary thought I have when designing any sort of object hierarchy is “how much of a pain is it going to be when I have to come back in 6-12 months to change something?”

That is almost covered by both the “making it harder to change code” and “making it easier to understand code” options, but I really wanted a “making it easier to change code” option because that’s actually what I’m trying to do – mostly because client requests result in not-irregular changes.

]]>