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
Was this helpful?
