Somewhere on the internet, Danny Ma published a simple algorithm for a happy life. It was written as pseudocode — a loop that runs while alive, with functions for family, health, gratitude, compassion, and the relentless pursuit of goals.
Then Sergey Zelvenskiy did a code review.
The review is brilliant not because it’s harsh, but because it applies the same rigor we use for software to something much harder: how we think about our own lives. Here is the original algorithm, the code review, and what every engineer can learn from the exchange.
The Original Algorithm
accomplishments = []
knowledge = []
goals = input("what do you want to achieve?")
while alive:
prioritize_family()
maintain_health()
show_gratitude()
have_compassion()
help_others()
try:
success = your_best(target=goals, luck=random())
accomplishments += success
knowledge += learn_from(success)
except: Exception as failure:
knowledge += learn_from(failure)
finally:
celebrate(accomplishments)
reassess(goals)
share(knowledge)
never_lose_hope()
else:
leave_legacy(accomplishments)
It is well-intentioned. The structure is optimistic — success is in the try block, failure is the exception, and the finally block ensures celebration and reflection regardless of outcome. But as the code review reveals, the assumptions need examination.
1. Goals are not set once at the start.
The original algorithm takes goals as input before the loop begins and never changes them. A reassess(goals) call exists in the finally block, but it has no effect on the goals variable — it’s a side effect at best.
The code review observation: “It’s incorrect to say that the goals are set before you are alive and never change.”
Goals evolve as you learn. What you wanted at twenty is not what you want at forty. The algorithm should treat goals as a living variable that gets updated inside the loop, informed by the accomplishments and knowledge accumulated in each iteration. A static goals variable is the source of the midlife crisis — the moment you realize you’ve been executing against an input you no longer believe in.
The engineering lesson: revisit your assumptions at the start of every iteration. The goal that made sense last quarter may not make sense this quarter. Code that never refactors its inputs becomes legacy. So do lives.
2. Success is the exception, not failure.
The original algorithm places success in the try block and failure in the except block. The code review flips this: “Assuming the goals are big enough, failure is not an exception. Success is typically an exception.”
This is the most incisive observation in the review. If your goal is ambitious enough, most attempts will fail. That is not an error condition — it is the expected path. The algorithm should treat failure as the normal case and success as the exceptional outcome that gets logged and analyzed.
The engineering lesson: if your error handling assumes failure is rare, you will design systems that handle failure poorly. The same applies to life. If you design your life assuming success is the normal case, you will be unprepared for the setbacks that are actually the normal case. Design for the expected path, not the optimistic one.
3. Celebration without new accomplishments is empty.
The finally block calls celebrate(accomplishments) regardless of whether the try block added anything. The code review notes: “If success did not happen, you will keep celebrating the same accomplishments over and over again.”
An empty check is needed. Celebration should only fire when there is something new to celebrate. Repeating the same accomplishments is not celebration — it is nostalgia. And sharing the same knowledge repeatedly is not teaching — it is repetition.
The engineering lesson: this is the pattern of teams that ship one feature and spend six months presenting it at every all-hands. Celebrate real progress. Do not let the ritual of celebration replace the substance of it. And when there is nothing new to share, the honest thing to do is say “we didn’t make progress this quarter” — not re-package the same accomplishment for a different audience.
4. Knowledge from success and knowledge from failure are different types.
The original algorithm treats all learning as the same — knowledge += learn_from(success) and knowledge += learn_from(failure) both append to the same array. The code review calls this out: “Knowledge learned from success is different from knowledge learned from failure. These need to be separated.”
Success teaches you what worked. Failure teaches you what didn’t. These are not interchangeable. Success can breed overconfidence. Failure can breed caution. If you store them in the same bucket, you lose the ability to reason about which lessons came from which context.
The engineering lesson: a postmortem that treats all outcomes the same is a wasted postmortem. Separate your learnings by type. Build a taxonomy. “What did we learn from the incident” and “what did we learn from the successful launch” are different questions that produce different answers. Treat them as such.
5. Knowledge is not an array — it is a graph.
The most elegant observation in the review: “Knowledge is not an array, it’s a graph.”
An array is linear. You add items to it, and you iterate over it in order. Knowledge does not work that way. New insights connect to old insights in unexpected ways. Learning about one domain illuminates another. The structure of knowledge is not sequential — it is networked.
The engineering lesson: this is why mentorship matters, why cross-functional exposure matters, why diverse experiences matter. A graph with more connections is more valuable than a graph with more nodes. The goal is not to accumulate facts. It is to build a dense network of understanding where each new piece connects to something already known.
What the Review Teaches About Code Review Itself
There is a meta-lesson here that is worth naming. Sergey Zelvenskiy took a piece of pseudocode written as a thought experiment and applied the same intellectual rigor to it that he would apply to a production system. He did not treat it as a joke or a curiosity. He treated it as something worth reviewing seriously.
That is the mindset of a great engineer. Great engineers review everything with the same standard, whether it is a critical infrastructure change or a whimsical happiness algorithm. They do not lower the bar because the context is informal. They hold the bar because the bar is who they are.
The best code reviews I have received were not the ones that caught the most bugs. They were the ones that questioned my assumptions. This review questions assumptions about goals, success, failure, celebration, learning, and the very structure of knowledge. That is the highest standard of review.
What I’ve Learned
Goals are living variables, not constants. Revisit them every iteration. The goal that made sense last quarter may not make sense this quarter — for your team, your career, or your life.
Design for the expected path, not the optimistic one. If your goal is ambitious, failure is the normal case. Treat it as such. Build systems that handle the expected path gracefully and treat success as the exceptional outcome to learn from.
Celebrate only when there is something new to celebrate. Ritual without substance is noise. Empty celebration trains teams to perform the motion without the meaning. If nothing new was accomplished, the honest thing is to say so.
Separate learnings by type. Success lessons and failure lessons are different data types. Store them separately. Analyze them differently. Apply them appropriately.
Knowledge is a graph, not an array. Build connections, not just accumulation. The most valuable learning happens at the intersection of domains. Invest in breadth as well as depth.