Ask HN: How do you explain programming to non-programmers?
In looking around for different approaches I ran into a number of interesting ideas. There's the "building a factory" analogy or "instructions for climbing mount Everest" analogy.
My focus was to try to explain the nature of the work a programmer, how it differs from linear or scheduled work and issues such as why it can be hard to estimate software project development time.
Most anyone working what I call "linear" jobs has a hard time understanding what programming is about. They get to the office and have n tasks to complete. Sure, the day may throw a wrench here and there, but, for the most part, the process is reasonably predictable.
Another case is that of a family practice doctor's office: They have patients scheduled and they can see n patients in eight hours. There's the occasional emergency, but, again, for the most part, the process is mostly linear and very predictable.
Creating non-trivial software products is nothing like that. There are lots of "unknown unknowns", particularly if you are trenching new territory. And then there are those problems that come-up unannounced that can consume hours, days or weeks.
Then there's the process of discovery. While working on an iOS app it became evident that interesting new UI approaches would work better. New functionality could be added, etc. Therefore, the scope of the project grew and variability was added as new feature sets or approaches were explored.
It's the nature of a creative art where you set out to go somewhere yet don't always have absolute knowledge of how to get there or where "there" might actually be.
I'm sure there are lots of interest takes on this from HN members.