# The pragmatic programmer
###### tags: `Books`

## C0. Preface

### What’s pragmatic programmer?

#### Tip 1: Care about your craft

Care about doint it well.

#### Tip 2: Think! About your work

Think about what you're doing while you're doing

### Individual/ big team

Always a room for individuality on large team

### Continuous process

Continuously making many small improvements
* Every day, refine your skill and add a new tool to your skill set

## C1. Pragmatic Philosophy

* Place yourself in the bigger context to seek out the bigger picture
* Take responsibility for everything you do

### Topic 1: It’s your life

Don’t afraid to be changed, you can work from home as you want

#### Tip 3: You have Agency

> “You can change your organization or change your organization”
> Martin Fowler

### Topic 2: The cat ate my source code

Take charge for your own career and aren’t afraid to admit ignorance or error.

#### Team trust

Bidirectional trust between you and team
Trust is essential for creativity or collaboration

#### Take Responsibility

* Analyze the situation for risks that are beyond my control
* Have right not to take on a responsibility for:
* An imposiible situation
* Risks are too great
* Ethical implications are too sketchy
* When you make a mistake or an error:
* Admit it honestly
* Offer options
* **Don't blame someone or something else, or make up an excuse**
* **Don't blame the problem on a vender, a programming language, management, or your coworkers**
* **It's up to YOU to provide solutions, not excuses**
* If you don't have backup for your project, it's your fault.

#### Tip 4: Provide options instead of excuses

> Before you approach anyone to tell them why something can't be done, Ask yourself:
> 1. Does your excuse sound resonable, or stupid?
> 2. How's it going to sound to your boss?
> 3. Is there any you can try?
> 4. What can be done?

**Refactoring**

Explain the value of refactoring

**Prototyping**

Portotype to determine the best way

**Testing**

* Test to code
* continuous testing

**Additinal resources**

* Do you need to learn new technique or more in depth?
* A book / course

**Lame excuses**

Tell your cat / rubber duck first

#### Challenge

When you say "I don't know", be sure to follow with "but I'll find it out."

### Topic 3: Software Entropy

> Entropy is a term that refers to the amount of "disorder" in a system

#### Software rot or technical debt

The software disorder increase, implied that they will pay it back someday

Creating a vicious spiral

**Factor that contribute**

* Project's psychology or culture

#### Tip 5: Don't live with broken windows

* Broken windows： bad designs, wrong decisions, or poor code
* Fix them ASAP
* Board it up when the time is insufficient
* Comment out the offending code, leave the message like "not implemented" or substitute with dummy data instead
* Don't cause collateral damage

### Topic 4: Stone soup and boiled frogs

Catalyst: soliders

Resources providers: Villagers

#### Start-up fatigue

You know what you're doing and it's right. You just need the permission. But everyone will guard their own resources.

* Bring oit the stones
* Pretend it's not important.
* Sit back and Wait for them to ask you to add the functionality you originally wanted😎
* Show people a glimpse of the future.

#### Tip 6: Be a Catalyst for Change

> A person who acts as a catalyst to facilitate a human chemical reaction or system process, without themselves being consumed in the reaction

#### Tip 7: Remember the Big picture

Constantly review what's happening around you, not just what you personally are doing.

#### Challenges

- Which soup what're making? (stone soup or frog soup)
- Without looking around: --> Then Do the same to your project!
- How many exits in the room?
- How many lights are in the ceiling above you?
- How many people?
- Is there anything out of context, anything that looks like it doesn't belong?

### Topic 5: Good-Enough Software

Write good-enough software for:
* Users
* Future maintainers
* Your own peace of mind

Meet standards:

* User's requirement
* Performance
* Privacy
* Security

It's unprofessional to:

* Promise impossible time scale and to cut basic engineering corners to meet deadline
* Ignore user's requirement to add new feature
* Polish up the code just one more time

#### Tip 8: Make quality a requirement issue

Give your user somethinf to play eith early, their feedback will lead you a better eventual solution

**When to stop**

* Don't spoil a good program by overembellishment and overrefinement

#### Challenges

* Advantage and disadvantage between loosely couple modules and microservices?
* **Feature bloat**: The software that comtains far more features you would ever use

### Topic 6: Your knowledge portfolio

Your knowledge and experience are expiring assets

#### Build your Portfolio

***Invest regularly***

Learning as a habit, develop a routine

***Diversity***

The more *different* you know, the more valuable you are. Don't forget all the *other* skills you need.

***Manage risk***

Similar to spectrum from risky, potentially hight-reward to low-risk, low-reward standards.

Don't put your technical eggs in the one basket

***Buy low, sell high***

Learning an **emerging** technology before it becomes popular can be just as hard as finding an undervalued stock

Learning Java back when it was first introduced and unknown may have been risky at the time, but it paid off handsomely for the early adopters

***Review and rebalance***

Brush up the database technology that you haven't used in a while

#### Tip 9: Invest regularly in your portfolio

**Goals**

***Learn at least one new language every year***

Every lauguage solve same problem in different ways.

Help borden your thinking and avoid getting stuck ina rut.

***Read a technical book each month***

Topic related to current project --> master technologies current using -->
Topic irrelevent to your current project

Books can gain your deep understanding.

***Read nontechnical books , too***

The books about people and soft skills. You work with people, are employed by people. And your products are used by people,

***Take classes***

Look for interesting courses at a loca or online college or university.

***Participate in local groups and meetups***

Isolation can be deadly of your career, actively participate.

***Experiment with different environments***

Try a sophisticated IDE with cutting-edge features

***Read current***

Read news and posts online on techology different from your current project

Once you feel comfortable on new language or bit of technology, learn another one

>It doesn't matter whether you ever use any of those technologies on a project, or whether you put them on the resume.
> **The process of learning will expand your thinking, new ways of doing things.**

Get familiar with object orientation, and you'll write procedural programs differently.

Understand the functional programming paradigm, you'll write object oriented code differently.

**Opportunities for learning**

If you've got a question that you don't know, find out the answer!

If you can't find the answer yourself, find out who can.

Talking to other people will build your personal network.

Use your dead moment to read.

**Critical thinking**

Think critically about what you read and hear.

Ensure your portfolio is neutral and is unswayed by vendor or media hype.

Beware of the zealots.

A book is featured by a bookstore doesn't mean it has a good content.

#### Tip 10: Critically analyze what you hear and read

***Ask 5 Whys***

Ask "why?" at least five times.

***Who does this benefit?***

Follow the money to analyze.

***What's the context?***

Best context for who?

What's the prerequisites?

What're the consequences, short and long term?

***When and where would this work?***

* What circumstances?
* Too early? Too late?
* First-order thinking(what will happen next) then second-order thinking(what will happen after that?)

***Why is this a problem?***

* Underlying model

#### Challenges

1. Start learning new language this week
2. Start reading the new book
3. Get out and talk technology with people

### Topic 7: Communicate!

Write natural language honors to DRY principle, ETC and automation

#### Tip 11: English is another programming language

**Know your audience**

Understand the needs, interests, and capabilities of your audience.

Making the appropriate pitch to each group (Marketing, end users, development and operation manager and developer)

Ask them the questions and gather the feedback

> The meaning of communication is the reason you get

**Know what you want to say**

Write an outline --> ask yoursf, "Does this communicate what I want to express to my audience in a way that works for them?" --> Refine it until it does

**Choose your moment**

* Choose the right moment.
* Make what you're saying relevant in time and content.
* "Is this a good time to talk about...?"

**Choose a style**

Adjust your style to suit your audience:

* Just the facts
* Long, wide ranging chatting

About your audience:
* What's their skill level and exprience in this area?
* If in doubt, ask

**Make it look good**

* Mark down ro Word processor: Make your documents look good (Page headers and footers)
* Check the spelling

* **Involve your audience**

Involve your reader with early drafts of your document. And get their feedback.

**Be a Listener**

> Listen to them

* Encourage people to talk by asking questions
* Ask them to restate the discussion in their own words

**Get back to people**

Always respond to emails and voicemails

#### Tip 12: It's both what you say and the way you say it

Effective communication make you become influential

**Documentation**

Documentation as a development process

#### Tip 13: Build documentation in, don't bolt it on

* Restrict non-API commenting to discussing why something is done, its purpose and goals
* Adding comments to modules

#### Online communication

* Proofread before you hit Send
* Check spelling
* Keep format simple and clear
* Keep quoting to a minimum
* If you don't want to say it to someone's face, don't say it online
* Check your list of recipients

#### Challenges

* Read "Mythical Man-Month" and "Peopleware: Productive projects and teams" in next 18 months
* "Dinosaur Brains: Dealing with all those impossible people at work"

## C2. A Pragmatic Approach

### Topic 8: The essence of good design

#### Good design is easier than change bad design

> ETC principle: Easier to change

* Decoupling
* Single responsibility
* Naming

**ETC is a value to help you make decision**

Ask yourself:
> Did the thing I just did make the overall system easier or harder to change?

when:

* Save a file
* Write a test
* Fix a bug

If you don't have a clue, do:

1. You can always fall back on "easy to change" path, try to make what you wrote replaceable
2. Develop instinct, leave a tag about the choices you have and gusses about change. When the code has to change, look back and give yourself a feedback

#### Challenges

* Think about coding paradigms (OO, FP, Reactive and so on), do they have big positives or big negatives when you comes to write ETC code? Do they have both?

* Get your editor to pop up the ETC? message every time you save

### Topic 9: DRY - The Eveils of Duplication

Maintenance is a routine part of the entire development process.

#### Tip 15: DRY - Don't Repeat Yourself

**Dry is more than code**

> DRY is about the duplication of knowledge, of intent. It's about expressing the same thing in two different places, possibly in two toatally different ways.

**Duplication in code**

Extract duplication to a function for reuse.

**Not all code duplication is knowledge duplication**

If the knowledge present different, it's ok to have same body in different function

**Dulplication in documentation**

Good naming and you won't need documentation in comments

**Dry violation in data**

* Localize the violation
* Always use accesstr function to read and write attributes of object

**Representational Duplication**

* External thing(Api, schema) and you app has different interface

**Duplication accross internal Apis**

* JsDoc

**Duplication accross external Apis**

* Use tool like OpenApi to generate documentation