I've seen this mentioned quite a bit around these parts and I just don't get it. What kind of problem takes 20 minutes to wrap your head around? Can you give me a working example?
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.
You probably won't get someone posting an example, because they're often in closed enterprise type source code.
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.
Architectural problems, for starters. These can take me somewhere between an hour and a day to crack. The time is spent constructing a coherent mental model and then "simulating" it in my head, looking for how it behaves in various conditions, and then patching the discovered holes.
(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.
It's not so much the problem itself that takes 20 minutes (though if you have loose specs, you have to think of the best way to solve it, which I prefer), it's how to solve the problem within the constraints of the existing codebase / framework / design philosophy.
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.
Oh man, lucky you. I've worked on things that take days to start figuring out what's going on... debugging subtle race conditions in massively distributed systems comes to mind.
Try inheritance trees in a dynamically typed language, when there is 8 layers of abstraction between the thing that you know and the thing that might be causing the problem.
It's not getting the problem in your head, so much as where you are at a certain point in time while attempting to solve the problem. If you get knocked out of flow by interruptions after 20 minutes, it can take quite an amount of time to get back to where you were.
If you are a programmer, here's a good one: You are 'thrown' into a legacy codebase and asked to fix/refactor/add a new feature. Oh, and also you don't have docs and the people who wrote the code are no longer available to you. Added bonus, that codebase runs on 4 completely different platforms platforms. Finally this is a game shipping in 2 months.
I understand, but why can't you stop fixing/refactoring/adding a feature for 5 minutes ?
Taking a break won't make you forget you everything, it mights make you more productive for the next 20 minutes.
For the record, I've worked on 20 years old code where maintanability didn't seemed like a important part.
Breaks doesn't always make you slower, it might do the contrary. Of course, there is no magical solution and you have to find a balance.
From the parent post, and I quote:
"What kind of problem takes 20 minutes to wrap your head around? Can you give me a working example?"
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?
Parent poster here — just FYI, I certainly did not say that "20 minutes is more than enough to wrap your head around anything". Was only looking for examples to assuage my curiosity.
I stand corrected. However it is a weird question to me and this mislead me into wondering how could someone not ever encounter any problem or task which takes more than 20 minutes to grok. Out of curiosity, what is it you do professionally? Do you get bored of it?
What I meant was, there's often talk on HN about how distractions during programming will tear down your "mind palace" and force you to build up your mental model from scratch. There are certainly problems I've dealt with that take more than 20 minutes (or even days) to grok, but almost none where I couldn't talk to someone and then jump right back in unless I'm actively learning/researching/debugging (which is maybe 10% of the time). With most of my work, I only have to deal with local functions and behaviors without having to run the whole stack in my head. Everything else is on paper or in my notes. But it seems that many others don't operate this way, and I'm very curious about this division.
Everybody is different. Personally, I can't keep multiple things in my head at the same time very well. I need to focus 100% (or as near to 100% as possible) on the task at hand. If I'm focused on solving a problem and somebody comes up to my desk to ask a question=, it's very similar to that xkcd comic where the mental bubble goes 'poof' and I'm back to square one.
Figuring out how a bug happens can easily take 20 minutes of concentration. "This thread calls this method, that one sends this message, then a request arrives here while this lock is held...".
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.
Potentially when your inexperienced in the problem domain, or you're building brand new large and complex systems and you haven't yet broken it into smaller subsystems/tasks that can be tackled one at a time.
I find the 20 minute on/5 minutes off Pomodoro cycle is great for getting me started into a problem. After 1 or 2 of these cycles I find I'm skipping the breaks and sustaining focused work for longer.
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.