The Clean Coder - a book written by Robert C. Martin
The Robert C. Martin series consist of books : The Clean Coder, Clean Code, Agile Estimating and Planning, Working Effectivly with Legacy Code. Some of the sentences are taken directly from the book.
So, the first book will give developers information how to become professional coder. It means that you should take the responsibility of you work and your development. You should work for you employer 40 hours per week and additionally work for you career 20 hours per week. Professionals spend time caring for their profession. Your career is your responsibility not your employer´s.
The cood code should be extendable, maintainable. It should lend itself to modifications and read like a prose.
Professional know the domain (field) they are working for. They dont harm the code (functions and structure). They do tests (automatic tests, unit tests) and take responsibility if they fail. They are not timid. They collaborate and mentor others.
Coder should be specific and should not use the sentence: I will try. Instead he/she should use I do or don´t do it. The coder will have to be honest. If there in not enough time to create the solution then he/she must say it. Professionals have the courage to say no to their managers. In cases when PM or the manager will misunderstood or give out exessive promises to the customer then the professional coder will have to interfere. When a train is bearing down on you and you are the only one who can see it, you can either step quietly off the track and watch everyone else get run over, or you can yell "Train!Get off the track!".
When the developer has not enough time to develop the solution in a certain period of time, then he/she:
1. should find out what is the real need to get it done with so short time
2. should offer the solution with less functionality (we can do simple webpage with login possibility, but it will NOT email a forgotten password to you and the banner and footer section will not work properly).
3. shuld explain shortly why it will take longer to fulfill the assignement'
4. should not drop the coding disciplines (unit and functional tests)
5. should not allow to add more functionality (additional features)
6. Be professional, not just "hero".
Passive aggression - situation when all the team members are not in the same page...and we let one of our team member to walk off the end of the cliff. We have evidence that the information is sent to everybody..but we are not sure that everyone has read it or understand it the same way (we might have some doubts, but we dont care enough).
Saying yes!
Professionals can always say NO to everything that is asked of them, but they should work hard to find creative ways to make "yes" possible.
CODING
The coder should be preapared:
- understand what kind of customers problem they are solving; what kind of structure to use
- specify the customers need
- the code must fit well into the existing system. The dependencies must be well- managed
- the code must be readable by other programmers
To write good code the coder should concentrate and focus; if needed eliminate the distractions.
The worry (you are worried about the sick kid, some other problems) code is never good. If you can, please resolve the worry!!! If you can´t solve it then you have to learn how to shut down the background process.
When you are tired then please dont write the code.
The flow zone- time when coders feel that they are the most productive. Avoid it. Instead practise TDD (test driven development) and pair programming. While being in the zone the coder will lose some of the big picture.
Music is not helping you to concentrate.
Writers block. Blocking issue can be melted away when you find yourself a pair partner.
To be creative you need creative input. Read the news, books, listen to music, visit the opera....
Debugging. Reduce the debugging time by adopting the practises of Test Driven Development (TDD). "Doctors dont want to reopen patients to fix something that they did wrong."
"Know when to walk away! Creativity and intelligence are fleeting states of mind. When you are tired, they walk away. Sometimes the best way to solve the problems 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 promised to write this code by Friday, but you cant. You should measure the process and be transparent during the whole development cycle. If you give evaluations then give 3 options: best, normal, worst case. If you need to change them, then detect the need as soon as possible and inform others.
Dont give hope! "Hope is the project killer. Hope destroys schedules and ruins reputations."
Dont rush! If really needed and possible then reduce the scope.
Overtime work is sometimes needed, but you should personally afford it.
The development is ready when it passes the automated acceptance tests (for example FITNESSE( java based acceptance testing tool), Selenium, RobotFX, Cucumber).
Programmers should help each others.
TDD
UNIT TESTING
1. At first you write a small part of a unit test (first test should be the failing unit test)
2. Then a bit code to make that test compile
Unit test is sa low-level documentation. Written for programmers.
ACCEPTANCE TESTING. Written for business
Testing the business requirements. Usually business analyst or QA will write those tests using FITNESSE, Cucumber, cuke4duke, robot framework, Selenium. Programmer should automate those tests.
The Robert C. Martin series consist of books : The Clean Coder, Clean Code, Agile Estimating and Planning, Working Effectivly with Legacy Code. Some of the sentences are taken directly from the book.
So, the first book will give developers information how to become professional coder. It means that you should take the responsibility of you work and your development. You should work for you employer 40 hours per week and additionally work for you career 20 hours per week. Professionals spend time caring for their profession. Your career is your responsibility not your employer´s.
The cood code should be extendable, maintainable. It should lend itself to modifications and read like a prose.
Professional know the domain (field) they are working for. They dont harm the code (functions and structure). They do tests (automatic tests, unit tests) and take responsibility if they fail. They are not timid. They collaborate and mentor others.
Coder should be specific and should not use the sentence: I will try. Instead he/she should use I do or don´t do it. The coder will have to be honest. If there in not enough time to create the solution then he/she must say it. Professionals have the courage to say no to their managers. In cases when PM or the manager will misunderstood or give out exessive promises to the customer then the professional coder will have to interfere. When a train is bearing down on you and you are the only one who can see it, you can either step quietly off the track and watch everyone else get run over, or you can yell "Train!Get off the track!".
When the developer has not enough time to develop the solution in a certain period of time, then he/she:
1. should find out what is the real need to get it done with so short time
2. should offer the solution with less functionality (we can do simple webpage with login possibility, but it will NOT email a forgotten password to you and the banner and footer section will not work properly).
3. shuld explain shortly why it will take longer to fulfill the assignement'
4. should not drop the coding disciplines (unit and functional tests)
5. should not allow to add more functionality (additional features)
6. Be professional, not just "hero".
Passive aggression - situation when all the team members are not in the same page...and we let one of our team member to walk off the end of the cliff. We have evidence that the information is sent to everybody..but we are not sure that everyone has read it or understand it the same way (we might have some doubts, but we dont care enough).
Saying yes!
Professionals can always say NO to everything that is asked of them, but they should work hard to find creative ways to make "yes" possible.
CODING
The coder should be preapared:
- understand what kind of customers problem they are solving; what kind of structure to use
- specify the customers need
- the code must fit well into the existing system. The dependencies must be well- managed
- the code must be readable by other programmers
To write good code the coder should concentrate and focus; if needed eliminate the distractions.
The worry (you are worried about the sick kid, some other problems) code is never good. If you can, please resolve the worry!!! If you can´t solve it then you have to learn how to shut down the background process.
When you are tired then please dont write the code.
The flow zone- time when coders feel that they are the most productive. Avoid it. Instead practise TDD (test driven development) and pair programming. While being in the zone the coder will lose some of the big picture.
Music is not helping you to concentrate.
Writers block. Blocking issue can be melted away when you find yourself a pair partner.
To be creative you need creative input. Read the news, books, listen to music, visit the opera....
Debugging. Reduce the debugging time by adopting the practises of Test Driven Development (TDD). "Doctors dont want to reopen patients to fix something that they did wrong."
"Know when to walk away! Creativity and intelligence are fleeting states of mind. When you are tired, they walk away. Sometimes the best way to solve the problems 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 promised to write this code by Friday, but you cant. You should measure the process and be transparent during the whole development cycle. If you give evaluations then give 3 options: best, normal, worst case. If you need to change them, then detect the need as soon as possible and inform others.
Dont give hope! "Hope is the project killer. Hope destroys schedules and ruins reputations."
Dont rush! If really needed and possible then reduce the scope.
Overtime work is sometimes needed, but you should personally afford it.
The development is ready when it passes the automated acceptance tests (for example FITNESSE( java based acceptance testing tool), Selenium, RobotFX, Cucumber).
Programmers should help each others.
TDD
UNIT TESTING
1. At first you write a small part of a unit test (first test should be the failing unit test)
2. Then a bit code to make that test compile
Unit test is sa low-level documentation. Written for programmers.
ACCEPTANCE TESTING. Written for business
Testing the business requirements. Usually business analyst or QA will write those tests using FITNESSE, Cucumber, cuke4duke, robot framework, Selenium. Programmer should automate those tests.
