The Pragmatic Programmer: From Journeyman to Master

Preface (Chapter 1)

Welcome to Iteration: a weekly podcast about programing, development and design through the lens of amazing books, chapter-by-chapter

NEW BOOK Pragmatic Programmer

by Andy Hunt and Dave Thomas

This book will help you become a better programmer

• this book was written in freaking 1999! I was 7.

• programming is a craft

• "as a programmer, you are part listener, part advisor, part interpreter, and part dictator. you try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice. you try to document your work so that others can understand it, and you try to engineer your work so that others can build on it. What's more, you try to do all this against the relentless ticking of the project clock. you work small miracle every day"

• "you shouldn't be welded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations"

What makes a pragmatic programmer

1. early adopter / fast adapter
2. inquisitive - you ask questions
3. critical thinker
4. realistic
5. jack of all trades

Tips

Tip 1: Care about your craft

"We who cut mere stones must always be envisioning cathedrals."

Tip 2: Think about your work - never run on auto pilot

"great lawns need small amounts of daily care, and so do great programmers."

"1% better every day. 365% bettere every year"

• kaizen - continuous small improvements

Tip 3: Provide Options, Don't make lame excuses

• basically, take responsibility
• when something can't be done, explain what can be done to salvage the situation

Challenge

• How do you react when someone - such as a bank teller, a mechanic, or a clerk - comes to you with a lame excuse. What do you think of them and their company as a result?

hmmmmm.... really gets you thinking

Tip 4: don't leave broken windows

Software entropy - aka Broken window theory - aka software rot

This is a great metaphor:

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment - ... so another window gets broken. People start littering. graffiti appears.

• police in NY and other major cities have cracked (no put intended) down on small stuff in order to keep out the big stuff.
• systems rot quickly with one broken window. wow. this cuts me deep. haha.
• don't let entropy win!!!
• in the opposite case, where there are no broken windows - and its extremely pristine - you don't want to be THAT guy that makes a mess.

Tip 5: Be a catalyst for change (gradual deception and you can get what you want haha)

"The three soldiers returning home from war were hungry. When they saw the village ahead their spirits lifted—they were sure the villagers would give them a meal. But when they got there, they found the doors locked and the windows closed. After many years of war, the villagers were short of food, and hoarded what they had. Undeterred, the soldiers boiled a pot of water and carefully placed three stones into it. The amazed villagers came out to watch. "This is stone soup," the soldiers explained.

"Is that all you put in it?" asked the villagers. "Absolutely—although some say it tastes even better with a few carrots...." A villager ran off, returning in no time with a basket of carrots from his hoard. A couple of minutes later, the villagers again asked "Is that it?" "Well," said the soldiers, "a couple of potatoes give it body." Off ran another villager."

Tip 6: Remember the big picture

(don't be the frog who gets boiled gradually)

Tip 7: Make quality a requirements issue

There will always be tradeoffs. When to ship?

Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution.

Challenges

1. look at some software you use. can you find evidence that companies are comfortable shipping software they know is not perfect. as a user, would you rather wait for them to iron out all of the bugs? have complex software and accept some bugs? opt for simpler software and have fewer defects?

Tip 8: Invest regularly in your knowledge portfolio

• knowledge is an expiring asset
• it becomes out of date as new techniques, languages, and environments are developed
• JP's pick: https://www.youtube.com/watch?v=ZZUY37RQS-k - "Staying relevant as a programmer"

1. invest regularly
2. diversify
3. balance portfolio regularly between high risk, high reward investments
4. buy low and sell high
5. reviewed and rebalanced periodically

• the same can be said for your KNOWLEDGE portfolio
• Diversify: "The more technologies you are comfortable with, the better you will be able to adjust to change"

GOALS - I LOVE this section.

1. learn at least one new language every year. Different languages solve the same problem in different ways.
2. read a technical book each quarter. after you've mastered the technologies you're currently using, branch out and study some that DONT relate to your project
3. read non technical books
4. take classes
5. participate in local user groups (meetups)
6. experiment with different environments (windows, linux)
7. stay current
8. get wired (twitter - follow big players in the space)

It doesn't matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things.

Tip 9: Critically Analyze What you read and hear

Don't get swayed by media hype. I'm looking at you create-react-app!

• i was at JS.la and mentioned how create-react-app is the best configuration free react setup. someone challenged me and said it's just the best marketed

Tip 10: It's Both What you Say and the way you say it

Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication

• kind of way we're doing this podcast!
• know your audience
• understand the needs and interests of your audience
• think about all the people and stakeholders and domain experts you have to communicate with as a software engineer
• very much, "How to win friends and influence people"

1. know what to Say
2. know your audience
3. choose your moment - not 4pm on a friday or when your boss is having a bad day
4. choose a style - know how to deliver your message
5. make it look good (make it pop). think about how sexy laravel docs are
6. involve your audience
7. be a listener
8. get back to people. ALWAYS respond back to emails. think about how it feels when people don't reespond back to you. even just a "Ill get back to you later" response is better than no response

these are great soft skills!

Episode source