Deividy'

Pragmatic Philosophy

This is my study book of Pragmatic Programmer (The Bible).

Remember the big picture!

Critical Thinker

  • Think! About your work!
  • Remember the big picture, always!
  • Dont live with broken windows, never!
  • Make quality a requirement issue
  • Provide options, dont make lame excuses
  • Invest regularly in your knowledge portfolio
  • Care about your craft
  • Listen to Nagging Doubts - Start when you’re ready! (only when you’re ready!)
  • Critically analyze what you read and hear
  • Be a catalyst for change
  • An Object should do only one work, and do your work as well
  • Eliminate Effects Between Unrelated Things
  • There are no Final decisions
  • Use Tracer Bullets to Find the target (Seek and destroy!)
  • Protoype to learn
  • Program Close to the Problem domain
  • Estimate to avoid surprises
  • Iterate the schedule with the code
  • Keep knowledge in plain text
  • Use the power of shell script (oh i got the power!)
  • Use a single editor well
  • Fix the problem, not the blame
  • Dont panic! x)
  • select isnt broken!
  • Dont assume it - PROVE IT!
  • Learn a Text Manipulation Language
  • Write Code That writes code (sounds awesome)
  • You cant write perfect software
  • Design with Contracts
  • Code defensively
  • Crash Early
  • If it cant happen, use assertions to ensure that it wont.
  • Use Exceptions for Exceptional Problems
  • Finish what you start!
  • Minimize Coupling between modules
  • Configure, Dont Integrate
  • Put abstractions in Code Details in Metadata
  • Analyze workflow to improve concurrency
  • Design using services
  • Always design for concurrency
  • Separate views from models (obvious)
  • Use Blackboards to Coordinate Workflow
  • Don’t code like an idiot, understand what you’re writing
  • Constantly look for room for improvement and design
  • Don’t Program by Coincidence
  • Estimate the order of your Algorithms
  • Always test your estimates
  • Design to test
  • Test your software, or your users will (worst!)
  • Dont use wizard code you dont understand
  • Dont gather Requirements - Dig for them!
  • Work with a user to think like a user
  • Abstractions live longer than details
  • Use a project glossary
  • Maybe it looks imposibble. But is it really as hard as it seems?
  • “Seeing further”
  • Dont think outside the box - Find the box
  • Some things are better done than described
  • Dont be a slave to formal methods
  • Expensive too do not produce better designs
  • Organize around functionality, not job functions
  • Dont use manual procedures
  • Test early, test often, test automatically!
  • Find your own bugs, dont let the others find for you!
  • Coding aint done til all the tests run!
  • Use saboteurs to test your testing
  • Test state coverage, not code coverage
  • Find bugs once
  • Treat English as just another programming language
  • Build documentation in, don’t bolt it on
  • Gently exceed your users’ expectations
  • Sign Your Work
read more