To be a professional programmer, there’re many things that we’ve to do to be a good one.
In this article, we’ll look at when we should code.
Worry Code
If we feel bad, then we shouldn’t be coding.
Stress distracts us from doing the hard task of coding.
We can’t maintain focus or concentration.
Also, we get tired and we get stuck with problems that we may able to solve faster if we feel good.
We just got to know how to shut down these bad feelings and get on with coding.
Coding is also a good distraction from all the bad things that are happening in life.
We should also find a quiet place to write code if it distracts us.
Flow
Flow is when we’re in a productive state,
Some programmers also call it ‘the zone’.
It’s when we’re in a focused, tunnel-vision state of consciousness that programmers can get into while they write code.
It’s when we’re feeling productivity.
When we’re in the zone, we’ll write more code.
We’ll add more features and refactoring them more quickly.
However, we may lose some of the pictures when we’re in the zone, so we may make decisions that we’ll have to go back later and reverse.
Therefore, we may want to walk away and take a break as we go into the zone.
Pair programming also prevents us from going into the zone.
The zone is an uncommunicative state.
Pairing requires intense and constant communication.
Music
Music may be distracting to us when we go into code.
Therefore, we may want to turn it off when we code.
Not everybody can code well with music on.
So if it distracts us, then we can turn them off.
Interruptions
Another bad thing that happens when we go into the zone is that we get mad when interruptions happen that take us out of the zone.
We may snap at people that take us out of the zone.
However, sometimes we’re stuck on some hard problem that needs concentration.
This may also lead to us being mad at people that interrupt us.
Pairing can help with solving hard problems.
Our pair partner can hold the context of the problem while we deal with the interruption.
When we return to pair programming, then we can reconstruct the context before the interruption.
Test-driven development also helps us with holding context.
The context are in the test. If we have a failing test, then we have a problem.
Writer’s Block
Sometimes we get stuck when we write code.
Often we find other work to do when we’re stuck, we surf the web or check the email for example.
The lack of sleep may slow our brain down so that we get stuck.
Other things like worry, fear, and depressions are also factors.
This is where a pair partner can help again.
They can help get us unstuck in whatever we’re doing.
Creative Input
Reading things also give us some ideas on how to solve our problems.
Creative input gives us the inspiration to make output.
Books, websites, TV, movies, music, etc. all may help.
Debugging
Debugging is definitely part of coding.
It probably takes more time than writing the code.
Debugging is just as expensive as coding time.
With test-driven development, we can spend less time debugging since we can catch them with the tests.
Ideally, we should spend no time debugging, and we should try to reduce it as much as we can.
Pacing Ourselves
Software development isn’t a race.
There will also be things to do and there’s no finish line.
When we’re tired, we can’t solve the problems that we can probably solve quickly if we’re energetic.
When we’re stuck or tired, we should stop for a while.
We should pace ourselves so that we won’t be working when we’re tired.
When we’re driving, we should also disengage from problems at work so we can concentrate.
Taking a shower is a great time to think about problems. Lots of solutions may come to our brains when we’re taking a shower.
Conclusion
We shouldn’t be coding when we’re tired.
Also, pair programming is useful when we need to get back to work faster after interruptions.
Pair partners also help when we’re stuck.
We should also minimize the time we need for debugging.
