TITLE: Software Can Make You Feel Alive, or It Can Make You Feel Dead
AUTHOR: Eugene Wallingford
DATE: May 10, 2020  2:16 PM
DESC: 
-----
BODY:
 This week I read one of
<A HREF="https://craigmod.com/essays/fast_software/">
   Craig Mod's old essays</A>
 and found a great line, one that everyone who writes programs for
 other people should keep front of mind:

<BLOCKQUOTE><EM>
 When it comes to software that people live in all day long, a 3%
 increase in fun should not be dismissed.
</EM></BLOCKQUOTE>

 Working hard to squeeze a bit more speed out of a program, or to
 create even a marginally better interaction experience, can make
 a huge difference to someone who uses that program everyday.  Some
 people spend most of their professional days inside one or two
 pieces of software, which accentuates further the human value of
 Mod's three percent.  With shelter-in-place and work-from-home the
 norm for so many people these days, we face a secondary crisis of
 software that is no fun.

 I was probably more sensitive than usual to Mod's sentiment when
 I read it...  This week I used Blackboard for the first time, at
 least my first extended usage.  The problem is not Blackboard, of
 course; I imagine that most commercial learning management
 systems are little fun to use.  (What a depressing phrase
 "commercial learning management system" is.)  And it's not just
 LMSes.  We use various PeopleSoft "campus solutions" to run the
 academic, administrative, and financial operations on our campus.
 I always feel a little of my life drain away whenever I spend an
 hour or three clicking around and waiting inside this large and
 mostly functional labyrinth.

 It says a lot that my first thought after
<A HREF="https://twitter.com/wallingf/status/1258764524427100161">
   downloading my final exams</A>
 on Friday morning was, "I don't have to login to Blackboard
 again for a good long while.  At least I have that going for me."

 I had never used our LMS until this week, and then only to
 create a final exam that I could reliably time after being
 forced into remote teaching with little warning.  If we are in
 this situation again in the fall, I plan to have an alternative
 solution in place.  The programmer in me always feels an urge to
 roll my own when I encounter substandard software.  Writing an
 entire LMS is not one of my life goals, so I'll just write the
 piece I need.  That's more my style anyway.

 Later the same morning, I saw this spirit of writing a better
 program in a context that made me even happier.  The Friday of
 finals week is my department's biennial undergrad research day,
 when students present the results of their semester- or
 year-long projects.  Rather than give up the tradition because
 we couldn't gather together in the usual way, we used Zoom.
 One student talked about alternative techniques for doing
 parallel programming in Python, and another presented empirical
 analysis of using IR beacons for localization of FIRST Lego
 League robots.  Fun stuff.

 The third presentation of the morning was by a CS major with a
 history minor, who had observed how history profs' lectures are
 limited by the tools they had available.  The solution?  Write
 better presentation software!

 As I watched this talk, I was proud of the student, whom I'd
 had in class and gotten to know a bit.  But I was also proud of
 whatever influence our program had on his design skills,
 programming skills, and thinking.  This project,
<A HREF="https://twitter.com/wallingf/status/1258784548097339394">
   I thought</A>,
 is a demonstration of one thing every CS student should learn:
 <EM>We can make the tools we want to use</EM>.

 This talk also taught me something non-technical: Every CS
 research talk should include maps of Italy from the 1300s.
 Don't dismiss 3% increases in fun wherever they can be made.
-----