KAREN ZGODA
MANAGEMENT BY OBJECTIVE (not for me)
TESTS
BAD FEEDBACK ON LAST REPORT
FUNDRAISING (not so much)
REQUEST FOR FEEDBACK
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 ] http://karenzgoda.org/
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.
MANGEMENT BY OBJECTIVE (not for me)
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] http://www.amazon.com/exec/obidos/ASIN/0932633366/
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] http://www.furman.edu/first/
Unfortunately, writing good code isn't as simple as training for a
marathon. see:
http://www.joelonsoftware.com/news/20020715.html
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
testing:
http://www.joelonsoftware.com/items/2009/09/23.html
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
http://nsp.staging.testing123.net/
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)
FEEDBACK LAST STATUS MESSAGE (not good)
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.
[paul]
http://www.biblegateway.com/passage/?search=1+Corinthians+9%3A19-23&version=NIV
For my last message:
http://thecsl.org/go/fake-blog/open_jobs_10_year_pre.shtml
...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
immediately"
"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:
http://en.wikipedia.org/wiki/Andy_Kaufman#Foreign_Man_and_Mighty_Mouse
FUNDRAISING
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:
http://thecsl.org/sys/finance.d/checkbook.xls
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] http://yapc2010.com/yn2010/
[trip report from past conference] http://perlmonks.org/?node_id=268056
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
though.
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:
http://thecsl.org/go/donate/
REQUEST FOR FEEDBACK
This status message was:
dignified: Y/N/Other ?
self-indulgent: Y/N/Other ?
Understandable by smart non-tech: Y/N/Other ?
Other thoughts:
