The Pragmatic Programmer
Chapter I : Pragmatic Philosophy
Characteristics
An awesome guy should be | |
Early Adopter or Fast Adapter | Instinct of the technologies and techniques |
Love try things out | |
Grasp quick | |
Confidence with their experiences | |
Inquisitive | Ask a questions |
Critical Thinker | |
Realistic | Understand the nature problem |
How difficult it is? | |
How long it will takes? | |
Jack of All Trades | Try to familiar with technology development, challenge or area |
Be Responsible
You should care about your craft and also your work maybe it will be takes a lot of time and also needs hard work but it will repaid in the future
Broken Windows
Treat your projects when it be | |
Good | Don't mess it up |
Bad | Try to fix it up with provide an options; Ask question to yourself : is there anything else you can try? |
Stone Soup
An awesome guy should be | |
Be Catalyst | Be the first one that has initiative to build something or start something |
Grow More | |
Be Notice with small things | |
Create Things into Smaller |
Boiled Frog
An awesome guy should be |
Stay Notice |
Repeat - Review |
Ask For Help |
Don’t Afraid |
Don't Frustrating |
The painting become lost in the paint!
Critical Thinking
Good requirement means enough well for their users. the future maintenance, and also yourself
Portfolio
Things To Do | |
Regularly | |
Buy Low – Sell High | |
Review and Rebalance | Dynamic |
Manage Risk | Don’t invest all money in high risk |
Diversify | Variative |
Goals
Things To Do | |
New language | Learn new language every years |
Stay current | It mean stay up to date |
Read books (non/it) | Read book every quarter years |
Feel comfortable ? Learn other | |
Community | Actively participate |
Go to your doctor and ask your reads | |
Don’t isolation |
Communication
An awesome guy should | |
Know what you want to say | Plan what you want to say |
Set an outline of what you want to say | |
Style | |
Make it looks goods | You must know how to spelling with a style to interact your audiences |
Feedback | Ask a feedback to your colleague |
Listen other | |
Get back to people | As soon as possible |
replay all email | |
Audience |
Wisdom
Ask to yourself with these questions |
What is their interest in what you've got to say? |
What do you want to learn? |
How sophisticated are they? |
How much detail do they want? |
Whom do you want to own the info? |
How can you motivate them to listen to you? |
Chapter II : Pragmatic Approach
Don’t Repeat Yourself
Make it reusable
Types of Duplication | |
Imposed | Seems need to be duplications |
There should be documentation | |
Impatient | Lazy and do duplicated |
There is no shortcut | |
inadvertent | A bad design implemented |
Did not realized | |
Inter development |
Tips: Ask question to yourself, your code is it good for performance? Example: adding flag on setter to make it cacheable
Orthogonality
Specs | |
Loose Coupling | |
High Cohesion | |
Isolated | |
Easy to Tested | Include unit testing and integration testing |
Be Independent Component | Only have single purpose |
Tracer Bullets
Tips: If Requirement made you in deadlock path use tracer bullets to find the target.
Prototypes
Make dummy for client
What |
Architecture |
New Function |
Structure of example data |
Third party |
Performance issue |
User interface design |
Question |
Responsibility of major component |
Collaboration? |
Coupling minimum? |
Potential duplication? |
Interface definition? |
Constraint acceptable? |
Module has a data? |
Chapter 3 : The Basic Tools
Chapter 4 : Pragmatic Paranoia
Chapter 5 : Bend or Break
Chapter 6 : While You Are Coding
Chapter 7 : Before the Project
Chapter 8 : Pragmatic Projects
Last updated
