When you start a task, or even before starting, set a strict time limit on how long you’re going to be busy with the task. If you don’t finish it before the timebox is up, fail it and move on. (A project that can be failed is more valuable than a project that cannot be failed, because failing possibly frees up resources, which is a gain. But that’s a story for another time.)
Let’s say, I am trying to figure out why a page doesn’t render due to an invalid character on the page, and it’s kind of tricky – a non-printing non-ascii character causes this issue. If I know what/where the character is and can delete the character without fixing the underlying issue, I can say: I’ll spend 30 minutes looking for a solution, and if I can’t, I’ll just delete the character and defer the actual solution for another day. This way, you can avoid going down a rabbit hole. This is an example from real-like engineering.
Another example: I set the timebox of 1 hour to read a character in a book. Split into easy 15 min adjacent intervals for easy accounting and for better focus. (I keep track of 15 minute intervals when working, as well as each hour. See 15 minutes.) The indirect benefit of this timebox is that I’ll actually read faster, knowing I’ll abandon the task un-finished, if I don’t do it within the timebox – and it’s inconvenient to break mid-chapter.
Or you can say, we got 15 minutes (my favorite time interval right now) to get ready to go out. During this timeframe, all the focus is on getting ready. No distractions are permitted.
As you can see, timeboxing a task is a useful method for getting things done better.