Please enable JavaScript.

Coggle requires JavaScript to display documents.

The Pragmatic Programmer pragmatic_programmer (Pragmatic Philosophy…

- - - - Changes are localised
      - Promotes reuse
      - Components are less fragile
      - Makes it easier to unit test
      - Help to not rely on, what you don't control
    - - Write shy code
        
        Minimum interface
        
        Minimum dependencies
      - Avoid global data
        
        Use dependency injection
        
        Avoid singletons
      - Stay DRY
      - KISS
      - Build in layers
    - - Components/layer that independent from each other
      - Design approach
  - - - Ability to change
      - Loosely kept dependencies
    - - Layers
        
        Decoupled components
        
        Good encapsulation
      - Metadata
        
        Download config
        
        Xcode targets
      - Use an interface
        
        Hide details behind it
        
        Strong layers
    - - Dependencies changes
      - 3rd parties go out of business
  - - - Design/Development approach
    - - Build small but functional components
      - Seek continuous feedback from stakeholders
      - Iterate fast
    - - Build with the same environment as production
      - Build with the same constraints as production
      - Figure out what the system should be by building not spec'ing
      - Better feel for what progress is being made
  - - - Answer(s) to a specific question
      - Learn
      - Try out competing ideas
    - - Ignore aspects of implementation
        
        Correctness
        
        Completeness
        
        Robustness
        
        Style/Presentation
      - Know what you want answered
    - - Set expectations
      - Know your boss
      - Iterate what it is throughout
- - - - Checking that assumptions are true
      - Fail fast approach
      - Confirmation of beliefs
    - - Add assets/preconditions
      - Should be additional code that doesn't affect the logic of the app
  - - - Error handling
      - Unexpected events
    - - Use to handle exceptional circumstances only
      - Don't use for expected states
    - - Cleaner code
      - Avoid pyramid of doom
  - - - Favour crashing over trashing
    - - fatalError
  - - - What allocates it is responsible for deallocating
      - Avoid putting shared resources into global state
      - Use dependency injection to share resources
      - Don't forget about exceptions
      - Create a wrapper around a resource
    - - Don't waste resources
      - Help to avoid deadlock
- - - - Easier to make changes
      - Bug avoidance
        
        Switch off broken code paths
        
        Feature flags
      - Creates a more flexible arch
      - Customise without recompiling
    - - Config file
        
        Abstract away details that change often
        
        Plain text
        
        Use a domain specific language
    - - Use it to control the flow of an app
      - Ship it with the app
      - Retrieve it via the API
- - - - Programming without knowing why it's working
      - "Lucky" programming
      - Depending on undocumented behaviour
    - - Be aware of what you are programming
        
        Ask why?
        
        Read documentation
      - Understand the requirements
      - Plan
      - Don't depend on undocumented behaviour
      - Document any assumptions
      - Don't be afraid to refactor
  - - - Rethinking previous decisions
      - Adapting to new(er) changes in tools
      - Rewiring
    - - Programming is like gardening
        
        Classes grow
        
        Conditions changes
        
        Routines need pruned
    - - Duplication
      - Tightly coupled components
      - Create independent layers
      - Learn more about the subject
      - Improve performance
    - - Piece by piece
      - Write tests
      - Small steps
      - Have a plan
  - - - Confidence
      - Design aid
      - Protect against regressions
    - - Contract testing
        
        Favour white box over black box
        
        Inputs and outputs
      - Check boundaries
      - Test happy and unhappy paths
      - Create a regression suite
    - - Always
      - Through CI
  - - - Code generation tools
      - Boilerplate
      - Not to same as 3rd party libraries
    - - Introduce code that you don't understand
- - - - For those who come after
        
        Good names make it easier to understand what is happening
        
        Write once, read multiple times
      - Re-enforce understanding
      - Just a different view to the code on the same ideas
    - - Discuss why something is done
        
        Code will describe how
        
        Details decisions and reasoning
      - Inline
      - Around the same time as coding
      - Only document that which can not be generated via tools
- - - - Gradual decline of quality in a codebase
      - Culture of the team
      - Poor standards in quality
      - Rot
      - Belief that no-one cares
    - - Easier to maintain a standard than achieve it
      - Infectious
    - - Broken windows
      - Treat resolving tech debt as important
      - Discuss and prioritise rot removal
      - Even be careful when putting out "fires"
  - - - Accountability
      - Empowerment
      - You work on it, might as well own it
    - - Assess risk
      - State your opinion
  - - - Others short-sightedness
      - Time pressures
      - Poor communication skills
      - Resource scarcity
    - - Small steps
      - Show success
      - Don't be afraid to just do it
      - Start with what you control
      - Communicate from their POV
  - - - Realism
        
        Understanding there is no perfect system
        
        Users don't care about the code
        
        Software is only useful if the user is using it
      - Shipping to user as soon as it's useful
    - - Release small/release often
      - Seek stakeholder feedback
  - - - Companies are buying your knowledge
      - Enjoyment
      - Technology changes so fast
    - - Invest regularly
        
        Passive
        
        Newsletters
        
        Videos
        
        Books
        
        Active
        
        Blog
        
        Experimenting
      - Manage risk
        
        Diversify
        
        Look for trends
        
        Solidify existing knowledge
      - Learning opportunities
        
        Don't just do the minimum
        
        Explore gaps in your knowledge
        
        Park the ego
      - Always have
        something to read
        
        Little and often
      - Judge what you read/hear
        
        Never just trust
        
        Think
  - - - We are knowledge workers
      - Multiple ways to do anything
    - - Know what you want to say
      - Know your audience
      - Choose the right moment
      - Involve the audience
      - Listen to other's concerns
      - Follow up