Clean Coder

Question 1

Professionalism:
First Do No Harm:
Do No Harm to Function

Answer 1

We can’t guarantee no bugs, but we can still take an oath to create no bugs.

1. QA Should Find Nothing.
2. You Must KNOW Your Code Works.
3. Automated QA.

Question 2

Professionalism:
First Do No Harm:
Do No Harm to Structure

Answer 2

You must be able to make changes without exorbitant costs.
1. If you want your software to be flexible, flex it!
2. Refactor Mercilessly.
If you have an automated suite of tests that covers virtually 100% of the code, and if that suite of tests can be executed quickly on a whim, then you simply will not be afraid to change the code.

Question 3

Professionalism:

Work Ethic

Answer 3

You career is YOUR responsibility.
You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.

Question 4

Professionalism:
Work Ethic:
Know Your Field

Answer 4

A minimal list of the things a professional programmer should be conversant with:
・All 24 patterns in the GOF book and knowledge of many of the patterns in the POSA book.
・Know and understand the SOLID principles.
・Understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.
・Practice TDD, Object-Oriented Design, Structured Programming, Continuous Integration, and Pair Programming.
・Know how to use UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, decision tables.

Question 5

Professionalism:
Work Ethic:
Practice

Answer 5

Algorithms, Katas, and other forms of warming up, sharpening the saw are extremely important.

Question 6

Professionalism:
Work Ethic:
Know Your Domain

Answer 6

It is the responsibility of every software professional to understand the domain of the solutions they are programming. If you are writing an accounting system, you should know the accounting field.

It is the worst kind of unprofessional behavior to simply code from a spec without understanding why that spec makes sense to the business. Rather, you should know enough about the domain to be able to recognize and challenge specification errors.