File /Humanist.vol22.txt, message 74


Date: Thu, 19 Jun 2008 06:02:18 +0100
From: "Humanist Discussion Group \(by way of Willard McCarty              <willard.mccarty-AT-mccarty.org.uk>\)" <willard-AT-LISTS.VILLAGE.VIRGINIA.EDU>
Subject: 22.072 Programmer (and scholarly) insecurity
To: <humanist-AT-Princeton.EDU>


                Humanist Discussion Group, Vol. 22, No. 72.
       Centre for Computing in the Humanities, King's College London
  www.kcl.ac.uk/schools/humanities/cch/research/publications/humanist.html
                        www.princeton.edu/humanist/
                     Submit to: humanist-AT-princeton.edu



         Date: Thu, 19 Jun 2008 05:54:35 +0100
         From: Neven Jovanovic <neven.jovanovic-AT-ffzg.hr>
         Subject: Humanist: Programmer (and scholarly) insecurity

Today, reading for fun, a text struck a note sounding quite familiar.

It was on the iBanjo blog: http://blog.red-bean.com/sussman/?p=96

Programmer Insecurity

(...)

My buddy Fitz and I have long preached about best practices in open source
software development -- how one should be open and transparent with
one's work, accept code reviews, give constructive criticism, and
generally communicate as actively as possible with peers. One of the main
community "anti-patterns" we've talked about is people
writing "code bombs". That is, what do you do when somebody
shows up to an open source project with a gigantic new feature that took
months to write? Who has the time to review thousands of lines of code?
What if there was a bad design decision made early in the process --
does it even make sense to point it out? Dropping code-bombs on
communities is rarely good for the project: the team is either forced to
reject it outright, or accept it and deal with a giant opaque blob that is
hard to understand, change, or maintain. It moves the project decidedly in
one direction without much discussion or consensus.

(...)

And somewhere near the end, the author even adds a bit on how tools shape
behaviour:

Moral: even though one shouldn't depend on technical solutions to
social problems, default tool behaviors matter a lot.

--- It seems that humanist scholars and programmers have lot in common
after all... with one exception: in the humanities world, you either write
your book / article / thesis (and get thrashed if you get it wrong), or
you do not. --- Or do we have subversion systems for humanities
scholarship, only I do not know about them (yes, there are procedures ---
talks over coffee and such, but how about *tools*)?

How do we "review code" (as opposed to "reviewing product")?

Yours,


Neven Jovanovic
Zagreb
Hrvatska / Croatia

   

Humanist Main Page

 

Display software: ArchTracker © Malgosia Askanas, 2000-2005