How to Become a Technical Expert: Deliberate Practice, Pattern Finding, and Continuous Learning

Caolé, a Tsinghua graduate and head of Didi's ride‑hailing technology department, writes a letter to help engineers broaden their perspective beyond pure technical views, emphasizing how to become a technical leader.

Many engineers feel anxious about growth, lack of time for learning, and fear of a "35‑year crisis"; the article argues that such anxiety is normal and can drive deeper commitment to coding and study.

The root of the so‑called crisis is complacency after a few years of work; truly valuable talent remains scarce, and continuous skill improvement keeps engineers in demand at any age.

Effective learning follows a deliberate‑practice framework: (1) identify the domain's patterns, (2) repeatedly practice each pattern, and (3) obtain timely feedback.

Examples from high‑school exam preparation and badminton illustrate how breaking a skill into components, practicing them deliberately, and seeking feedback lead to rapid improvement.

When entering a new field, first build a knowledge framework by reviewing surveys, seminal papers, or textbook tables of contents, then dive deep into each topic, and finally map the knowledge to real‑world work for feedback.

A personal case study of learning distributed storage shows how the author listed required topics, gathered materials, studied consistency theories (CAP, Paxos, Raft), and compared systems (GFS, Dynamo, Aurora, OceanBase, Ceph, Spanner) while constantly iterating his understanding.

The learning cycle is iterative: practice, receive feedback, discover missing knowledge, and refine the framework, preventing superficial understanding.

Work should not be separated from learning; practical experience provides higher "knowledge density" than books, and deep mastery of one domain enables easier cross‑domain migration.

Improving coding ability requires regular self‑review and studying high‑quality code (e.g., open‑source projects like Boost), while enhancing troubleshooting involves thorough post‑mortems of incidents to uncover root causes and prevent recurrence.

Architects need a complete technical knowledge system, systematic thinking, and deep business insight to avoid over‑design; studying other companies' architectures (e.g., Amazon, Google) helps build this perspective.

Ultimately, continuous curiosity, problem‑driven learning, and systematic knowledge integration—what the author calls "thinking in action"—are the keys to becoming a technical heavyweight.