The Practice of Writing Excellent Code By Pete Goodliffe

Recently from past one week i have been reading Code Craft: The Practice of Writing Excellent Code book by Pete Goodliffe.

I can admit this book is great for programmers and found good tips across the book.You can really see that he put a lot of research and experience into it. Experienced programmers probably wouldn't always agree with all of his arguments, which is quite normal for this kind of topics, but they are deliberately written to get you thinking yourself.

Please read Book review by Daniel Klein.

Actually i liked types of programmers chapter i.e Chapter 16 Code Monkeys a lot and it was funny and learning.

Author tries to divide types of programmers in a high intelligent way.Below are the types of programmers.I will try to give only strengths and weakness.Please get a copy of this book if you are so serious about to improve the code quality.

1) The Eager Coder

Strengths
Eager Coders are productive, in terms of code quantity. They write a lot of code. They love learning new stuff and are really enthusiastic—even passionate—about programming. The Eager Coder loves his job, and genuinely wants to write good code.

Weaknesses
Because of his unfettered enthusiasm, the Eager Coder is hasty and doesn’t think before rushing into the code editor. He does write a lot of code, but because he writes so fast, it’s flawed—the Eager Coder spends ages debugging. A little forethought would prevent many silly errors and many hours ironing out careless faults.Unfortunately, the Eager Coder is a really bad debugger. In the same
way he rushes into coding, he dives straight into debugging. He’s not methodical,
so he spends ages chasing faults down blind alleys.He’s a poor estimator of time. He’ll make a reasonable estimate for the case when it all goes well, but it never does go according to plan; he always takes longer than expected.

2) The Code Monkey

Strengths
Give them a job and they’ll do it—reasonably well, reasonably on time.A Code Monkey is reliable and can usually be counted on to put in extra effort when it comes to crunch time.Unlike Eager Coders, Code Monkeys are good estimators of time.They are methodical and thorough.

Weaknesses
Although Code Monkeys are careful and methodical, they don’t think outside of the box. They lack design flair and intuition. A Code Monkey will follow the existing code design conventions unquestioningly, rather than address any potential problems. Since they are not accountable for the design, they don’t accept responsibility for any problems that arise and often won’t take the initiative to investigate and fix them.It’s hard to teach a Code Monkey new stuff; he’s just not interested.

3) The Guru

Strengths
Gurus are the experienced magicians. They know all the modern techniques and understand which old tricks are better. (Gurus invented all the cool techniques in the first place.) They have a wealth of experience and write mature maintainable code.A good Guru is a wonderful mentor—there’s so much to learn from him.

Weaknesses
Few Gurus can communicate well. They’re not always tongue tied, but their ideas fly so fast and at a level beyond mere mortals’, so it’s hard to follow them. A conversation with a Guru makes you feel stupid,confused, or both.
The poorer a Guru’s communication skills, the worse mentor he will make. Gurus find it hard to understand why others don’t know as much or don’t think as fast as they do.

4) The Demiguru

Strengths
It’s easy to assume that a Demiguru has no strengths, but his great asset is his belief in himself. It’s important to trust your own abilities, and to be secure that you write high-quality code. However . . .

Weaknesses
The Demiguru’s great weakness is his belief in himself. He overestimates his abilities, and his decisions will jeopardize your project’s success. He’s a serious liability.The Demiguru will haunt you, even after he’s moved on to new pastures. You’ll be left with the consequences of his bad design and overly clever code.

5) The Arrogant Genius

Strengths
The Genius has considerable technical skill. He can provide a strong technical lead and will catalyze a team when everyone agrees with him.

Weaknesses
The Genius doesn’t like to be proved wrong and thinks that he must always be right. He feels compelled to act as an authority; The Genius knows everything about everything. He can never say I don’t know,suffering from a full humility bypass.

6) The Cowboy

Strengths
Cowboy code works, but isn’t particularly elegant. Cowboys like to learn new things, but seldom get around to it (it’s too much like hard work).

Weaknesses
You’ll spend ages cleaning up after a Cowboy. His aftermath is not a pleasant place to be. Cowboy code always requires later repair, rework,and refactoring. They have a limited palette of techniques to use, and no real engineering skills.

7) The Planner

Strengths
They do design. They do think. They don’t hack out thoughtless code.

Weaknesses
When a Planner sets to work, there is a very real danger of over design.He tends to create very complex systems. Planners are the key cause of analysis paralysis—where development becomes more focused on methods and modeling than on prototyping and creating a solution. The Planner likes to generate endless documents and call meetings every other hour.He spends ages thinking and not enough time doing anything. He knows a lot, but it doesn’t all make the leap from theory to practice.

8) The Old Timer

Strengths
He’s been programming for years, and so he has considerable experience and wisdom. The Old Timer has a mature approach to coding. He has learned which qualities make good and bad programs and how to avoid the common pitfalls.

Weaknesses
The Old Timer won’t willingly learn new techniques. Fed up with fashionable ideas that promise much and deliver little, he’s a bit slow and can be resistent to change.
He has little patience, thanks to years of corporate ineptitude. He’s been at the receiving end of countless tight deadlines and unreasonable managers.

9) The Zealot

Strengths
He knows BigCo’s products inside out and will produce genuinely good designs based on them. He is productive with that technology, but not necessarily maximally productive—other unfamiliar approaches might be more effective.

Weaknesses
Being a Zealot, he’s neither objective nor pragmatic. There may be better non-BigCo designs that he will miss. Worse, though, are the Zealot’s continual rants about BigCo.

10) The Monocultured Programmer

Strengths
The Monocultured Programmer is focused and determined. He’ll ensure that the project works, or he’ll die trying. He’s willing to put in a lot of extra effort, and he’s really useful as deadlines draw near.

Weaknesses
He expects others to be as obsessive and focused as he is and might be disapproving of those who aren’t. His biggest danger is overlooking things, since he permanently lives too close to the problem.

11) The Slacker

Strengths
At least he knows how to have fun.

Weaknesses
A Slacker is an obvious liability. It’s hard to prove he’s slacking—some hard problems do take a while to sort out. A programmer might not be slacking; he just might not have enough skill to solve the problem quickly.

12) The Reluctant Team Leader

Strengths
The Reluctant Team Leader has a real sympathy for the programmer’s plight—he’s been there and now wishes he was back. Often, he is far too willing to take responsibility for late software delivery to prevent the programmers being picked on by management. Just as he’s not good at delegating work, he’s not good at apportioning blame.

Weaknesses
When a Team Leader tries to write code, it will be awful. He never has enough time to write, design, or test carefully enough. He naïvely plans himself a full day’s coding alongside team leading duties. He can’t fit it all in, and so the Reluctant Team Leader spends longer and longer in the office, trying to keep up. He can’t organize well, can’t explain things to managers, and can’t manage his team members properly.

13) The Ideal Programmer

The fabled Ideal Programmer is part:

Politician
He must be diplomatic, able to deal with the peccadilloes of these weird code monkeys and the many, many more creatures that inhabit the software factory—managers, testers, support, customers, users, and so on.

Relational
He works well with others. He isn’t territorial about his code and isn’t afraid to get his hands dirty if a task is for the common good. He communicates well—he can listen as well as talk.

Artistic
He can design elegant solutions and appreciate the aesthetic aspects of a high-quality implementation.

Technical genius
He writes solid, industrial-strength code. He has a broad palette of technical
skills and understands how and when to apply them.

Finally when we want to know diff between good and bad programmers:

Good programmers . . .
1) Are PRATs: politicians,relational, artistic, and technical
2) Are THICK: team players,honest and humble, improving constantly, considerate,and keen

Bad programmers . . .

1) Are not interested in writing good code
2) Do not work well on a team
3) Try to look better than they really are
4) Stagnate—they don’t seek to improve themselves


Contents Of this Book:

Cutting code: At the codeface
Chapter 1: On the defensive
Chapter 2: The best laid plans
Chapter 3: What's in a name?
Chapter 4: The write stuff
Chapter 5: A passing comment
Chapter 6: To err is human

Cutting code: The secret life of code
Chapter 7: The programmer's toolbox
Chapter 8: Testing times
Chapter 9: Finding fault
Chapter 10: The code that Jack built
Chapter 11: The need for speed
Chapter 12: An insecurity complex

Cutting code: The shape of things to come
Chapter 13: Grand designs
Chapter 14: Software architecture
Chapter 15: Software evolution

Life in the software factory: A herd of programmers
Chapter 16: Code monkeys
Chapter 17: Together we stand
Chapter 18: Practising safe source

Life in the software factory: Part of the process
Chapter 19: Being specific
Chapter 20: A review to a kill
Chapter 21: How long is a piece of string?

Life in the software factory: From the top
Chapter 22: Recipe for a program
Chapter 23: The outer limits

About the Author:
Pete Goodliffe is an expert software developer who never stays at the same place in the software food chain; he's worked in numerous languages on diverse projects. He also has extensive experience in teaching and mentoring programmers, and writes the regular "Professionalism in Programming" column for ACCU's C Vu magazine (www.accu.org). Pete enjoys writing excellent, bug-free code, so he can spend more time having fun with his kids.

Please do get a copy of this book and enjoy reading this book.