• clean architecture
  • designing data intensive applications
  • design patterns: elements of reusable object-oriented software
  • refactoring: improving the design of existing code
  • code complete
  • the pragmatic programmer
  • clean code
  • the mythical man month
  • building secure and reliable systems
  • designing distributed systems
  • peopleware
  • an elegant puzzle: systems of engineering management
  • the pragmatic programmer notes
    • take responsibility for your work and actions - expect to be held accountable as a result - don't blame others if things go wrong
    • instead of excuses, provide options - explain what can be done to salvage the situation rather than saying something can't be done about it
    • one or two "broken windows" in the code is likely to lead to the mentality of "well the rest of this code is shit anyway, so who cares?" - try to avoid them and repair them or board them up as quickly as possible when they do happen to avoid entropy. if people perceive that no one else cares about quality, they'll stop caring too
    • people find it easier to join an ongoing success - build something small to start, and people will be more likely to join and continue the effort
    • it is equally unprofessional to promise impossible timelines and cut basic corners to meet a deadline
    • is this a good time to talk about...?
    • DRY principle - don't repeat yourself. every piece of knowledge must have a single, unambiguous, authoritative representation within a system. if you repeat info in multiple places, then it has to be updated in multiple places
    • debugging checklist
      • is the problem a direct result of the bug or a symptom?
      • try to explain this bug to a coworker
      • if suspect code passes tests, are the tests complete enough? can you run the tests with the data that caused the bug?
      • do the conditions that caused the bug exist anywhere else in the system?
      • challenge your assumptions of the system
    • write “shy”/“lazy” code - be strict in what you will accept before you begin and promise as little as possible in return. specify what the code doesn’t promise to deliver and what it does
    • crash early, at the site of the problem, rather than letting the problem propagate. ex: check for incorrect inputs and error out right away
      • a dead program usually does less damage than a crippled, broken one - crash early to catch things before they spiral (e.g writing invalid data generated from invalid inputs to a db, vs crashing at the invalid input)
    • minimize coupling - if one module gets compromised or needs to be changed, it can be swapped out relatively easily. (e.g swapping out one persistence layer for another, or one microservice for another)
feb 10 2022 ∞
mar 8 2023 +