1. This clearly took A LOT of work, and I have not finished reading it. I intend to, but as another comment calculated below, that will take around 127 minutes. This comment is simply about the beginning.
2. I'm not 100% certain yet what the intended goal of this article is, so I may just be off base. That being said, my criticisms should be interpreted more as questions, since I'm deeply fascinated with how to make programming more accessible. I hope they are taken as such, and people share their experiences/successes/failures in getting people to understand "what we do". Again, like other commenters here I have suffered the fate of parents not really understanding what you do (unlike the even superficial understanding of what a physicist does).
3. People learn differently, this is me pretending to not know anything and reading this article. It is thus flawed on two axises: I can't know for sure how I would have taken it in, and even if I did, it may be great for most people but bad for me.
All that being said, I had a few issues with this article('s beginning) if the goal is to make programming seem understandable to non-programmers. It seems to jump around a lot at the beginning and focus on just how complex everything is. If the goal is "programmers are justified in their work, look how complex everything they deal with is!", then this may be an OK approach. However, if the goal is to help them understand what we do day to day, it may not.
Some examples:
1. The early references to math. I once upon a time thought math was a pre-requisite to programming. I have now met enough awesome programmers that are absolute rubbish at math that I no longer believe that to be true. I believe referring to the "math" of things a lot scares people off (makes it seem like "one of those math things math people do" and inaccessible, when in reality your everyday programmer does not do a lot of (complex) math).
2. The early reference to circuits, compilation, and keyboard codes. This is a tremendous amount of scope that is unnecessary in my opinion, and just makes everything seem so obtuse. Showing keyboard codes goes a long way in conveying how much a computer does, but I feel is very confusing in relation to programming. I don't deal with "keyboard codes". We could also get into for example the actual hardware and how even having to deal with denouncing a key is hard! But I think everyone would see why that isn't great for the (introduction) of a programming explanation.
3. The circuits I believe are pretty and let you do things interactively, but I have a hard time believing they convey any information to people not familiar with programming. No one knows what XOR means (which you can flip the gates to), and just furthers the idea that code is this weird incantation we do. More putting them in "awe" of programming than understanding it.
Then again, I've been criticized for relying to heavily on analogy. My explanation would probably start with a lot of hand waiving: "lets tell the computer to get a sandwhich shall we?", then trying to get deeper bit by bit, etc. Others have probably tried this and failed, so I am genuinely curious if people walk away from this article feeling like they have a better understanding of things.