This is definitely a young coder because those features made some sense in the era they were created. In some cases they were life savers. On error resume next

This is definitely a young coder because those features made some sense in the era they were created. In some cases they were life savers. On error resume next: This can be scoped. So I’m reality it’s was used in small sub routines where errors needed to be discarded. I’m not suggesting it’s a particularly great idiom but this comes from an era before try / catch blocks. DoEvents: This was vital back when your language runtime was event driven but also single threaded. It was a way of allowing the application not to lock up (and thus the user force closing it) when there was computationally heavy workload. These days you’d stick that workload in a new thread for async await but you’d have all the same problems of ensuring that you’d disabled UI elements first as the article describes with DoEvents. And actually DoEvents is rather more clever because you’re telling a single threaded application that was typically running on a single core/CPU system exactly where the safe points are to prioritise other processes. These days we have green threads, async/await and other concepts for lazy multitasking. But back when DoEvents was created there was no such thing and using real OS threads was very difficult (in fact it was officially unsupported in the languages that had DoEvents, though there were some unofficial jacks) so it was a real life saver in some scenarios.