#4 Coding (Part 2) - Tips from The Clean Coder

This is the second 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".

Debugging

For some reason, software developers don't think of debugging time as coding time. But debugging time is just as expensive to the business as coding time is, and therefore anything we can do to avoid or diminish it is good.

Whether you adopt TDD, it is incumbent upon you as a professional to reduce your debugging time as close to zero as you can get. Clearly zero is an asymptotic goal, but it is the goal nonetheless.

Doctors don't like to reopen patients to fix something they did wrong. Lawyers don't like to retry cases that they flubbed up. A doctor or a lawyer who did that too often would not be considered professional. Likewise, a software developer who creates many bugs is acting unprofessionally.

Pacing yourself

Software development is a marathon, not a sprint. You can't win the race by trying to run as fast as you can from the outset. You win by conserving your resources and pacing yourself. A marathon runner takes care of her body both before and during the race. Professional programmers conserve their energy and creativity with the same care.

Know when to walk away

Creativity and intelligence are fleeting states of mind. When you are tired, they go away. If you then pound your nonfunctioning brain for hour after late-night hour trying to solve a problem, you'll simply make yourself more tired and reduce the chance that the shower, or the car, will help you solve the problem.

When you are stuck, when you are tired, disengage for a while. Give your creative subconscious a crack at the problem. You will get more done in less time and with less effort if you are careful to husband your resources.

Driving home

One place that I have solved a number of problems is my car on the way home from work. Driving requires a lot of noncreative mental resources. You must dedicate your eyes, hands, and portions of your mind to the task; therefore, you must disengage from the problems at work. There is something about disengagement that allows your mind to hunt for solutions in a different and more creative way.

The shower

When you are working on a problem, you sometimes get so close to it that you can't see all the options. You miss elegant solutions because the creative part of your mind is suppressed by the intensity of your focus. Sometimes the best way to solve a problem is to go home, eat dinner, watch TV, go to bed, and then wake up the next morning and take a shower.

Being late

You will be late. It happens to the best of us.

The trick to managing lateness is early detection and transparency. The worst-case scenario occurs when you continue to tell everyone, up to the very end, that you will be on time - and then let them all down. Don't do this. Instead, regularly measure your progress against your goal and come up with three fact-based end dates: best case, nominal case, and worst case. Be as honest as you can about all three dates. Do not incorporate hope into your estimates! Present all three numbers to your team and stakeholders. Update these numbers daily.

Hope

Hope is the project killer. Hope destroys schedules and ruins reputations. Hope will get you into deep trouble.

Rushing

What if your manager sits you down and asks you to try to make the deadline? What if your manager insists that you "do what it takes"? Hold to your estimates! Your original estimates are more accurate than any changes you make while your boss is confronting you. Tell him that you've already considered the options (because you have) and that the only way to improve the schedule is to reduce scope. Do not be tempted to rush.

Woe to the poor developer who buckles under pressure and agrees to try to make the deadline. That developer will start taking shortcuts and working extra hours in the vain hope of working a miracle. This is the recipe for disaster because it gives you, your team, and your stakeholders false hope. It allows everyone to avoid facing the issue and delays the necessary tough decisions.

You can't make yourself code faster. You can't make yourself solve problems faster. If you try, you'll just slow yourself down and make a mess that slows everyone else down, too.

Overtime

Overtime can work, and sometimes it's necessary. Sometimes you can make an otherwise impossible date by putting in some ten-hours days, and a Saturday or two. But this is very risky. You are not likely to get 20% more work done by working 20% more hours. What's more, overtime will certainly fail if it goes on for more than two or three weeks.

Therefore you should not agree to work overtime unless (1) you can personally afford it, (2) it is short term, and (3) your boss has a fall-back plan in case the overtime effort fails.

False delivery

Of all the unprofessional behaviors that a programmer can indulge in, perhaps the worst of all is saying you are done when you know you aren't. Sometimes this is just an overt lie, and that's bad enough. But the far more insidious case is when we manage to rationalize a new definition of "done".

We convince ourselves that we are done enough, and move on to the next task. We rationalize that any work that remains can be dealt with later when we have more time.

This is a contagious practice. If one programmer does it, others will see and follow suit.

When a team falls into this trap, managers hear that everything is going fine. All status reports show that everyone is on time. It's like blind men having a picnic on the railroad tracks: Nobody sees the freight train of unfinished work bearing down on them until it is too late.

Define "done"

You avoid the problem of false delivery by creating an independent definition of "done". The best way to do this is to have your business analysts and testers create automated acceptance tests that must pass before you can say that you are done.

The tests should be understandable by the stakeholders and business people and should be run frequently.

Help

Programming is so hard, in fact, that it is beyond the capability of one person to do it well. No matter how skilled you are, you will certainly benefit from another programmer's thoughts and ideas.

Helping others

Because of this, it is the responsibility of programmers to be available to help each other. It is a violation of professional ethics to sequester yourself in a cubicle or office and refuse the queries of others. Your work is not so important that you cannot lend some of your time to help others. Indeed, as a professional, you are honor-bound to offer that help whenever it is needed. You will likely come away having more than you gave.

This doesn't mean that you don't need some alone time. Of course you do. But you have to be fair and polite about it. For example, you can let it be known that between the hours of 10 am and noon you should not be bothered, but from 1 pm to 3 pm your door is open.

Being helped

When someone offers to help you, be gracious about it. Accept the help gratefully and give yourself to that help. Do not protect your turf. Give it thirty minutes or so. If by the time the person is not really helping all that much, then politely excuse yourself and terminate the session with thanks.

Learn how to ask for help. When you are stuck, or befuddled, or just can't wrap your mind around a problem, ask someone for help. If you're sitting in a team room, you can just sit back and say "I need some help". Otherwise, use your social networks. Call for help. Again, this is a matter of professional ethics. It is unprofessional to remain stuck when help is easily accessible.

Mentoring

For now, let me simply say that the training of less experienced programmers is the responsibility of those who have more experience. Nothing can bring a young software developer to high performance quicker than his own drive, and effective mentoring by his seniors.

Therefore, once again, it is a matter of professional ethics for seniors developers to spend time taking younger programmers under their wing and mentoring them. By the same token, those younger programmers have a professional duty to seek out such mentoring from their seniors.

Blog