I haven’t read the book, The Four Agreements, but I will eventually. However, simply knowing what the Four Agreements are has been tremendously helpful for me. They may help you, too. I want to write them down to share, but also to remember them better and have a reference to revisit in the future.
You and your relationships — personal and professional — will benefit from practicing these rules. There’s a lot of wisdom in them. Embracing them is empowering. Following them, though sometimes challenging, will yield a better version of yourself, reduce suffering, and bring more joy to your relationships with others.
1. Be impeccable with your word.
Speak with integrity. Say only what you mean. Avoid using the word to speak against yourself or to gossip about others. Use the power of your word in the direction of truth and love.
2. Don’t take anything personally.
Find the courage to ask questions and to express what you really want. Communicate with others as clearly as you can to avoid misunderstandings, sadness, and drama. With just this one agreement, you can completely transform your life.
3. Don’t make assumptions.
Nothing others do is because of you. What others say and do is a projection of their own reality, their own dream. When you are immune to the opinions and actions of others, you won’t be the victim of needless suffering.
4. Always do your best.
Your best is going to change from moment to moment; it will be different when you are healthy as opposed to sick. Under any circumstance, simply do your best, and you will avoid self-judgment, self-abuse, and regret.
* * *
When it comes to programming, these agreements form a great approach to how we should write code and give code reviews. I think they are appropriate as written, but we can add a few tweaks.
1. Be impeccable with your word.
Write code clearly and concisely. Prioritize understanding over cleverness.
2. Don’t take anything personally.
Review the code, not the author. When your code is criticized, remember that you are not your code.
3. Don’t make assumptions.
Don’t assume “it will just work” now or that it won’t break later. Don’t assume anyone on your team (including yourself) will understand your code in six months. Write your tests.
4. Always do your best.
No one writes bugs on purpose. Do your best, and learn from your mistakes.