This is the first part of the fourth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the chapter "Coding".

This chapter describes my personal set of rules and principles for coding. These rules and principles are not about my code itself: they are about my behavior, mood, and attitude while writing code. They describe my own mental, moral, and emotional context for writing code. These are the roots of my confidence and error-sense.

You will likely not agree with everything I say here. After all, this is deeply personal stuff. That's OK, they are not intended to be absolute truths for anyone other than me.

Preparedness

Coding is an intellectually challenging and exhausting activity. It requires a level of concentration and focus that few other disciplines require. The reason for this is that coding requires you to juggle many competing factors at once.

1. First, your code must work. You must understand the problem and how to solve it. You must manage every detail of that solution while remaining consistent within the language, platform, architecture, and all the warts of the current system.

2. Your code must solve the problem set for you by the customer. Ofter the customer's requirements do not solve the customer's problems. It is up to you to see this and negotiate with the customer to ensure that the true needs are met.

3. Your code must fit well into the existing system. It must follow solid engineering principles. It should not increase the rigidity, fragility, or opacity.

4. Your code must be readable by other programmers. This may be the most difficult thing a programmer can master.

Juggling all these concerns is hard.

When you cannot concentrate and focus sufficiently, the code will be wrong. It will have bugs. It will have the wrong structure. It will be opaque and convoluted. It will not solve the customers' real problems. In short, it will have to be reworked or redone. Working while distract creates waste.

If you're tired or distracted, do not code. You'll only wind up redoing what you did. Instead, find a way to eliminate the distractions and settle your mind.

Dedication and professionals are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day.

Worry code

Have you ever gotten into a big fight with your spouse or fired, and then tried to code? Did you notice that there was a background process running in your mind trying to resolve or at least review the fight? Sometimes you can feel the stress of that background process in your chest, or in the pit of your stomach. It can make you feel anxious, like when you've had too much coffee or diet coke. It's distracting.

I have learned that this is no time to code. Any code I produce will be trash. So instead of coding, I need to resolve the worry.

Of course, there are many worries that simply cannot be resolved in an hour or two. Moreover, our employers are not likely to long tolerate our inability to work as we resolve our personal issues. The trick is to learn how to shut down the background process, or at least reduce its priority so that it's not a continuous distraction.

Ideally, the time spent with personal issues would be personal time. It would be a shame to spend an hour at the office this way. Professional developer allocates their personal time in order to ensure that the time spent at the office is as productive as possible. That means you should specifically set aside time at home to settle your anxieties so that you don't bring them to the office.

The Flow Zone

The Flow Zone, or just "the Zone", is the highly focused, tunnel-vision state of consciousness that programmers can get into while they write code. They feel very productive and infallible. And so they desire to attain that state and often measure their self-worth by how much time they can spend there.

Here's a little hint from someone whose been there and back: Avoid the Zone. This state of consciousness is not really hiper-productive and is certainly not infallible. It's really just a mild meditative state in which certain rational faculties are diminished in favor of a sense of speed.

You will write more code in the Zone. If you are practicing TDD, you will go around red/green/refactor loop more quickly. And you will feel a mild euphoria or a sense of conquest. The problem is that you lose some of the big picture while you are in the Zone. You will likely make decisions that you will later have to go back and reverse. Code written in this state may come out faster, but you'll be going back to visit it more.

One of the big benefits of pair programming is that it is virtually impossible for a pair to enter the Zone, because it is an uncommunicative state, while pairing requires intense and constant communication.

Interruptions

Pairing can be very helpful as a way to deal with interruptions. Your pair partner can hold the context of the problem at hand, while you deal with a phone call or a question from a coworker. When you return to your pair partner, he quickly helps you reconstruct the mental context you had before the interruption.

TDD is another big help. If you have a failing test, that test holds the context of where you are. You can return to it after an interruption and continue to make that failing test pass.

In the end, of course, there will be interruptions that distract you and cause you to lose time. When they happen, remember that next time you may be the one who needs to interrupt someone else. So the professional attitude is a polite willingness to be helpful.

Writer's block

Sometimes the code just doesn't come. You sit at your workstation and nothing happens.

Often you will find other work to do. You'll read emails. You'll read tweets. You'll look through books, or schedules, or documents. You'll do anything so that you don't have to face workstation and watch as the code refuses to appear.

A lot of factors can cause such blockages: sleep, worry, fear, depression, you name it.

Oddly enough there is a very simple solution. It works almost every time and it's easy to do.

The solution: Find a pair partner.

Creative input

There are other things I do to prevent blockage. I learned a long time ago that creative output depends on creative input.

I read a lot, and I read all kinds of books. However, I find that the thing that best primes the pump of creative output is science fiction. For you, it might be something else.

Next article: #4 Coding (Part 2)

Previous article: #3 Saying Yes