2010 08 25

From TheCommandLineWiki

Jump to: navigation, search

Contents

Feature Cast for 2010-08-25

(00:17) Intro

  • Quick review of Netanel's "Copyright's Paradox"
    • http://www.amazon.com/gp/product/0195137620?ie=UTF8&tag=thecommandl0a-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0195137620
    • An incredibly well researched discussion
      • Of the balance between copyright and free speech
    • He covers both sides quite well
    • You get a strong sense of the historical shift
      • And the key cases and events informing the narrowing
        • Of what are supposed to be the free speech safety valves
    • I especially like his deconstruction of the Blackstonian interpretation
    • Even though he is immensely critical of copyright maximalists
      • He concedes well that we need a variety of media, sources and business models
    • Like other scholars in the area, he concludes with recommendations
    • I would put his right up with the more recent work by Pam Samuelson
    • The book is not very long, just over two hundred pages
    • It is a demanding read
    • Distraction from a sentence if a paragraph
      • Can unravel the whole sense of it
    • It is pretty gripping, if you are interested in the subject
      • So distraction may not be as much of a concern
    • I am glad I bought this book as I marked pages
      • And highlight passages to go back to
    • I could see re-reading this book on a regular basis
  • No new shows on 8/29, 9/1 or 9/5

(03:56) Listener Feedback

(07:51) Hacker Word of the Week: finger-pointing syndrom

(08:23) Hacker Superstitions

  • I've seen more than a few programmers who observe superstitions
    • These aren't usually the ones with which you're familiar
      • Like throwing some spilled salt over your shoulder
    • Explaining them is often as difficult
      • Shrouded in personal or shared history
    • In form they are often as eccentric as more common superstitious practices
    • At their core, I think that hacker superstitions and the more plain variety
      • Are given credence for much the same reason
    • Invoking them is usually done as a hedge against the unknown
      • Or the seemingly unpredictable
    • In the absence of something we know, they help us deal with a situation
    • It is useful to have something, anything to do
    • It assuages our need for action of some kind
      • Even if there isn't necessarily any real effect
  • BREAK
  • Most hacker juju typically has to do with personal process
    • There are a lot of different activities involved
      • In assembling, releasing and supporting programs
    • Programmers have a great deal of choice in specifically
      • How they go about each and every one of these tasks
    • Some times techniques are chosen rationally
      • Based on formal teaching or a well argued point from a peer
    • Other times, they are developed seemingly at random
    • As much as we strive for all experiments with software tools
      • To be undertaken with rigor and to result in full understanding
      • Many times hackers arrive at a formula that works solely by trial and error
    • Tools for building software often come with a bewildering array of options
    • There isn't always the time needed to explore them exhaustively
    • Documentation is sometimes incomplete, leaving correct usage up to guess work
    • There are plenty of cracks and bad joints
      • Through which irrational beliefs can seep into daily routine
    • One former coworker described his update, build, commit cycle
      • As a superstitious practice
    • He never committed a change to source control without pull fresh updates
      • Followed by a full compile
    • This all had to be executed within a limited window
    • If he sat to long after updating or compiling
      • Then his local copy might be too stale versus the server copy
    • Bear in mind that he was usually the only committer against that particular server
    • All the same, if he failed, his irrational fear was he'd commit a change
      • That broke the build for someone else
    • This is a slightly more rational impulse than most
    • In soliciting help with this feature, an online acquaintance
      • Related the compulsion to ensure source code comments
        • Are all symmetrical
    • At first I wasn't entirely sure how this qualified as superstitious
    • When I pressed, he explained how he felt that not tending to comment symmetry
      • Might hide a real problem with matching up braces and parenthesis
    • Even though the two are not necessarily related
      • And a good editor or IDE can match up actual structural symbols like braces
      • He still clings to his need to keep comments arranged just so
    • He also shared that he is OCD a malady I suspect is common
    • Neuroses that lead to fastidiousness like this can actually be an advantage
      • At the expense of perhaps some wasted motion in coding
  • It is far too easy for the weakest link, the hacker, to fail
    • The anecdotes about personal process highlight this really well
    • It isn't necessary ignorance of what the software is doing that is the problem
    • Making a mistake in processing is all too easy
    • In the source control example
      • Getting distracted before a commit
        • Can make it easy to forget whether your local source is up to date
        • Or that you have indeed performed a good compile
    • A little wasted motion in following a superstition
      • Can save a lot of waste if a mistake is allowed to care
      • Especially in a team environment where the impact on other contributors
      • Acts as a force multiplier on the mistake
    • Breaking the build is invariable traceable back to a simple goof by someone
    • Fear of stalling the whole team can lead to some constructive habits
      • That aren't necessarily rationally tied to real risk
    • If we assessed the likelihood of a mistake occurring
      • Say by looking at some historical data on build breaks
      • We'd most likely realize that it doesn't happen all that often
    • Worrying about causing breaks can incur some intangible costs
      • That might erode a healthy team dynamic
      • Or sap momentum in a small but noticeable way
    • Having a juju, as irrational as it may be, can bring a counter intuitive benefit
    • The example of the comments and braces is similar
    • With modern tools, the probability of an uncaught unbalanced brace is low
    • Even when it does happen, all the syntax highlight and language support
      • Usually makes short work of tracking down the problem
    • Anxiety about making this mistake can rob momentum
    • The person who shared the story has found a way
      • To harness his OCD to be able to spend some small effort
      • To avoid some larger worry that might actually hamper his work
  • BREAK
  • The unpredictable is pretty much the everyday with software
    • According to the dictionary, superstition is informed
      • By belief in supernatural causes
    • There isn't anything supernatural in software in the conventional sense
    • If you cannot easily apprehend the cause of something you are seeing though
      • It is easy enough to assign it to something like the supernatural
    • Many non-programmers have a view of coding like math
    • All variables in the course of putting together a program have to be accounted for
    • If it is a giant equation or proof, then everything has to be accounted for and explained
    • For trivially small programs, that may actually be possible
    • When a program grows to a size where it does something truly useful
      • It is next to impossible for one person to be able to fully quantify
        • Everything that it does at every moment when it is running
    • Worse, software is a complex phenomenon
    • A bigger program isn't just more of the same
      • With the problem of understanding being
        • That you just have to remember more states and instructions
    • More source code really is different source code
    • There is more opportunity for non-local effects
      • Like variables in broader scopes affecting ones in narrower scopes
      • Or state inside some shared object being unexpectedly changed
    • When you through any kind of parallelism into the mix
      • It gets that much worse
    • It isn't even necessary that you are explicitly working with parallel code
      • Such as spawning your own threads or processes or using co-routines
    • By their very nature, many programs are inherently parallel
    • This is true for server applications of all kinds, such as web applications
      • With which most of us are pretty familiar
    • Multiple users don't ask servers to do work in an orderly fashion
      • And wouldn't tolerate the work they are trying to do being queued up
        • So the server can do just one thing at a time
    • Imagine how much worse Twitter would fail
      • If every time you posted a tweet
        • You received a note like a customer service call queue
        • "Your tweet is important to us and will be posted in the order received."
        • "There are 1,317,242 tweets ahead of yours in the queue."
    • That means that there legitimate sources of ignorance
      • Code pathways outside of our ability to easily understand them
    • It makes sense that some hackers would think of these blind spots
      • As something akin to the supernatural, where the natural
        • Is what we can understand and for which we can easily account
  • This can lead to a couple of funnier and more frustrating superstitions
    • Failing to reproduce a problem when the developer is present
      • Can lead to a semi-serious belief
      • That the developer scares away the problem
      • Or emits some sort of bug suppression field
    • Oddly enough, the other explanation for this particular super-normal situation
      • Relates to science, not superstition
    • I've heard the term Heisenbug, even used it myself
    • The idea is that the developer's observation of the bug changes its behavior
      • Like the effect of observation in quantum mechanics
      • Or the inability to measure both speed and position at the same time
    • In my experience, there is something to the idea of viewing perturbing a system
    • It isn't the code that is changed, however
    • Unconsciously, even the most savvy user may change what they do
      • To reproduce a particular bug when a trouble shooter is present
    • Just hit refresh is a not uncommon mantra
    • Sergio on Identi.ca pointed out how repetition of a bug
      • Often clears it up without anything explicitly changing
    • I've seen some systems where such bugs are never solved
      • And users just develop the habit, or superstition, of repeating some task
    • This is likely a consequence of some contention between parallel requests
    • The times a particular bug pops is when two or more users
      • Are hitting the same stretch of code or two conflicting parts
    • Even if both users are giving in to the mistaken belief
      • That repeating will make the bug go away
    • Running that same function over increases the odds
      • That the time between the two executions hitting that trouble spot
        • Is wide enough for one or both users to slip through without error
    • These race conditions can be ridiculously difficult to solve
      • Under even the best conditions
      • When you can reproduce it with a minimum number of users
      • And control very carefully the timing of all them
    • In my experience, these sorts of bugs are slow to solve
    • If you pay very close attention, increasing or improving logging
      • You might get a bit more of the puzzle as time goes on
    • I've met very few people who can reason out race conditions in their head
      • Or on a white board
    • But most people are capable of finding counter examples
      • That deflate a proposed explanation of the necessary sequence of events
    • This is a case, where a fix is genuinely needed, where more information
      • Can eventually help refine belief enough to lead to a fix
    • Most of the time when I've gone through this
      • I'd say we got very close to the actual sequence of execution
      • But never all the way towards pinning it all down
    • Solutions can often be coarse enough
      • That some residual ignorance or misbelief can still linger
  • BREAK
  • Ironically enough, debunking a superstition can sometimes make things worse
    • If the belief really is irrational
      • But the resulting action is harmless or oddly beneficial
      • Then there is little harm in letting superstitions persist
    • Think about pseudo science for a minute
      • Where some correct knowledge mixed with some incorrect knowledge
        • Leads to some utter wackiness
    • Our minds are really good at recognizing patterns, correlation
      • They are not so good at rigorously testing for correct causation
    • If the correct portion of technical knowledge
      • Relates to some easy to break part of a system
      • You could see a developer or user making changes
      • Thinking they had a good grasp on the system
      • But in reality breaking things far worse because of that mixture of knowledge and ignorance
    • If the same person lacked that bit of knowledge
      • And had some practice or technique that appeared to work
      • They might be less tempted to try to reason through doing something more or different
    • I am not saying ignorance is an unalloyed good
      • That would be very elitist and not what I am getting at
    • Rather, I think it would be fairer to say incompletely debunking a superstition
      • Can be more dangerous than leaving well enough alone
    • I would say this is most true when the time and effort to educate
      • Maybe is more than can be afford at a given time
    • This was certainly more common in my experience when I worked in support
    • Out of good intentions, I'd try to explain some program or peripheral
      • To a clearly superstitious user who drove the software or device just so
    • There was always pressure to close tickets, to solve a problem and move on
    • You could never spend a whole afternoon improving someone's literacy
    • Leaving them with an incomplete understanding
      • And maybe inflating their sense of what they knew
      • Often led to more support calls from that user
      • Than just letting them do and think as they had in the first place
  • There is often a strong overlap with ritual
    • I distinguish rituals from superstition
      • By the level of awareness as well as the intent
    • When I spoke about rituals, I was describing practice
      • That helped support work in an explicit and positively reinforcing way
    • Practicing a ritual is usually rational, designed to improve an aspect
      • Of our practice of hacking
    • When a ritual does not have a rational basis
      • It rarely introduces any kind of risk to the work we do
    • An irrational ritual may still have a sound basis
      • Say an emotional one
      • But the intent is always conscious and towards the good
    • Exercises that simply boost mood can have a positive knock on effect
      • Making us more attentive, patient and generally ready to tackle challenges
    • Doing them incorrectly may fail to list our spirits but won't break a build
    • Superstitions are often more immediate, more intertwined with the tasks at hand
    • The way we interact with source control or the particular build steps we invoke
      • Or as commonly informed by superstition as having thought things through
        • From first principles, considering all the possible side effects
    • They may be harmless
      • In some cases observing them or not really makes no difference
        • On the outcome of a particular bit of work
    • But there are also the cases where they can directly impact
      • Some aspect of building software as much for the bad as for the good
    • It is worth thinking about our personal superstitions
    • It isn't necessary to eliminate them or even shift them onto a more reasoned footing
    • Understanding the potential risks is enough to ensure
      • That we trim out those that may be harmful
      • And only observe the ones that at worst have no effect
        • But in the observation may help lighten the cognitive load
        • Incurred by managing the inherent complexity in hacking together software

(26:51) Outro

Retrieved from "http://www.thecommandline.net/wiki/2010_08_25"
Personal tools