A Comment On RSVP’s On Meetings

While I’m thinking about it, another quick comment.  If you’re asked to RSVP to a meetup, user group, etc. please do not say “I’ll attend” unless you’re sure you’ll attend.  As dumb as it sounds we have a few people around the Metro Detroit area (not naming any names) that seem to consistently sign-up for meetups and indicate they are planning to attend and then simply never show up.

Perhaps if I explain why this is a problem my point will become clearer.  The organizers of these user groups, meetups and so forth often want to feed attendees.  In order to get the right amount of food because if we get too little some will go hungry and if we get too much food may go to waste we need an idea of how many people to expect.  Hence if you RSVP that you’re going to attend and then just don’t bother to show up you’re simply making it harder for those who run these meetings.  By the way, the people I have in my mind have done this multiple times.

If you join a meetup group because you’re interested in the topic you are not obliged to RSVP yes to attendance.  You won’t be kicked off of the meetup group’s mailing lists. But if you do RSVP yes and don’t bother to show up you may eventually find yourself removed.

Why I Am Not A Fan of Screen Sharing For User Group Meetings

So I want to capture these thoughts while I can for whatever value they may have to myself or others in the future.

Last night we did a coding dojo on building Android apps with F#.  Reluctantly, after a little cajoling from a co-worker I decided to add a Google Hangout to the meeting.  NB: While I specifically mention Google Hangout don’t misunderstand; the problems I’m addressing have been problems with pretty much any teleconferencing solution I’ve had experience with.  AnyMeeting, WebEx etc. etc. etc. all seem to have the same issues.

So I don’t think it went particularly well (others may feel differently).  And I think I’ve finally figured out my issues with the screen share/videoconferencing approach.

The technology still has some rough edges. Repeatedly last night I was sharing a screen to show people on-line some point that I was discussing.  And repeatedly the screen share simply stopped by itself. The video conferencing portion just stopped working by itself at some points too.  This issue will go away as the technology improves, of course, but we’ll also ask more from the tech so this issue will never really resolve completely.

The speaker’s focus is split. For me, the bigger issue was trying to help the developers in the room (coding dojo) and trying to assist the developers online.  There was no way I could simply talk to the people online and also address the people in the room.

The speaker ends up having to run the video conference. This is a relatively tough issue to address because the speaker has the slide deck and the speaker knows which examples he (or she) is going to show so they end up running the video conference from their machine.  It’s tough enough to give an intelligent talk without having to worry about the side issues of when you should share your screen and when you should be showing the video feed and such.  I think if I were to do this at a user group meeting again there would be a designated video conf assistant and I’d practice things with that video conf assistant at least three or four times before the actual presentation.

If others have thoughts or suggestions on these issues, please feel free to comment.  Perhaps I’m simply not seeing what may be simple answers to these issues.

Why The Defaults Matter

I often think of why I feel that it’s important to have a functional language—not just write code that’s pseudo-functional in an imperative language.  As I think this through, I wanted to record some of my ideas on the subject.

Even the best developers I’ve known are almost always inclined to take the defaults.  I mean if the default string type is ASCII then you’re very unlikely to see Unicode strings in the app unless someone specifies that this is needed.  This is not laziness; it’s simply that these developers have other issues to concentrate upon.

Why is this important?  Simply this: I’ve come to realize that default mutability is an accidental complexity–in the sense that Fred Brooks used that term in his “No Silver Bullet” essay.  Don’t misunderstand what I’m saying–mutability is necessary and appropriate.  But having all values in software mutable by default is an invitation to lots of unexpected side effects.  And this is why I really believe that functional languages will continue to gain in use.  Functional languages are immutable by default.  Impure functional languages (OCaml, F#, Clojure, and Scala among others) do allow a programmer to specify mutable quantities where it’s appropriate due to performance considerations but they default to quantities being immutable–and that’s why they’re important.  If things default to being immutable, developers will learn to work with immutable quantities and become accustomed to them in the same way they’re now accustomed to thinking in Objects.  People seem to forget that 30 years ago, OO was as much an academic discipline as Functional is now.

Every developer knows they should mark quantities as constant (or final or readonly or whichever keyword expresses immutability) but most do this only as an afterthought and they do it incompletely.  Default immutability could eliminate a whole class of side-effect errors and therefore reduce errors in our code by a large fraction of all errors present. The issue is not the question of does “const correctness” (for lack of a better way of phrasing it) make software less error-prone; the issue is getting developers who are always under impossible deadlines to use constants by default.  Languages that default to constant, immutable quantities are a large step in that direction.  This is why functional programming is important and this is why you’re going to inevitably see more and more developers gravitating toward these functional languages.

The Tech Support Effect

At a few points in my career I’ve worked in tech support.  It’s an experience I heartily recommend to every developer.  Every developer should spend at least a month or two supporting software because it helps you to understand the sorts of issues our tech support people deal with.  I really believe that too many developers, and I include myself in that group, don’t appreciate how truly valuable good technical support people are.

An interesting thing happens to many support people of long-standing.  They get a very negative impression of the software they’re supporting.  This is simple and understandable because all they hear most days are complaints about the software.  People don’t call tech support to tell them “Hey the software is working great!”  Even if 99.9% of the software is working exactly as it should, the .1% will be the part that customers call about. For lack of any better name for this phenomenon I call it the “Tech Support Effect”—that long term cynicism that sets in from hearing complaints and negativity day in and day out.  

I think the same thing happens in other areas of life as well.  The news can really depress a person quickly because the parts of our economy that are working aren’t the parts that get reported upon.  Gas may reach $5/gallon soon but no one in the news will tell you that the Europeans would be dancing for joy if gas were only $5/gallon over there.  Of course they have better mass transit but that’s another discussion. The 999 people who safely negotiate some dangerous turn on a freeway don’t make the news; it’s the 1 person who fails to make the turn that gets shown at 6 pm.  It’s easy to get a very skewed view of things.

And I definitely think this happens in software development.  We see the failings of our own software so often that we can really get down on ourselves and start to think of ourselves as idiots.  We can forget that many of us turn out thousands of lines of code that works substantially as it should when we’re shown a line of code where we forgot a semi-colon and that caused a problem for a customer.

The point is this; don’t fall for the Tech Support Effect in your own life.  All of us have things in our life we could wish would be better.  But every once in a while if you think of all the good things you’ve already got it can help to put the negative in perspective.