Ten Principles for Engineers to Enhance Work and Learning

Yesterday I came across a technical article by Meituan employee Yunpeng, who joined the company in 2014 and has contributed to the hotel supply‑chain system and distributed scheduling platform. He grew from a fresh graduate to a technical leader and now shares ten improvement principles for engineers.

The article is long—over 8,000 Chinese characters—but it is concise and worth reading thoroughly.

Eight years ago, my first internship was as a C++ engineer in a wireless search department. My first deployment caused a major incident: I mistakenly pushed a wrong configuration from SVN to production, leading to a 20‑minute outage affecting millions of users.

During the following six months I made almost every mistake a newcomer could make: wasted weeks on research without results, missed deadlines due to personal commitments, and passive participation in project meetings.

After eight years I have become a technical leader, yet I see many teammates repeating the same errors. The root cause is a lack of guiding principles. Principles act like a lighthouse, linking values to actions.

1. Principle One: Owner Mindset

"Owner mindset" consists of two aspects: 一是认真负责的态度, and 二是积极主动的精神.

Responsibility is the baseline. Every design document, every line of code must be completed carefully and its quality owned. Poor documentation, missing comments, or buggy code harms not only the developer but also QA, PM, and other collaborators.

Ownership also means caring for the system: architecture, interface docs, logs, database capacity, cache, etc. A true system owner fulfills these responsibilities.

Proactivity is a higher level of owner mindset. Engineers face many unplanned tasks daily; they must respond actively, for example by promptly addressing technical inquiries from customers.

Many colleagues ignore or postpone such issues, leading to poor customer experience. The correct approach is to push solutions forward, or at least forward the problem to the right person.

Proactivity also appears in self‑driven service health reviews, cross‑team communication, and taking initiative to improve processes.

2. Principle Two: Time Awareness

In the fast‑moving internet industry, delivery timeliness reflects a developer’s efficiency and reliability.

Those who deliver on schedule share two traits: 做事有计划，工作分主次 and 工作安排要有计划性. After design review, developers should estimate development time accurately and arrange development, integration, and testing accordingly.

Planning should be granular—down to the smallest task (pd granularity). Fine granularity reduces the gap between estimated and actual time.

Key deliverables must be defined and checkpoints set for verification. Misaligned expectations (e.g., backend promises a Friday delivery while frontend assumes Friday morning) cause avoidable delays.

Prioritization can follow the Eisenhower matrix: urgent‑important first, important‑not‑urgent later, delegate urgent‑not‑important, and drop not‑urgent‑not‑important.

3. Principle Three: Begin With The End In Mind

Stephen Covey’s habit means: 先想清楚目标，然后努力实现. In work, many engineers focus on execution without a clear goal, making it hard to assess the impact of their projects.

For performance‑optimisation projects, set concrete targets (e.g., TP99 < 200 ms, QPS > 10k) before starting. Optimisation should solve a specific problem, not just improve metrics for their own sake.

The same mindset applies to learning: define what you want to master (e.g., Redis persistence, master‑slave sync, or Redis‑Cluster architecture) before gathering resources.

4. Principle Four: Closed‑Loop Thinking

Repeatedly revisiting the same issues in design or requirement reviews indicates a lack of closure. Every assigned task must have a clear outcome, a documented result, and feedback within a defined timeframe.

For cross‑team meetings, ensure meeting minutes are verified, action items are tracked, and progress is checked. Without this, teams fall into a loop of “communicate‑discover‑communicate‑discover”.

True closure requires that every work item has a conclusion, a notification, and a verification.

Regularly report progress, even with a brief update, to build trust with leaders.

5. Principle Five: Keep Reverence for Standards

Respect for standards—code style, design guidelines, deployment procedures—prevents repeated mistakes. New team members should quickly learn and follow existing conventions.

Ignoring standards leads to unnecessary rework during code reviews or deployment failures. When uncertain, ask colleagues rather than rely on personal intuition.

Standards should evolve: if a rule feels outdated, discuss it with the team and update accordingly.

6. Principle Six: No More Than Two Iterations

All reviews and problem discussions should not exceed two rounds. Excessive iterations waste developer and PM time.

If a requirement or design cannot be approved after two reviews, it should be turned into a case study for deeper analysis.

After each incident, conduct a 5‑Why analysis and create an actionable To‑Do list to avoid repeating the same error.

7. Principle Seven: Design First

Good architecture reduces long‑term maintenance cost. Projects longer than three days should have a design document; those longer than five days require a design review.

Effective design is clear, logical, and executable. Use a top‑down approach: start from high‑level requirements, abstract the problem, then detail each module.

Have senior engineers or PMs review the design and iterate based on feedback.

8. Principle Eight: Balance Output and Capacity (P/PC)

Output (the "golden egg") must be balanced with capacity (the "goose"). Over‑emphasizing output leads to burnout; neglecting output leads to stagnation.

For systems, continuous feature addition must be paired with architectural scalability and stability improvements.

For individuals, technical skill growth and personal well‑being are the capacity that enables sustainable output.

9. Principle Nine: Ask Good Questions

Being inquisitive starts with asking questions frequently. When you don’t understand something, ask; when you encounter differing opinions, ask politely.

Effective questioning requires critical thinking—evaluating evidence, reasoning, and underlying assumptions.

The Bohr theorem tells us that the best ideas emerge from debate.

In design or code reviews, never stay silent; raise issues to make the session valuable.

10. Principle Ten: Empty‑Cup Mindset

Maintain humility: "Full‑cup invites loss, empty‑cup receives benefit." Over‑confidence can turn into complacency, causing resistance to feedback and stagnation.

Regular self‑assessment, 360‑degree reviews, and learning from peers keep growth alive.

Even when you are strong in some areas, stay open to others’ suggestions and apply critical thinking to evaluate them.

Conclusion

The ten principles are grouped into three categories: personal work methods (Owner mindset, Time awareness, Begin with the end, Closed‑loop), team standards (Respect for standards, No more than two, Design first), and efficiency improvement (P/PC balance, Ask good questions, Empty‑cup mindset). Applying them can guide engineers and teams toward stronger performance and continuous growth.