A couple weeks ago I accidentally replaced our live, production database with a 17-hour old snapshot.
I had intended to target a test server, not production. I didn’t realize what I had done for an hour or so, and by that time I had already left work. (I was actually out walking my dog. Not a good setting for managing a production crisis.)
Here’s how my team and I handled it.
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. They sold us the Editor/Assember package.
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). That’s their job.
(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.
(Somebody on Quora asked about “traits that the best programmers seem to have”. Here’s what I said.)
Breadth of understanding. They are not dogmatic. They have used (at least in passing) more than one language, framework, operating system – and understand the strong points of each.
Communication skills. They can explain their decisions. They can write code reviews. They can discuss their code.
Understanding that engineering is about tradeoffs. There is never an absolute “best” answer; there are always many choices each with their own sets of pros and cons.
Once in a while I look at a sampling of recent dpaste activity. Partly I do it so I’m not totally out of touch with what my site contains. Partly I do it because it’s just interesting.
And I do it to confirm that the site is actually used by people who want to share code snippets, not just spambots who fire their cannons into every porthole.
I just sampled 10 random items from the last week. Happily, no spam. Here’s what I saw: