Craftsmanship and Ethics

Source
How to become a professional programmer
1. Short iterations - 1 to 2 weeks is fine. 4 weeks is too long. You have deployable software. Not deployed software. It is a business decision to decide is the deployable software should be deployed.
2. Best way to establish requirements is to implement your best guess and compare it against what the customer needs. Give the small changes to the customer and ask him if that is what they want. Don't ask the customer to sign off on the requirements document.
3. Separate what is likely to change from what is likely NOT to change and put them in different parts. E.g. Do not put business rules in GUI code. GUI and business rules change for different reasons. GUI changes for merit reason. Business rules change for policy rules. No validation in javascript. There is a way to get user experience and at the same time separating what changes from what does not.
4. Always better to DO than NOT DO (wait for req., Module b from group b). If you are wainting, help the other group achieve it.
5. NEVER be blocked. Decouple dependencies by creating stubs, mocks & stimulators. Your code can run without their code.
6. Architectures that impede software development. Doon't try to solve every problem tthat is. Do you create more difficulties than you solve. Have several simple architectures for the enterprise. Architects must write code. They must live the mess they create.
7. How do you address mess? Face that you have a mess and solve it increamentally solve it. Bit by Bit, day by day. Simple rule. Check in the code that is a little better than you checked it out.
8. No grand re-design. Mgmt. does not want it. It is expensive. Where are the reqs. for the new re-deisgn system? In the old system. The old system is changing. New system has to catch up. So one little bit at a time.
9. Practise progressive widening. Small/thin feature from GUI to DB. Then widen it one thin feature at a time.
10. Progressive deepening. Get something working in one layer and stretch it across other layers. GUI programmer waited for middle layer. GUI wrote simple dirty middle layer. Then write SOA, DAO etc...
11. Make it work, right, fast
12. Slowed down by bad code. Why did Jim write it? Bad code is not something that slows down somebody months from now, but us, right now. Don't write and you will not read. We did not have time to write it well. You are going to be significantly slowed down by this code but you did not take the time to avoid being significantly slowed down. You look at your 2 hours ago code and surprised at what it does. DO NOT WRITE BAD CODE. Bad code saves a few thousand $s. But bad code will increase repeating maintenance cost. Our product is code not the behaviour. It does not matter if the product behaves as expected. If code is bad, product is bad. Bad code stays with the team. If regression rate is high, there is a chance that code is fast. The only way to go fast is to slow down and write the code well.
13. Write clean code: Every line of code is the way you expect it to be. No surprises. As you read it its obvious. how big should a function be? Small, good function and variable names. Clean code begins with 1 line of good code.
14. TDD - test driven development. Do not write a unit of production code without writing test code. Stop writing unit test code the moment the test code fails. Compilation failure is unit test failure. Write production code. Stop writing production code until unit test passes. Write more unit test code. Keep swinging between unit test and production code every 30 seconds.
15. What makes s/w flexible. Tests. Test runnable in a simple fashion.
16. Don't use QA to find bugs. QA will find. But programmer's should aim at QA not finding bugs.
17. Increase code coverage. It should be as close to 100%. 90% is pretty good.
18. Avoid debugging. Look at the code. You had it working a minute ago. Do it rarely.
19. Automate them. Manual tests - less. Manual test should be explorative.
20. Done means - all tests passes.
21. Test through the right interface. Tesing through GUI, when GUI changes, tests fails. Do not test business rules through the GUI. Test business rules through a different test. Test only GUI code through the GUI test scripts.
22. Training. Make sure new people work with old people.
23. Write code because you care. Free ware tools are good quality. I will be as well as I can.