Programmer’s guide to stress-free coding

A project’s building block is a programmer.Generally, they are always under heavy stress, because of project deadlines, commitment, technical complexities, mis-understandings, communication gaps , pressure from management etc…
For a stress-free coding, Qalixa team is using a simple approach of “RIDBIO” concept !
RIDBIO is :
“ Get the Requirement & Use your Imagination ;Discuss the imagination & Build in Order “

1) Understand the Requirement & Use your Imagination
Before starting your work, use your imagination to understand what the task/ requirement is. Try to imagine how much elements will be used, how much classes may need to code, on UI part, how much changes or new elements are required.
               
2) Discuss the Imagination & Build in Order
Coding is like building a house, how are you going to build your house ?
As shown below in graphic, or you are going to build it in order ?

Many times it happen that a programmer gets away with complexities of the project, and is unable to deliver what he is capable of. One should always stay focussed about task, and should try to complete it in smaller parts.
”Do the simple bits first, you may never need the complex bits ! ”
Always code the simple cases first. Not only is it more likely that the requirements and specification process has got the simple cases right (more people at more meetings can understand them), but it's less hassle if you have to throw them and start again.

3) Test , test, test & TEST
Think of it like building a house.Before you build the walls, you want to make pretty sure the foundations are stable. If you find a fault with the footings after the walls are raised it's going to cost a lot to get it fixed. If the roof's gone on and the furniture is in place, that same fault might cost more than the house to put right. One should make sure that every function, every method, every object, every subroutine has an associated automatic test harness which tests normal, limit and error cases for every parameter, and makes sure it does the right thing.
4) Working in  ‘ bits ‘
If you work regular office hours, try to divide your work into chunks you can complete in a day. Try to build and test some sort of subsystem by the end of a week, and so on. It seems obvious, but it's amazing how many people don't even try to do this.
First it lets you free your mind from clutching onto part-finished work. I've never been able to fully relax if I have remember where I've got up to for tomorrow; well, not and do any useful work the next day, anyway. The second benefit is the happy "kick" we all get from "closure". I get a physical sense of release when I've finished and tidied a piece of work; a feeling of "now I could do anything!".


Summarizing up the things :

Coding : At the end of the day, if the program doesn't run and make money for the client, you haven't done anything.

Testing : You have to know when you're done. The tests tell you this. If you're smart, you'll write them first so you'll know the instant you're done. Otherwise, you're stuck thinking you maybe might be done, but knowing you're probably not, but you're not sure how close you are.

Listening : You have to learn what the problem is in the first place, then you have to learn what numbers to put in the tests. You probably won't know this yourself, so you have to get good at listening to clients - users, managers, and business people.

Designing : You have to take what your program tells you about how it wants to be structured and feed it back into the program. Otherwise, you'll sink under the weight of your own guesses.