Nope. Didn't see the confidential until you mentioned it, but I am assuming that the Confidential relates to the original date. If the document is confidential beyond that date then I doubt the teacher should be using it as a mock paper either ... seems to me that an examination paper can't remain confidential after the exam as it is in the public domain thereafter.
I'm OK with helping / guiding students, provided that they submit their workings so far. I'm not OK with doing their homework for them as, of course, they wouldn't learn anything..
Yup, I agree.
Seem OK to me, but checking exam papers is not a skill I have; I'm dyslexic so the chance of me spotting a mis-match between question and answer is quite small.
That's a good pair of questions.
When you've been doing it for a while it kinda comes naturally. There may be better ways - more efficient / perform better / avoid pitfalls and, my particular soapbox:are programmed "defensively", that is to say writing the program in a way that will fail with suitable error message, or avoid possible outcomes, e.g. if data is "goofy" or goes out of expected ranges and so on. Plenty of palces just "churn out code", better places consider and address the quality of the code.
So I think it is important to strive for "Best of breed" coding techniques
I don't think Practice alone will help. You need Teaching - either from a more experienced person, or self-taught. I'm self-taught, some of it has come in peer-review with colleagues where we have debated the baest ways of doing things, I've also read some good books over the years - such as "Code Complete". Reducing bugs, the ones that come to light after the program is rolled out, is the biggest cost-saving, or counted another way highest "profit"
and that is what I have developed my methods to mitigate. We have extremely few failures in code that is in Production, we achieve that with a combination of Defensive Programming and good Testing / QA (i.e. the stage between Development and Deployment). Good error reporting is another way of reducing "cost" of failures in production; if the error can be quickly diagnosed and fixed that reduces the cost.
The cost of fixing a fault rises the further along the process that it is discovered. It is cheapest to fix in Design, and most expensive to fix if it has made it all the way into Production, which is why it is a primary focus of mine.
But we see all sorts of shocking code posted on here by people asking for help - unformatted, no consistency of style / naming, use of really poor technique ... and sadly I think that may be "average" in the industry.