Highlights for The Pragmatic Programmer-by Andrew Hunt, David Thomas - Part 1
2019-02-11-highlight-the-pragmatic-programmer-part-01
This is a highlight and summary content for my favorite parts
PREFACE
What Makes a Pragmatic Programmer?
- Early adopter/fast adapter: instinct for technologies, love trying things out
- Inquisitive: be a pack rat for little facts
- Critical thinker: rarely take things as given without first getting the facts
- Realistic: understand the underlying nature of each problem you face
-
Jack of all trades: try hard to be familiar with a board range of technologies and environments
We’re challenging you to THINK about WHAT you’re DOING WHILE you’re DOING
Chaper 1: A Pragmatic Philosophy
The Cat Ate My Source Code
One of the cornerstones of the pragmatic philosophy is the idea of taking respnsibility for yourself and your actions.
Take Responsibility
You have the right NOT to take on a responsibility for an impossible situation, or one in which the risks are too great. When you DO accept the responsibility for an outcome, you should expect to be held accountable for it.
Make a mistake or an error in judgment -> admit it honestly and try to offer options. Don’t BLAME, or make up an excuse. Provide solutions.
If the disk crashes-taking all of your code with it-and you don’t have a backup, it’s YOUR FAULT.
“The cat ate my source code”, won’t cut it. Before tell anyone why something can’t be done, stop and listen to yourself first. Does it reasonable? or stupid?
Before you go and tell them the bad news, is there anything else you can try? Instead of excuses, provide options.
Don’t say it can’t be done; explain what can be done to salvage the situation. How to prevent it from happening again?
Software Entropy
Don’t live with Broken Windows. Fix each one as soon as it is discovered.
Take some action to prevent further damage and to show that you’re on top of the situation.
Good-Enough Software
You can discipline yourself to write software that’s good enough-good enough for yours users, for future maintainers, for your own peace of mind.
Know when to stop
Dont’ spoil a perfectly good program by overrembellishment and overrefinement. Move on, and let your code stand in its own right for a while.
Your Knowledge Porfolio
Your knowledge and experience are your most important professional assets.
Unfortunately, they’re expiring assets. Your knowledge becomes out of date as new techniques, languages, and evironments are developed.
Goals
- Learn at least one new language every year
- Read a technical book each quater
- Read nontechnical books, too
- Take classes
- Participate in local user groups
- Experiment with different environments
- Stay current
- Get wired
Critical thinking
Think critically about what you read and hear
Communicate
We have to communicate on many levels. We spend hours in meetings, listening and talking. A large part of oour day is spent communicating, so we need to do it well.
Know what you want to say
Plan what you want to say. Write an outline. Then ask yourself, “Does it get acroos whatever I’m trying to say?”. Refine it until it does.
Know your audience
You need to understand the needs, interests, and capabilities of your audien.
Choose your momment
As part of understand what your audience needs to hear, you need to work out what their priorities are. Make what you’re saying relevent in time, as well as in content.
Sometimes all it takes is a simple question: “Is this a good time to talk about…?”
Choose a style
Adjust the style of your delivery to suit your audience: briefing, wide-ranging chat, reports, documents… If in doubt, ask
Make it look good
Your ideas are importent. They deserve a good-looking vehicle to convey them to your audience
Imvolve your audience
If possible, involve your readers with early drafts of your document
Be a listener
If you want people to listen to you, listen to them.
Get back to people
Always respond to e-mails and voice mails, even if the response is simply
Leave a comment