A higher-level view of this is that the programmer must be aware of when a transaction is happening, and avoid installing any "holes" that allow the transaction to end up partially committed. The analytical/reductionist mindset of "break it down into steps" must be balanced by the synthetic/holistic flipside that says "this whole thing is just one step". Transactions are not just something that database programmers have to worry about. I think training
in transactional thinking tends to fall through the paradigmatic cracks because transactions can't be classified as functions or events or objects. If anything, a transaction is most closely related to the logic programming paradigm, which is undertaught. A transaction can be viewed as a sort of hypothesis that can either be proven or disproven. A partially proven hypothesis is of little use.
in reply to Basic Coding Tips: Parsimonious Parameterization