1) Do you really manage (and how) to predict possible future problems?

Look at the level of maturity of a technology in question, and consider how widespread is its use. You can predict with reasonable certainty that the number of non-intuitive places in a technology stack drops as the technology gets more mature.

2) How much time do you spend for finding the workaround/fix/solution before you leave it and switch to other problems.

It depends on the need for a fix: I’ve spent nearly two weeks researching a rare but persistent bug on an obscure platform that we needed to support, because the platform was required by the contract. This was when Experts Exchange was in its infancy, and Stack Overflow did not exist.

3) What are the criteria for you to think about yourself as experienced in the tecnology. Do you take these gotchas into account?

Absolutely, I do! In fact, it’s pretty much the only thing that makes up the “experience” (as opposed to “knowledge” that can be learned from books and tutorials).

The biggest criteria is how long you can go without hitting one of these “gotchas”: what’s gotcha for one developer, may be a known limitation to another developer, and a feature to yet another one. The more you use a technology, the more “gotchas” sort themselves out into your “feature” and “limitation” boxes, letting you work without discovering a new one for days and months.

The reason it’s called a learning curve (as opposed to a learning slope) is that it starts out steeper and levels out but never truly becomes flat. There’s always something you don’t know. And there’s always something that you don’t know you don’t know.

You learn from experience, and it’s an unfortunate truism that you learn more from your mistakes than your successes.

To answer your specific questions:

Do you really manage (and how) to predict possible future problems?

To some extent. A lot of it comes from my own experiences and those of people I’ve worked with. But it’s not entirely “I can’t predict something unless I’ve seen the problem before.” You start to get a spidey-sense for the areas where gotchas reside. I understand why you currently feel that there’s no pattern to them, but over time you’ll find that there is, in a lot of cases.

There are certain things that scream out “Here be dragons” without you really knowing what colour the dragons might be. But, in those cases, you can usually get that information from Google.

How much time do you spend for finding the workaround/fix/solution before you leave it and switch to other problems.

Depends again on that instinctive sense. I’ve run into a problem just this week that I never saw coming and never would have spent time looking for. I made a very obvious assumption that I think most people would make, and I’d make it again.

But there are certain areas (for example, anything to do with communications) that I don’t go near without Googling for gotchas.

What are the criteria for you to think about yourself as experienced in the tecnology. Do you take these gotchas into account?

I think experience is relative. There is no “I am experienced in this technology,” no matter how much we try to claim there is on a resume. I think it’s all about whether you’re more experienced in the areas of risk that you’re facing than other people you’re working with.

ie. How often do you spot those gotchas, before they become problems, compared to your colleagues?