Summarized from http://ptgmedia.pearsoncmg.com/images/9780137081073/samplepages/0137081073.pdf
The code written should satisfy the following criteria:
1. The code must work consistently and satisfy the requirement of the client
2. The code must solve the problem set for by the customer. Many times customer's requirements do not solve the customer's problem. It is upto the programmer to negotiate with the customer and ensure that the problem is solved.
3. The code must fit into the existing system without destabilizing or making it fragile or opaque.
4. The code must be readable by other programmers.
Preparedness
The author says "Coding is an intellectually challenging and exhausting activity.". So one should be in a state of preparedness before writing the code. Some suggestions that the author provide are as below:
1. Do not write code at 3AM especially after having already worked for 18 hours and having put in 60 - 70 hour week.
2. Do not write when some personal matter is bothering you. Try and resolve that matter before coding.
The Flow Zone
Some programmers feel that they get into a hyper productive zone known as the "flow". They do not stop programming as long as they feel they are in this state. The author suggests that it is not a very good state to be in for long. This zone is not infallible and not necessarily productive. Step away from this state and write code when you are more under control.
Listening to music while coding may actually be a distraction, depending on your disposition. The author found himself writing lyrics from the songs he was listening to when coding in the code comments.
Be prepared for interruptions when coding. It is important to attend to the needs of the others too. Keep a time period when you do not wish to be disturbed, while at the same time providing time for others to disturb you. Author also suggests getting into pair programming so that one of the pair can maintain the thread while the other answers to the interruption.
Writer's Block
There will be times when one will just not be able to code. The author suggests adopting pair programming strategy will help melt the block.
Do things that brings the creativity in you. This will depend from person to person.
Debugging
Write code such that you do not have to debug the program. This is the best form of coding. The author suggests adopting Test Driven Development will help reducing the time spent in debugging.
Pacing YourselfThe author suggests that coding is not a 100 metre dash, but a marathon and so it is important to pace oneself. One needs to ensure that one needs to conserve ones energy so that one does not end up hurting oneself.
The author says "Can’t go home till you solve this problem? Oh yes you can, and you probably should! 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"
Being LateThe author says it is difficult to avoid being late. He suggests that what is bad is to keep the stakeholders in the dark about the delay. The earlier they are briefed about the delay, the better they will be able to be prepared for the final outcome.
The author suggests do not give hope that the thing would be finished when it is known that it will not be. Do not hesitate to say "No it cannot be done". There is no point in saying "I will try" and give the stakeholder a feeling of safety which you are not confident about. Do not say "I will try" unless the stakeholder has a backup plan.
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 your boss 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. If you try to rush you will end up taking shortcuts which will lead you to a destination other than where you wish to be.
Avoid overtime. Overtime for a short time may be OK. But continuous overtime does not help anybody. It is as bad as a rush job.
Do not say something is done before it is actually done. Define "done" when you say "done".
Help
Do not hesitate to ask for help. Do not hesitate go give help. Do not hesitate to accept help.
Mentor: Mentor the juniors so that they become better programmers.
The book is about how to be a "Software Professional" and not just an "engineer".
The code written should satisfy the following criteria:
1. The code must work consistently and satisfy the requirement of the client
2. The code must solve the problem set for by the customer. Many times customer's requirements do not solve the customer's problem. It is upto the programmer to negotiate with the customer and ensure that the problem is solved.
3. The code must fit into the existing system without destabilizing or making it fragile or opaque.
4. The code must be readable by other programmers.
Preparedness
The author says "Coding is an intellectually challenging and exhausting activity.". So one should be in a state of preparedness before writing the code. Some suggestions that the author provide are as below:
1. Do not write code at 3AM especially after having already worked for 18 hours and having put in 60 - 70 hour week.
2. Do not write when some personal matter is bothering you. Try and resolve that matter before coding.
The Flow Zone
Some programmers feel that they get into a hyper productive zone known as the "flow". They do not stop programming as long as they feel they are in this state. The author suggests that it is not a very good state to be in for long. This zone is not infallible and not necessarily productive. Step away from this state and write code when you are more under control.
Listening to music while coding may actually be a distraction, depending on your disposition. The author found himself writing lyrics from the songs he was listening to when coding in the code comments.
Be prepared for interruptions when coding. It is important to attend to the needs of the others too. Keep a time period when you do not wish to be disturbed, while at the same time providing time for others to disturb you. Author also suggests getting into pair programming so that one of the pair can maintain the thread while the other answers to the interruption.
Writer's Block
There will be times when one will just not be able to code. The author suggests adopting pair programming strategy will help melt the block.
Do things that brings the creativity in you. This will depend from person to person.
Debugging
Write code such that you do not have to debug the program. This is the best form of coding. The author suggests adopting Test Driven Development will help reducing the time spent in debugging.
Pacing YourselfThe author suggests that coding is not a 100 metre dash, but a marathon and so it is important to pace oneself. One needs to ensure that one needs to conserve ones energy so that one does not end up hurting oneself.
The author says "Can’t go home till you solve this problem? Oh yes you can, and you probably should! 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"
Being LateThe author says it is difficult to avoid being late. He suggests that what is bad is to keep the stakeholders in the dark about the delay. The earlier they are briefed about the delay, the better they will be able to be prepared for the final outcome.
The author suggests do not give hope that the thing would be finished when it is known that it will not be. Do not hesitate to say "No it cannot be done". There is no point in saying "I will try" and give the stakeholder a feeling of safety which you are not confident about. Do not say "I will try" unless the stakeholder has a backup plan.
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 your boss 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. If you try to rush you will end up taking shortcuts which will lead you to a destination other than where you wish to be.
Avoid overtime. Overtime for a short time may be OK. But continuous overtime does not help anybody. It is as bad as a rush job.
Do not say something is done before it is actually done. Define "done" when you say "done".
Help
Do not hesitate to ask for help. Do not hesitate go give help. Do not hesitate to accept help.
Mentor: Mentor the juniors so that they become better programmers.
The book is about how to be a "Software Professional" and not just an "engineer".
No comments:
Post a Comment