1. You should attempt to re-express your target’s position so clearly, vividly, and fairly that your target says, “Thanks, I wish I’d thought of putting it that way.”
2. You should list any points of agreement (especially if they are not matters of general or widespread agreement).
3. You should mention anything you have learned from your target.
4. Only then are you permitted to say so much as a word of rebuttal or criticism.

As I mentioned in my Review for Nonviolent Communication, NVC still feels a bit vague for me even after reading the book. Because I still don't know exactly how to apply NVC in my life.

Rapoport's Rules to Criticize, on the other hand, is such a practical steps to follow. And I can tell from my experience that it definitely works. Before learning Rapoport's Rules, I've been using similar techniques already: I always try to re-express what I received and what I agree before I say what I don't. And most of the time, people would accept my opinions better.

After learning Rapoport's Rules, I would re-express more and start mentioning what I've learned. Maybe you can do the same and see if it helps with your communication?

• A goal is something that goes away when you hit it.
  • Once you’ve reached it, it’s gone.
  • You could always set another one, but I just don’t function in steps like that.
• I just worked at whatever I was working on and ended up wherever I am.

As I learn to become goal-driven (a.k.a result-driven), I am also aware of the downside of goals: setting goals in itself doesn't mean anything, what really matters is execution.

Another interesting quote from this article is:

The reason that most of us are unhappy most of the time is that we set our goals not for the person we’re going to be when we reach them, but we set our goals for the person we are when we set them.

From my current understanding, it's impossible to "set our goals not for the person we’re going to be when we reach them". So shall we stop setting goals once and for all?

That being said, I still believe in the power of goals: what gets measured gets managed. What we need to do is to set goals for what really matters to us. Use a few goals to help us focus on things really matter. And learn the goal-setting skills from practices.

• Writing tests that scale with your team
  • Abstractions can be useful tools
  • Abstractions can also increase the cognitive load on the next person to work with your code
• Minimizing dependencies between tests
• Requirements change, abstractions break
• Writing untested logic
  • we shouldn’t spend time testing that language features work as expected
• Making the right abstractions
  • DRY test code should be a means to achieving the goals of your test suite, rather than a goal in and of itself.

When writing tests, we should strive for being DAMP (Descriptive And Meaningful Phrases), rather than DRY (Don't Repeat Yourself). It's way easier to build a Wrong Abstraction when writing tests. And it doesn't cost much to have duplicated code in our tests.

• Inheritance
  • When? Object Specialization
    • A child should be a specialized version of its parent
    • Not to share behaviour
  • Pros (when done correctly)
    • Reusable
    • Extensible
  • Cons
    • Coupling
    • Reduced Readability
    • Easy to Abuse
    • Complicates Unit Testing
      • subclasses are not fully tested
      • if someone changes superclass and its tests, tests would pass, but the behaviours of subclasses are changed
• Composition
  • When? As much as possible!
    • Small classes
    • Small methods
  • Pros
    • Flexible
    • Readable
    • Easily Testable
  • Cons
    • More boilerplate

I spent quite some time to understand "Composition over Inheritance". Because when I first started learning Object-Oriented Programming, it was one of the core concepts I learned. After reading many articles and books, I was convinced that Composition is actually better. This talk is the best resource you can learn about this idea.

If you want to learn more about "Composition over Inheritance", these are some great reads:

• Michael Feathers on Twitter: "Inheritance might be the most unjustly maligned language feature."
• Inheritance Is a Procedural Technique for Code Reuse
• How to avoid inheritance in Ruby? – Michał Konarski
• interfaces - Why should I prefer composition over inheritance? - Software Engineering Stack Exchange

• split your achitecture based on knowledge, not on data.
  • How a company structures knowledge depends entirely on the people and the business they are on
  • think in our business as a business platform:
    • we don't have a product, we have a set of products.
    • Those products are a set of features that apply to a persona.
• Summary
  • Thinking in platforms allows us to split our business better.
  • Linking products to personas and also to bounded contexts makes boundaries explicit.
  • State-sourcing and event-driven architectures are essential for building distributed and available platforms.
  • Teams should not share code, but a common platform.

How to design a architecture optimized for long-term evolution is the core of software design. This article provides a practical example to explain how to split domains based on knowledge, rather than data.