10/12/2017

‘Clean Coder’ by Robert C Martin. Here are important quotes from the book.

1) Professionalism

If a nonprofessional makes an error, the employer cleans up the mess. But when a
professional makes a mistake, he cleans up the mess.

As you mature in your profession, your error rate should rapidly decrease towards the
asymptote of zero. It won’t ever get to zero, but it is your responsibility to get as
close as possible to it.

How can you know your code works? That’s easy. Test it. Test it again. Test it up.
Test it down. Automate your tests. Write unit tests that you can execute on a
moment’s notice, and run those tests as often as you can. Every single line of code
that you write should be tested. write your tests first, before you write the code
that passes them.

You should plan on working 60 hours per week.

Perhaps you don’t want to make that kind of commitment. That’s fine, but you should
not then think of yourself as a professional. Professionals spend time caring for their
profession.

Read books, articles, blogs, tweets. Go to conferences. Go to user groups. Participate

in reading and study groups

when a professional finds himself the butt of a joke, he’ll be the first to laugh

Professionals will pursue and defend their objectives as aggressively as they can. your
manager is counting on you to defend your objectives as aggressively as he defends
his. That’s how the two of you are going to get to the best possible outcome.

Commitments:-
Creating a language of commitment may sound a bit scary, but it can help solve many
of the communication problems programmers face today—estimations, deadlines, and
face-to-face communication mishaps. You’ll be taken as a serious developer who lives
up to their word, and that’s one of the best things you can hope for in our industry.

Your code must be readable by other programmers.

. Working while distracted creates waste.
Avoid the Zone. It’s really just a mild meditative state in which certain rational
faculties are diminished in favor of a sense of speed.
The problem is that you lose some of the big picture while you are in the Zone, so
you will likely make decisions that you will later have to go back and reverse. I walk
away for a few minutes I clear my head by answering a few emails or looking at some
tweets. One of the big benefits of pair programming is that it is virtually impossible
for a pair to enter the Zone.

Creativity:-

I learned a long time ago that creative output depends on creative input. I read a
lot, and I read all kinds of material. I read material on software, politics, biology,
astronomy, physics, chemistry, mathematics, and much more. However, I find that the
thing that best primes the pump of creative output is science fiction.

When you are stuck, when you are tired, disengage for awhile. Give your
creative subconscious a crack at the problem. You will get more done in less time. .
There is something about disengagement that allows your mind to hunt for solutions in
a different and more creative way.

regularly measure your progress against your goal, and come up with three fact-based
end dates: best case, nominal case, and worst case. Be as honest as you can about all
three dates. Do not incorporate hope into your estimates!

not agree to work overtime unless (1) you can personally afford it, (2) it is short
term, two weeks or less, and (3) your boss has a fall-back plan in case the overtime
effort fails.

Programming is so hard, in fact, that it is beyond the capability of one person to do

it well. No matter how skilled you are, you will certainly benefit from another
programmer’s thoughts and ideas

THE THREE LAWS OF TDD:-

1. You are not allowed to write any production code until you have first written a
failing unit test.
2. You are not allowed to write more of a unit test than is sufficient to fail—and not
compiling is failing.
3. You are not allowed to write more production code that is sufficient to pass the
currently failing unit test.

A programming kata is a precise set of choreographed keystrokes and mouse movements

that simulates the solving of some programming problem. You aren’t actually solving the
problem because you already know the solution. Rather, you are practicing the
movements

Broadening your experience:-

If you are a Java programmer, contribute to a Rails project. If you write a lot of
C++ for your employer, find a Python project and contribute to it.

keep your polyglot skills sharp.

it should be the goal of the development group that QA find nothing wrong.

Programming is an intellectual exercise that requires extended periods of

concentration and focus. Focus is a scarce resource, rather like manna. After you have
expended your focus-manna, you have to recharge by doing unfocused activities for
an hour or more.

Professional software developers know how to provide the business with

practical estimates that the business can use for planning purposes. They do not make
promises that they can’t keep, and they don’t make commitments that they aren’t sure
they can meet.

Choose disciplines that you feel comfortable following in a crisis. Then follow them all
the time. When the going gets tough, trust your disciplines.

The worst thing a professional programmer can do is to blissfully bury himself in a

tomb of technology while the business crashes and burns around him. Your job is to
keep the business afloat!
The most efficient and effective way to review code is to collaborate in writing it.
Professionals work together. You can’t work together while you are sitting in corners
wearing headphones. So I want you sitting around tables facing each other. I want you
to be able to smell each other’s fear. I want you to be able to overhear someone’s
frustrated mutterings. I want serendipitous communication, both verbal and body
language. I want you communicating as a unit

A gelled team usually consists of about a dozen people. It could be as many as twenty
or as few as three, but the best number is probably around twelve. once it happens,
it’s magic. A gelled team will plan together, solve problems together, face issues
together, and get things done.

allocate projects to existing gelled teams, they don’t form teams around projects.

Teams are harder to build than projects. Therefore, it is better to form persistent
teams that move together from one project to the next and can take on more than
one project at a time. The goal in forming a team is to give that team enough time
to gel, and then keep it together as an engine for getting many projects done.