Automated tests for software

I have known for many years that I enjoy devising software solutions to difficult problems, then implementing and demonstrating them. A more recent discovery for me is that I enjoy writing automated tests for the software I write. I wonder if this is partly because I like writing code when I have a good understanding of what is going on and, having implemented code and got it appearing to work, mostly I already know how to write tests for it and can then just get on with that productively.

Agile purists may ask, weren't the tests already written? Not all of us get to work in such a shielded environment. When a deadline is pressing and another developer is made more productive by my piece already working, even buggily, then I'll get off the critical path as soon as I can. When I am proposing projects to wealthy, patient customers then I build the test-writing into every task on the chart, but I have not been in that enviable position for years now.

Restaurant failures

A curious issue here with restaurants is that it is not uncommon for many items from the menu, perhaps most, to be unavailable. One discovers this only when ordering. Some chains do fine, others are reliably poor in this regard and I am learning simply to avoid them. An additional frustration is that, not only do they not mark what is no longer available, but interaction with the staff often fails to reveal the whole story: instead we have interactions like, sorry, only X and Y are available, what about Z?, sure, we have that.