(Hint: it’s about your team.) A couple weeks ago I accidentally replaced our live, production database with a 17-hour old snapshot. This is an always-on application with users around the globe, so the mistake was likely to have blown away some new user-entered data. I didn’t realize what I had done for an hour or so (I thought I had targeted a test database server, not production). When it hit me, I had already left work.
You could say Z-80 assembly language is what really turned me into a software developer. My first programming language was BASIC, which was built into my first computer (a TRS-80 Model III). I wrote a lot of BASIC code, including arcade-style games (compiled BASIC — you can still play them on this TRS-80 Model III Emulator). I always wanted to keep learning. There was no World Wide Web for research and nobody I knew could guide me, so we went to Radio Shack and asked them how else I could program the computer.
Non-engineers want to know: what happens when a big bug is found in your software, and the bug is causing real users real problems, and you’re the one who wrote the code? Engineers do sometimes write bad code, and sometimes it makes it into production, it’s true. But shipping production software involves a lot more than writing code. It goes beyond that one engineer. That engineer is not the only person who saw or ran that code.
How do you comprehensibly explain to non-programmers the challenges of programming? Why can’t you “just tell the computer what you want it to do”? A classic teaching tool for this is the “make me a peanut butter and jelly sandwich” demo. Put out on the table a jar of peanut butter, a jar of jelly, a loaf of bread, and a knife. Tell them you are a robot (computer) that is physically capable of making a peanut butter and jelly sandwich, but you need instruction (programming).
(This is another thing I found myself writing on Quora and wanted to keep. The question was “Does Python have any scalability limitations?") “Scalability” is a term people like to throw around, but the less specific you are as to what you mean by it, the less substantial the answers will be. It is not a simple linear measure on which languages can be given some numerical score. Languages and their implementations do have certain inherent performance characteristics, but in order to understand their relevance to your needs you have to get specific about your needs.