How to Write Good Code Under Pressure.

Don’t Honor Commitments Not Made by YOU

As a programmer, you always have two choices — your commitment versus your fear.

Your commitment is the date and deadline given by you to complete your work. And when you do that, the most important thing you have with you is your word, your trust. You have to make it happen, come what may. That is where you earn your respect.

You experience fear is when someone else makes a commitment on your behalf.

Yes, that happens. Sometimes commitments are made for us. Sometimes we find that our business has made promises to the customers without consulting us. However, we are not honor bound to accept the commitments.

The difference between commitments is important.

Professionals will always help the business find a way to achieve their goals. But professionals do not necessarily accept commitments made for them by the business. In the end, if we can find no way to meet the promises made by the business, then the people who made the promises must accept the responsibility.

This is not easy. Pressure gets on everybody when commitments are not met. But at least if you have behaved professionally you can hold your head high and stick to your stand.

And if nobody is willing to understand your point of view, it is time to quit your job.

Don’t Cut Corners.

There is nothing called “Quick and Dirty code”. Dirty code is bad code. Period. Never cut corners or accept anything that is second rate.

Your real test as a good programmer comes under a crisis. If your behavior changes during a crisis, then you are not a good programmer. For example, if you follow the discipline of Test Driven Development in non-crisis times but abandon it during a crisis, then you don’t really trust that TDD is helpful.

If you keep your code clean during normal times but make messes in a crisis, then you don’t really believe that messes slow you down.

Never neglect the little things. Never skimp on that extra effort, that additional few minutes, that delivery of the very best that you can do. It does not matter what others think, it is of prime importance, however, what you think about you. Always remember cutting corners will haunt you, if not now later.

And professional programmers never take the easy route and create messy codes to move quickly. They do the best work they can and deliver the cleanest output possible, come what may.

Communicate, Communicate and Communicate.

Communication. It’s about honesty. It’s about treating people in the organization as deserving to know the facts. You don’t try to give them half the story. You don’t try to hide the story. You treat them as…as true equals, and you communicate and you communicate and communicate.

If you have important information to share with your boss, colleagues, vendors — even if it’s not great news — don’t wait. If you put off providing them with actionable information until it’s too late to act, then your news will never be well received, whether it’s good or bad.

In almost every conceivable scenario, it’s to your advantage to communicate as quickly as possible, allowing everyone involved to understand and digest the information, formulate an appropriate reaction, and respond accordingly. If it is bad news, your early warning just might allow for sufficient planning to minimize the damage.

Above all, remain professional, polite, direct, and clear — all traits that will move your communication in the right direction during your time at your current place of work.

And Lastly, Get Help When the Going Gets Tough

Pair! When the heat is on, find an associate who is willing to pair program with you. You will get done faster, with fewer defects. Your pair partner will help you hold on to your disciplines and keep you from panicking.

The quick development time of the pair often comes from an increased focus. Pairing literally is having another person looking over your shoulder all time. People actively participating in pairing are less likely to be distracted by interruptions (e.g. checking email, mind wandering to unrelated tasks, or blankly staring at the screen for minutes on end).

Even related secondary tasks can be blocked out. The person on the keyboard can focus on just banging out the code, while the partner can worry out readability, testability, robustness, user upgrade migration, and other “big picture” issues related to the new code. Working with a pair provides positive pressure to stay on task.

The adjustment period from solo programming to collaborative programming is like eating a hot pepper. The first time you try it, you may not like it because you are not used to it. However, the more you eat it, the more you like it.

And most important of all it creates a culture of collaboration and gratitude. Next time when you see someone else who’s under pressure, offer to pair with them. Help them out of the hole they are in.

As Booker T. Washington has rightly said.

“If you want to lift yourself up, lift up someone else.”