Return to Answer

Edit: Disclaimer - This is how I define "the zone": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

I try to avoid this state because, while I may produce correct code in the zone, I and other developers will have a hard time understanding it later on. To put it short: reading code that was written in the zone may often require the reader being in the zone. That constraint is my problem.

There's a lovely chapter on The Clean Coder where Uncle Bob persuasively explains why "getting into the zone" is a delusively bad idea.

Here's a possibly better alternative than "getting in the zone": think straight and consider calmly and professionally what you're doing. Communicate. Share thoughts with your partner(s). Identify the real problems. Discuss possible solutions. You might not feel supernaturely focused, but you're likely to make good decisions, and approachable designs.

If you and your teammates can discuss the problem without both of you being extremely focused, then chances are you've boiled the problem down to its simpler nature. That suggests you'll be able to understand it again whenever you need to.

On the flip side... If you just need some time alone to get your head straight (we all do sometimes), just take it. Get your thoughts together. Work the problem out in your head first.

But the thing is that if you do - don't use that time to write production code. Instead, play around with sample code and prototypes. Try to understand the problem, without thinking about solutions just yet. Once you get everything straight and written down, discuss it with your team and pair partner, or even the rubber duck on your desk. If you still can't articulate it, or they can't understand it, then refine your ideas. Once you've nailed all of that down - integrate all that thought and sample code into a real, working solution.

Edit: Disclaimer - This is how I define "the zone": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

I try to avoid this state because, while I may produce correct code in the zone, I and other developers will have a hard time understanding it later on. To put it short: reading code that was written in the zone may often require the reader being in the zone. That constraint is my problem.

There's a lovely chapter on The Clean Coder where Uncle Bob persuasively explains why "getting into the zone" is a delusively bad idea.

Here's a possibly better alternative than "getting in the zone": think straight and consider calmly and professionally what you're doing. Communicate. Share thoughts with your partner(s). Identify the real problems. Discuss possible solutions. You might not feel supernaturely focused, but you're likely to make good decisions, and approachable designs.

If you and your pair-partner can discuss the problem without both of you being extremely focused, then chances are you've boiled the problem down to its simpler nature. That suggests you'll be able to understand it again whenever you need to.

On the flip side... If you just need some time alone to get your head straight (we all do sometimes), just take it. Get your thoughts together. Work the problem out in your head first.

But the thing is that if you do - don't use that time to write production code. Instead, play around with sample code and prototypes. Try to understand the problem, without thinking about solutions just yet. Once you get everything straight and written down, discuss it with your team and pair partner, or even the rubber duck on your desk. If you still can't articulate it, or they can't understand it, then refine your ideas. Once you've nailed all of that down - integrate all that thought and sample code into a real, working solution.

It seems to me that people treat "the zone" as if it were some magic quick fix for solving problems well, like a thinking hat.

There's a lovely chapter on The Clean Coder where Uncle Bob persuasively explains why "getting into the zone" is a delusively bad idea.

In a nutshell: when you get into "the zone" (what a pathetic term, might I add), you start "seeing things differently" like Neo from the Matrix.

The problem is that later on, other people, or yourself (when not in "the zone") will find it hard to understand just how you managed to "connect all the dots" together. In other words, you're more likely to make bad design decisions, shielded by the feeling that you're in some crazy super-natural state of mind.

And getting into the zone is not even the easy choice, since it's not easy to get so concentrated.

So here's a better all around option: think straight and consider calmly and professionally what you're doing. Communicate. Share thoughts with your partner(s). Identify the real problems. Discuss possible solutions.

If you and your teammates can discuss the problem when you're not in that silly zone, then that means that you really managed to uncover its true (simple) nature, and how it might be solved, and that you'll be able to understand it again whenever you need to.

And remember, we're grown-ups now. We prefer stability over random sparks of alleged brilliance.

Don't get caught up with attractive buzz words that mask harmful practices (just like Singletons...).

On the flip side... If you just need some time alone to get your head straight (we all do sometimes), can't you just take it?

But the thing is that if you do - don't use it to write production code. Instead, write tracer bullets and prototypes. Try to understand the problem first, without thinking about solving it just yet. Once you get everything straight and written down, discuss it with your team and pair partner. If they can't understand it, refine your ideas. Once they do, discuss it together! And only then implement.

Yeah, it's going to take more time in the short run. But you know what they say... quality over quantity.

Edit: Disclaimer - This is how I define "the zone": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

I try to avoid this state because, while I may produce correct code in the zone, I and other developers will have a hard time understanding it later on. To put it short: reading code that was written in the zone may often require the reader being in the zone. That constraint is my problem.

There's a lovely chapter on The Clean Coder where Uncle Bob persuasively explains why "getting into the zone" is a delusively bad idea.

Here's a possibly better alternative than "getting in the zone": think straight and consider calmly and professionally what you're doing. Communicate. Share thoughts with your partner(s). Identify the real problems. Discuss possible solutions. You might not feel supernaturely focused, but you're likely to make good decisions, and approachable designs.

If you and your teammates can discuss the problem without both of you being extremely focused, then chances are you've boiled the problem down to its simpler nature. That suggests you'll be able to understand it again whenever you need to.

On the flip side... If you just need some time alone to get your head straight (we all do sometimes), just take it. Get your thoughts together. Work the problem out in your head first.

But the thing is that if you do - don't use that time to write production code. Instead, play around with sample code and prototypes. Try to understand the problem, without thinking about solutions just yet. Once you get everything straight and written down, discuss it with your team and pair partner, or even the rubber duck on your desk. If you still can't articulate it, or they can't understand it, then refine your ideas. Once you've nailed all of that down - integrate all that thought and sample code into a real, working solution.

It seems to me that people treat "the zone" as if it were some magic quick fix for solving problems well, like a thinking hat.

There's a lovely chapter on The Clean Coder where Uncle Bob persuasively explains why "getting into the zone" is a delusively bad idea.

In a nutshell: when you get into "the zone" (what a pathetic term, might I add), you start "seeing things differently" like Neo from the Matrix.

The problem is that later on, other people, or yourself (when not in "the zone") will find it hard to understand just how you managed to "connect all the dots" together. In other words, you're more likely to make bad design decisions, shielded by the feeling that you're in some crazy super-natural state of mind.

And getting into the zone is not even the easy choice, since it's not easy to get so concentrated.

So here's a better all around option: think straight and consider calmly and professionally what you're doing. Communicate. Share thoughts with your partner(s). Identify the real problems. Discuss possible solutions.

If you and your teammates can discuss the problem when you're not in that silly zone, then that means that you really managed to uncover its true (simple) nature, and how it might be solved, and that you'll be able to understand it again whenever you need to.

And remember, we're grown-ups now. We prefer stability over random sparks of alleged brilliance.

Don't get caught up with attractive buzz words that mask harmful practices (just like Singletons...).

It seems to me that people treat "the zone" as if it were some magic quick fix for solving problems well, like a thinking hat.

There's a lovely chapter on The Clean Coder where Uncle Bob persuasively explains why "getting into the zone" is a delusively bad idea.

In a nutshell: when you get into "the zone" (what a pathetic term, might I add), you start "seeing things differently" like Neo from the Matrix.

The problem is that later on, other people, or yourself (when not in "the zone") will find it hard to understand just how you managed to "connect all the dots" together. In other words, you're more likely to make bad design decisions, shielded by the feeling that you're in some crazy super-natural state of mind.

And getting into the zone is not even the easy choice, since it's not easy to get so concentrated.

So here's a better all around option: think straight and consider calmly and professionally what you're doing. Communicate. Share thoughts with your partner(s). Identify the real problems. Discuss possible solutions.

If you and your teammates can discuss the problem when you're not in that silly zone, then that means that you really managed to uncover its true (simple) nature, and how it might be solved, and that you'll be able to understand it again whenever you need to.

And remember, we're grown-ups now. We prefer stability over random sparks of alleged brilliance.

Don't get caught up with attractive buzz words that mask harmful practices (just like Singletons...).

On the flip side... If you just need some time alone to get your head straight (we all do sometimes), can't you just take it?

But the thing is that if you do - don't use it to write production code. Instead, write tracer bullets and prototypes. Try to understand the problem first, without thinking about solving it just yet. Once you get everything straight and written down, discuss it with your team and pair partner. If they can't understand it, refine your ideas. Once they do, discuss it together! And only then implement.

Yeah, it's going to take more time in the short run. But you know what they say... quality over quantity.