Pragmatic Programmer - Book Notes

Pragmatic Programmer

Pragmatic Programmer Book

Pragmatic philosophy

• Your life it's your life
  • Craftsmanship
  • Early adopter
• Responsibility
  • Offer options
• Software Entropy
  • Simplicity
  • Maintenance
• Good enough software
  • Quality is a requirement
• Your knowledge portfolio:
  • Investment in knowledge always pays the best interest
  • Read nontechnical books
  • Read conceptual books
  • Learn one new language every year
• Communicate
• Testability is key

Pragmatic approach

• The essence of good design: ETC
• DRY: Code, Data, Documentation (Knowledge)
  • Don't abstract too early, wait until you have copied and pasted a couple of times, examples are needed to create good abstractions
• Orthogonality:
  • Eliminate effects between unrelated things
  • Understandable, and easier to debug, test and maintain
  • Design patterns
  • SOLID
  • Prefer composition and FP languages
• Reversibility:
  • Flexible architecture
  • Have options
• Tracer bullets:
  • Code lean and complete
  • Find the target

• Prototypes and post-it notes:

  • Information gathering
  • Is coupling minimized
  • Collaborations between components well-defined
  • Responsibilities
  • Interfaces and data clear and available

• Domain languages:

  • Program close to the problem domain

• Estimation:

  • I'll back to you
  • optimistic, most likely, and pessimistic
  • model building: someone that already did it

Basic Tools

Be more productive with your tools

• The power of plain text:
  • Self-describing data
• Shell games
• Power Editing
• Debugging skills
  • localhost test
  • Explain to someone else
• Text manipulation
  • Unix: sed, awk
  • Scripting languages: Python
• Engineering daybooks

Pragmatic Paranoia

Validate all the information we're given, assertions of bad data, and distrust data from potential attackers

• Design by contract
  • Preconditions, postconditions: Clojure Specs
• Dead programs tell no lies
  • Crash early
  • Defensive programming is a waste of time let it crash! (Supervisor)
• Assertive programming
  • Use assertions to prevent the impossible
• How to balance resources
  • Release free resources
• Don't outrun your headlights
  • take small steps always

Bend or break

Make our code as flexible as possible, a good way to stay flexible it's to write less code

• Decoupling
  • Allow flexibility
  • Shy code that promotes cohesion
  • Law of Demeter: Depend on abstractions
  • Avoid global data
  • Avoid inheritance
• Juggling the real world
  • Events
  • Finite state machine
  • Observer
  • Publish/Subscribe (Channels)
  • Reactive Streams
• Transforming programming
  • Think in programs like Input Output and transformation of data
  • Process of data
  • find . -name '*.java' | xargs wc -l | sort -n | tail -11 | head -10
  • Programming is about code but programs are about data
• Inheritance tax
  • Coupling
  • Interfaces to express polymorphism
• Configuration
  • Parameterize your app using external configuration

Concurrency

• Concurrency: Two pieces of code run at the same time using Fibers, Threads, and process
• Parallelism: Hardware that can do two things at once
• Breaking temporal coupling
• Avoid shared state
• Actor and process
• Blackboards
  • Communication using Kafka or other streaming services

While you are coding

• Listen to your lizard brain
  • Give time and space to your brains to organize your ideas
• Algorithm speed
• Refactoring
  • Rethink
  • Gardening
  • Unit test
  • (Duplication, Not DRY, Bad performance, Outdated knowledge, Test passing. Nonorthogonal)
  • Redesign
  • Refactor early and often is like a surgery
• Test the code
  • Feedback
  • Improve design
  • Embrace TDD
• Property-based testing
• Security
  • Authentication
  • I/O data
  • Principle of least privilege
  • Up to date
  • Encrypt sensitive information
• Naming
  • In programming all the things have names and reveal the intent and belief of the system
  • Communication

 Before the project

• Requirements Pit
  • User doesn't know what he wants
  • Our job is to help businesses to understand what they want
  • Improve the feedback loop
  • BDUF is not a good thing
  • Work with the user to think like one
• Solving de puzzle
  • Think out of the box
  • Make time to think in the unfocused mode
• Working together
  • Pair programming
  • Mob programming
• Agile
  • It's about values, context, and feedback loop

Pragmatic Teams

• Pragmatic Teams
  • No broken windows
  • Be aware of the environment and health of the project
  • DRY
  • Small teams
  • Cross-functional teams Tracer bullets
  • Automation
  • Create and identity (Team name)
  • Schedule time to improve knowledge portfolio
• Context
  • Use the right tools and practices
  • Software delivery (When release flow is slow status meetings are high)
  • Kanban
• The programmer starter kit
  • Version control
  • Ruthless testing
    • Unit, Integration, Component, Performance
    • If modules don't work well as a unit, they won't work well as a system
    • Saboteurs: Chaos engineering
• Automate everything
  • Software delivery es fully automated
• Delight your users
  • What are your expectations
  • Deliver quality not code
• Pride and prejudice
  • Code that you feel proud
  • Collective ownership