How to Keep Learning and Grow as an Engineer While Working Full‑Time

Introduction

Ancient wisdom says "Live to old age, learn to old age." In the Internet industry, overtime is common and technology evolves rapidly, leaving many engineers exhausted and believing that 35 is the end of a programmer's career. This article summarizes personal insights on how to accumulate technical knowledge and build core competitiveness, organized into three parts.

First part explains learning principles; proven rules greatly affect efficiency.

Second part discusses common confusions that hinder work and learning.

Third part analyzes the architect competency model to clarify required abilities.

How to Learn

Continuous learning amid a busy schedule requires perseverance and the right methods. The following principles are essential:

Persist

Knowledge accumulates rapidly; engineers must accept that current expertise will soon become obsolete. Only relentless learning can keep one a good architect.

Foundations change slowly, so regular review of basic theory is necessary.

Practice

The "721" model suggests 70% of growth comes from on‑the‑job practice, 20% from learning from others, and 10% from formal training. Emphasizing practice leads to the greatest learning gains.

Both rational (reading) and sensory (hands‑on) cognition are needed; you cannot become a driver by only reading a car manual.

Communicate

Learning from mentors, leaders, peers, and even opponents is crucial. Engaging in design discussions provides richer understanding than solitary study.

Summarize & Share

Deep reflection on details turns quantity into quality. Writing articles, giving talks, or daily self‑review solidifies knowledge and benefits others.

Plan

Good planning is half the battle. Long‑term plans set direction; short‑term plans balance life, growth, performance, and promotion. A practical short‑term plan includes prioritizing goals, setting minimum thresholds, allocating resources, and ordering tasks by priority.

Common Confusions

Engineers often face dilemmas that feel like shackles. Below are typical ones and ways to resolve them.

Is Learning Endless?

Life is finite while knowledge is infinite. However, many core engineering fields have relatively shallow foundations that can be mastered within limited time.

Examples: basic number theory underpins cryptography; Paxos solves the classic consistency problem; mastering ABAC and RBAC addresses permission management.

No Absolute Superior Technology

Technical prowess is not about a single technology stack. Mastery of a framework does not make one a true expert; the ability to solve problems matters more.

Must Have Projects to Grow?

Project depth, not quantity, drives growth. Repeating shallow projects yields little learning. Use project gaps to deepen expertise.

Is a Small Role Meaningless?

Team size and responsibility do not directly correlate with technical growth. Focus on impactful projects and avoid being spread too thin.

Do You Need to Be the Technical Lead?

Being the top technical person in a weak team offers little value. Better to join stronger teams or ensure you have peers to explore new domains.

Platformization Myths

Platform projects are not fundamentally different from business projects; they still deliver customer value. Avoid treating platformization as a buzzword without clear ROI.

Is Basic Tech Always Superior?

Foundational technologies are mature but not necessarily more advanced than business‑level tech. Both have distinct focuses and challenges.

Feasibility Study Pitfalls

Common mistakes: turning feasibility studies into impossibility studies, over‑engineering, and spending excessive time without clear progress.

Are Engineers Poor Communicators?

Effective communication requires choosing reliable (TCP) vs. fast (UDP) modes, synchrony vs. asynchrony, and avoiding off‑topic discussions.

Leading People

Micromanaging stifles team growth. Trust, provide feedback, and give challenges at the right time.

Efficiency, Efficiency, Efficiency

Focus on efficiency over sheer effort. Do the right things, not just do things right.

Architect Competency Model

Becoming an excellent architect involves seven core abilities: programming, debugging, build‑and‑deploy, performance optimization, business architecture, online operations, and project/people management.

Programming Ability

Translating business requirements into code; mastering OOP and design patterns; code reviews accelerate growth.

Debugging Ability

Understanding runtime state to verify and optimize systems; essential for timely, high‑quality delivery.

Build & Deploy Ability

Compiling and deploying in production is a required step for modern SOA systems; junior engineers must master it.

Performance Optimization Ability

Involves data structures, OS, JVM, CPU, storage, network; requires holistic understanding of availability, reliability, scalability.

Online Operations Ability

Rapid detection, mitigation, and resolution of incidents; combines monitoring, escalation, and deep system knowledge.

Business Architecture Ability

Distinguish real vs. pseudo‑requirements, abstract business scenarios, and design cost‑effective solutions.

Project Management Ability

Handle large‑scale projects, cost control, risk management, and team coordination.

Team Management Ability

Planning, talent allocation, morale, communication, and principled decision‑making.

Conclusion

The author was invited to speak about "working while learning," collected rumors, clarified doubts, and drafted a personal architect competency model. The article systematically presents learning principles, analyzes common confusions, and sets clear learning goals to help engineers. The model reflects personal views; readers are encouraged to share their own experiences.

Source: Meituan‑Dianping Tech Blog URL: https://tech.meituan.com/study_vs_work.html