I'm asking honestly, by the way! I've never personally encountered a problem in my professional career that takes half an hour just to internalize, and I've always wondered what one might look like.
I'm asking honestly, by the way! I've never personally encountered a problem in my professional career that takes half an hour just to internalize, and I've always wondered what one might look like.
One example is spaghetti type code that you have to untangle and see if you can simplify (or simply understand). Imagine that you have a Rails controller where there are several modules being pulled into it. There is a before filter that calls a private method. The private methods makes a call to another method, but it's not clear where that method is. It turns out that it's in one of the modules. The module method makes calls to other methods in other modules - of which you have to hunt down and figure out where they are. One of the methods in such modules has some dynamic code where it calls a class based on a value that comes from the DB...
There's some funky stuff that goes on in production apps sometimes - add in a bit of tricky logic to trace, and maybe you can see how it could take a bit to get your head around what's going on.
Hopefully this is the exception to the rule, but if you're a consultant who's job it is to clean up other's messes then I guess it wouldn't be so surprising to see some pretty gnarly code.
(Those problems could easily take even more time, but after a lot of such cases in my hobby projects, I learned that if I feel the problem is that complex, I should aggressively decompose it into pieces that can be thought through and implemented independently.)
Another kind of problem - complex algorithms. For instance, it once took me over a week to implement a new path routing code in our company's application, with half of the time spent on trying to comprehend some obscure papers that described an efficient solution in just enough details to get a pretty good picture of the method, but not nearly enough to actually build it.
I can give you a concrete example. At a place I worked at a while ago, they wanted to integrate shipping. Well they had already done Fedex but wanted to now do UPS. Shipping has all sorts of special services like Saturday delivery and return receipts, etc. So first you have to understand what they were doing with the Fedex implementation, then you have to understand the constraints of the UPS implementation and conform those constraints into the same functionality of the Fedex implementation without missing any of the features or how the implementation works / looks to the user. You have to apply this to the front end, the back end, and the database.
That took a lot longer than 20 minutes, because you have to keep 2 mostly full implementations in your head at the same time while you are designing the second.
I'm not against breaks, the issue here is that someone mentioned that 20 minutes is more than enough to wrap your head around anything. I gave an example where most (mortals) would require substantially more than 20 minutes. Are we talking about breaks? Or the fact that some geniuses are able to figure out everything under 20 minutes?
It's in tracking down tricky bugs that I find focus is most needed: if I'm in an easily-distracted state then I will basically spend hours getting nowhere.