community software lab computer icon

Sites running our code



Small Funding A/B tests
domestic violence
packaged divorce
more happy users
small success
It has been a year
management by objective not for me
not open jobs/ 10 year pre
2 page accademic paper
micro pair programming parking
other people's poverty
marathon dental work
matching funds
Life Support Tech Tip
party (good) downtime (bad)
<insert something clever here>
rant: stupid children
Parker 2007
Services for Paul Hansen
FYI CSL audit ZIP code sort
status: quo
finance fiduciary responsibility
goofy pile
on time for once
prodigal update
embrace failure and anxiety
new yearhelpW
better late than never.t
boomer grant funded for $20,000
simple and laughing at failure
Fransico franco still dead
drunken master
PARTY !!! planning utec monks festival IRS
coffee lunch irs spam utec
control panel | bonuses | spam | virtual
We're People People Too
[an error occurred while processing this directive]

Valid XHTML 1.0!

FUNDRAISING              (not so much)

KAREN ZGODA (good work)

These past (4) years Karen Zgodahas been an excellent board president.
Despite teaching (4) classes a semester, getting a PhD and working the
odd shift at the senior center and library, she's found the time to
supervise me 1-3 hours a week, run the board meetings and push us all to
do better work.

[Karen's website ]

She's stepped off the board. We miss her and her good work very much,
but are comforted by the knowledge that she's left us in a better place.


It all sounds very nice. set objectives, measure progress toward
objectives. Reward people if they meet the objectives, punish them if
they fail. It doesn't matter if people show up on time, clean, sober and
ready to work. Results matter, not affect, not attitude. The more
problematic somebody's work is, the more the supervisor is at fault for
not clearly defining the tasks.

The really fine manual proves that that when the work is easy to measure
***AND** control, measurement by objective is the way to go.

  [good measurement book]

For example, my marathon training goes better when I do exactly as the
textbook schedule tells me. There is a lot of scientific research
designed to help middle aged runners. I find my last race time on the
chart and then follow the chart. If I do more than is scheduled, I
increase the risk of injury. If I do less, I get passed by a more
disciplined 65 year old wearing a speedo.

  [marathon training]

Unfortunately, writing good code isn't as simple as training for a
marathon.  see:

The problem is that it is very, very easy to pick the wrong objectives,
measure the wrong things or (worst!) measure only some of the right things.

In my small experience, undergraduate Computer Science education at
state universities (UML & Rutgers) is all about measuring progress
toward objectives. When you ***require*** measurements,  evaluators
create tests that are easy to grade and the evaluatees go for the grade.
The measurement of choice seems to be the number of assignments
completed to some minimal level.

It is easy to measure if somebody finished the assignment. It is time
consuming to read code (especially novice code), make red marks, point
out that a function should do one thing only, that globals are naughty,
etc,etc.  Most code is shit because nobody reads it and with tact and
sensitivity points out problems.

Useful evaluation is time consuming, messy, subjective and full of
potential for unpleasant conflict. I presume to hope that unit tests,
zealous refactoring, decent documentation and clean code create a
structure that reduces the need for messy evaluation, but until we have
these things, messy is how we roll here at the Ashram.

TESTS (unit & integration)

For those of you who already have the testing religion and want it
challenged, Just read the prophet Joel's words that mildly relate to

Except where he talks about "those breathtakingly good-looking young
men", I (somewhat) disagree with Joel. After Joel, ***if you are a
coder*** click around  the magic of Devel::Cover

For those who don't speak geek, A "unit test" is a way to test a
subroutine (a 'unit' of code). so given:

	   sub add {return $_[0]+$_[1];};

You have tests:

	  print "passed" if add(2,2) == 4;
	  print "passed" if add(0,0) == 0;

If you change the definition of add(), you can re-run your tests and
know if you've broken something.

An "integration test" is a way to test how the units of code fit
together, a way to test the whole application. Often this is done by
hand by humans who type and click their way through "Add a new Agency"
or "Categorize a program".  An integration test automates this process.
The test script does all the typing and clicking.

Knowing your code  (probably) works is useful.  However, that's not the
best part. Testing forces  you to think about your code.  For example,
you eliminate naughty globals because they make code hard to test.

Unfortunately, testing takes effort, time and faith. If you have trouble
getting your curly braces in the right place, you won't think you are
smart enough to write unit tests. If you have a deadline, meeting the
deadline is more important than writing the tests.  ---Even if in the
long run, the tests will save you time.

On average, people volunteer with us for 6 months before getting a
market rate job or finding some other reason to leave. We have a lot of
new people touching our code, it is extra important that we have tests
and test coverage. I can micro-manage less if I know tests are shaping
people's thoughts and catching dumb mistakes. (especially my dumb mistakes)

Usually, status message feedback is mixed. Strong positives outnumber
strong negatives. I've coasted in my complacent assumption that despite
what Paul says [1], making some people LOL is the price you pay for
pissing other people off.


For my  last message:

...Feedback was entirely negative. Quotes:

    "I have already spent too many
    years of my life reining in
    wayward software engineers who
    think they are special.[..] I
    am resigning effective

     "Were you drunk ?"

     (laughing) "Poetry?
     You must have been
     sleep deprived"

     "A lot like stuff you've
     already done. "

Ah well, Andy Kaufman was not appreciated in his lifetime either:


Right now The lab has:

   $257 in the checking account:
 -($500) in an loan (to me)
   $190 in monthly pledged donations.

See the checkbook register:

Our big need is a cash reserve to cover the cost of rent and utilities.
We keep hearing rumors that the university will give us the boot.
Generous monthly expenses would be approximately:

  $300 office space (20x30 room in clean, heated warehouse.)
  $150 Co-location for a server
  $100 phone & office Internet

Nicer hardware would be good. Thanks to MD, who made a $500 donation and
our friends at a youth center with a nice basement, we've upgraded from
12 year old computers with big CRT monitors to 4-7 year old computers
with 20 inch flat screen  monitors. This is hugely better, but there is
some remaining room for improvement.

Money for conferences would be swell. For each $600 chuck we have
registration & travel money to send (1) person to a very nice Perl
conference, that has been a good value in the past.

  [Perl Conference]

  [trip report from past conference]

Moving closer to fantasyland, It would be cool to have $10,000 per year
to pay me. Over the past 10 years, when I've made that amount of money,
I've avoided credit card debt. Taking a few more side jobs won't kill me

Moving deep into fantasyland, for each $35,000 per year, we could keep a
programmer, even after they got skilled up.  Market rate is $40,000 to
$60,000 for junior programmers, but we're fun to work with.

You can donate at:


This status message was:

  dignified:                        Y/N/Other ?
  self-indulgent:                   Y/N/Other ?
  Understandable by smart non-tech: Y/N/Other ?

Other thoughts: