Meta

This chapter alone is SDE Mentoring 101. Many of my mentees through the years have struggled in these areas, and improvement is often following these principles, whether by design or by accident.

This is a “soft” skills chapter, yes. Later ones get much more technical. However, most tech ICs (and managers) don’t struggle with technology; we struggle learning these lessons ad-hoc, through experience.

– Harold, 08 January 2020

Foreward & Preface

They don’t talk down to you. They don’t assume you are an expert. … They take you as you are–programmers who just want to be better.

Ship of Theseus

What makes a Pragmatic Programmer

1. Early adopter/Fast Adapter You have an instinct for technologies and techniques, and you love trying things out
2. Inquisitive You tend to ask questions, and you’re a pack rat for little facts.
3. Critical Thinker You rarely take things as given without first getting the facts.
4. Realistic You try to understand the underlying nature of each problem you face.
5. Jack of all trades You try hard to be familiar with a broad range of technologies and environments.

Tip 1: Care About your Craft. We feel there is no point in developing software unless you care about it.

Thoughts? Can this be taken too far?

How is this similar and different from UncleBob’s Software Craftsmanship Manifesto?

Is this similar or different to other professions, from your experience?

Tip 2: Think! About your work. Never be on autopilot. Constantly be thinking, critiquing your work in Realtime.

Anybody have an example where you recently stopped, self-critiqued, and changed/improved what you were doing?

(Stated) Rewards (p. xxi)

1. More active involvement in a job you love.
2. Feeling of master over ranges of subjects
3. Pleasing feeling of continuous improvement
4. Teams become more efficient
5. Write code that’s easier to maintain
6. Spend less time in meetings

(you had me at ‘Less time in Meetings’ - HC )

Individuals & Large teams

“Software is an engineering discipline that breaks down if individual(s)…make decisions for themselves.” Agree or Disagree?

There should be engineering in software construction. However, this doesn’t preclude individual craftsmanship. (p. xxii)

Chapter 1: A Pragmatic Philosophy

It’s Your Life

Many developers we talk to are frustrated….Our answer is always the same: “Why can’t you change it?” (p.2)

Tip 3: You Have Agency (p.2)

Why do they say this is the most important tip in the book?

The Cat Ate My Source Code

What are some “disasters” you can think of? How does this go to Earning (or Losing) trust?

Trust in a team is absolutely essential for creativity and collaboration

Agree? Disagree? Examples?

Tip 4: Provide Options, Don’t Make Lame Excuses

• The Vendor didn’t come through
• The datacenter went drop
• Your drive crashed

Always listen for the word “can’t”

Before you approach anyone to tell them why something can’t be done, is late, is broken, stop and listen to yourself.

Q: What is “Rubber Ducking”? Have you done it?

Q: What does providing options look like?

Q: How does this align (or not) with how we do things @ Amazon?

Application (p.5)

• Tell about a time in life when someone came to you with a lame excuse. What was your opinion of that person?
• Follow “I don’t know” with “, but I’ll find out.” This is a great way to admit what you don’t know, but take responsibility.

Software Entropy

• Software Rot
• Technical Debt

Hopelessness can be contagious (p.6)

Tip 5: Don’t Live with Broken Windows

Q: What is the broken windows theory and how does it (or doesn’t it?) apply to your team and Amazon?

Strategies

• Fix each ‘broken window’ as soon as discovered
• “Board it up”
• “Do No Harm”: Don’t break the rest of the software in fixing a “crisis”

Application

• Choose two or three “broken windows” and discuss what you can do about them?
• Think about root causes for “broken windows”: ignorance, deadlines, laziness. Be honest. Consider what proactive steps you can make under those circumstances

Stone Soup and Boiled Frogs

Q: What is the moral of the ‘Stone Soup’ story?

Is this (or not) a template for effecting change? Anyone have an example?

Tip 6: Be a Catalyst for Change.

“It is easier to ask forgiveness than permission” – Grace Hopper

Q: What is the point of the Boiled Frog?

Some examples:

• Scope creep
• Schedule slippage
• Decisions postponed
• No Ownership
• Fear

Tip 7: Remember the Big Picture

Application

• How aware are you of your surroundings? How many people are in this room? Do you even care? Is the door open or closed? Is anything out-of-place? Take time to be aware both of your surroundings and your project. How can you do this?
• What procedures/metrics do you have in place to detect “Boiled Frogs” syndrome?
• Is the Second System Effect an instance of Boiled frog? How are they alike and different?

Good Enough software

The real world just won’t let us produce much that’s truly perfect. (p.11)

Perfect code never ships – Software Advantages

“Do you ever ask your users how good they want the software to be?” (p.11-12)

Constraints:

• marketing promises
• delivery schedule
• on-shelf DateTime
• cash-flow constraints

“I know you needed this code last week for the rocket launch, but I insist I had to rewrite all 50,000 lines in Rust.”

Tip 8: Make Quality a Requirements issue

Application

• Define “Minimum Viable Product” (though I guess we hate that term now)
• Give users something to play with early, then let their feedback lead you better solutions
• Know when to stop

Q: Why is stopping hard? Or is it easy for you?

Q: How does this vary in embedded software, webapps, mobile. What effect does modularization or microservices have on this?

Q: What Software is so bloated it’s almost unusuable (ECLIPSE!)

Q: How do you deal with the ‘Have you thought about?’ question from Senior SDE, PE reviews? Have you ever put explicit “constraints”/“won’t do” sections in your designs? Why or why not?

Your Knowledge Portfolio

Tip 9: Invest Regularly in your Knowledge Portfolio

application

1. Invest Regularly
2. Diversify
3. Manage risk
4. Buy low, sell high
5. Review and Rebalance

Strategies

1. Learn a new programming language every year
2. Read a technical book each month
3. Read non-tech books
4. Take Subclasses
5. Participate in groups/meetups
6. Experiment with different environments
7. Stay current

Critical Thinking

Tip 10: Critically analyze what you Read and Hear

1. Ask the “Five Whys”
2. Who does this benefit?
3. What’s the context?
4. When or where would this work?
5. Why is this a problem?

Application

Candidate Languages: Clojure, Elixir, Elm, F#, Go,Haskell, Python, Rust, Scala, Swift, TypeScript

Communicate

A large part of our day is spent communicating, so we need to do it well.

Tip 11: English is Just Another Programming Language

Application

1. Know your audience You’re communicating only if you’re conveying what you mean to convey.
2. Know what you want to say
3. Choose your moment
4. Choose a style
5. Make it look good
6. Involve your Audience
7. Be a Listener. Turn a meeting into a dialog
8. Keep your promises to get back to people

Tip 12: It’s both What you say and the Way you say it

Documentation

Tip 13: Build Documentation in, don’t bolt it on (p.23)

Q: How has “documentation” changed in our industry? Is there more or less than when you started?