Wednesday, May 11, 2011

Programming Should Be Relaxed, Care-Free and Easy

While I'm on the subject of last week's New England Code Camp, there was another statement made during one of the sessions which stuck with me.  This was a session early in the day where Richard Hale Shaw was talking about maintaining focus and tracking progress in one's software development career.  The format of the discussion was interesting.  He started out by making 20 statements about software development while we noted to ourselves whether we "agree" or "disagree" with each statement.  Then the session progressed with discussions about each one.

The statements were in many cases intentionally vague.  The idea we ended up focusing on was that context is key in many of these things.  And, of all the statements that were made, the one that stuck with me the most was:
Programming should be relaxed, care-free and easy.
The room was divided on this one, which wasn't uncommon among most of the statements given that we all inferred our own context based on our own experience.  This one also generated a good bit of discussion.  Time didn't permit very much, though.  The basic idea we got out of the discussion was that what we do is difficult by nature and we enjoy challenges and all that good stuff.  We don't want things to be stressful, but "easy" just doesn't happen in the real world.

But, at least for me, that didn't really resolve the statement.  I still stayed in the "agree" camp.   Thinking about it, I keep circling back to a point I shared with the group about how it all depends on how you define your terms.  Let's define these ones...

  1. Relaxed - Well, we can all agree that work shouldn't be stressful.  Stress begets poor results.  Every good manager knows this, and every programmer wants to work for a good manager.  Sure, sometimes stress happens.  Sometimes deadlines are tight.  But, honestly, that's what managers are for.  If a project is unrealistically managed and the stress of it trickles down to the developers, then the project is in danger.  The developers should be relaxed.
  2. Care-free - I can see how this one can have a lot of different meanings to a lot of different people.  At first one may picture a kind of hippie-like carelessness to the world around you.  This, of course, isn't a good approach to programming.  My interpretation was a little different.  When I think "care-free" I'm reminded of an instruction given to the American during a sparring match in The Last Samurai:
    "Mind the sword, mind the people watch, mind enemy - too many mind"
    This is where the developer should be.  He shouldn't have external cares pressing him while he's working.  His team (manager, project manager, tech lead, etc.) should keep those things out of the way.  The developer should be able to remove these external influences and work in a care-free, worry-free environment.  The work being produced by the developer is the only concern.  If that work has value to the company, then the environment which produces that work has value to the company.
  3. Easy - This was the one that most people didn't like.  Again, it's a matter of definition.  Easy is the opposite of difficult, that's easy.  But at the same time, difficult is not the same thing as challenging.  I certainly agree with the overall opinion that what we do is by its nature challenging.  It's interesting, it requires intelligence and focus.  However, just because what we do is challenging doesn't mean it's also supposed to be difficult.  That's a cop-out for people who don't want to make it easy.  Making it easy takes effort, it takes time, it takes work.  But the result is that it should be easy in the sense that it should be enjoyable.  This goes back to the "relaxed" bit earlier.  The job itself is challenging, but the act of going to work and doing the job should be easy.
As it was in the session at Code Camp, I'm sure there are lots of differing opinions.  That's part of what makes the profession so enjoyable.  But, for me (emphasis mine)...
    Programming should be relaxed, care-free and easy. 

    Tuesday, May 10, 2011


    I've been kicking around a thought in my head for a few days now, and I'm not sure where to go with it.  (Or if there even is anywhere to go with it.)  The idea struck me while I was at New England Code Camp this past Saturday, specifically in a session with MS-Joe on JavaScript in ASP.NET.  (Great speaker at workshops like this, by the way.  I'd love to attend more interactive stuff with this guy.)

    He was talking about jQuery selectors and such, and someone in the audience asked, "So it uses CSS to select elements?"  Joe replied with a little explanation, but essentially said, "Yes, it uses CSS selectors."  Immediately I was compelled to raise my hand to clarify... "Well, it's not so much that it uses CSS selectors.  Think of it more that jQuery and CSS use the same selectors to identify elements in the DOM.  It doesn't really belong to either of them."  This prompted a very short discussion about how one can decorate elements with classes that have no CSS purpose and serve only for jQuery selection.  Joe said, "That's interesting, and I can't say I've ever used classes for non-CSS purposes before jQuery."

    I didn't want to derail the session, so I kept my ongoing thoughts to my self where they've been stirring for a few days.  But ultimately, my thought was...
    Can one effectively think of class specifications on HTML elements as analogous to interfaces on class implementations?
    For some reason I'm fascinated by this question.  What are the implications, if any?  From the point of view of the selectors, it makes sense.  For example, if you want all of the "td" elements in the document, you can select them by their type.  Essentially, you're looking for a particular element implementation, "td."  Class specifications, on the other hand, are element-agnostic.  You can select by "myClass" and get all elements which have that class, regardless of their type.  Basically, all elements which implement the "myClass" interface regardless of the implementing type.

    Does this even mean anything at all?  Is there any direction to take this?  I'm not sure.  Maybe I'm just mulling over the obvious, but for some reason the very concept of it intrigues and excites me.  Or maybe as I dive further into serious JavaScript application programming (I'm loving MooTools, by the way), someday this will make for an interesting and useful object-oriented approach to DOM manipulation.

    It's just... interesting.