Mastering Technical Communication: From RPC Basics to Feynman Learning

Ali Mei's reading notes discuss how communication, though seemingly simple, is challenging for technical staff; the article analyzes common inefficient communication patterns and proposes methods to improve clarity.

I. Inefficient Technical Communication Cases

1. Unclear problem description leads to low resolution efficiency.

Student A: "Senior, after the cloud architecture changed, the database cannot be planned." Student A: "The solution cannot be exported." Other classmates CDEF: "Other issues discussed, cluttering the context." Student A: "Database cannot be planned, reporting risk." Student B: "Please describe the problem clearly."

Student A's possible mindset: "It's a product issue, not my problem; I've already posted logs and screenshots; the responsible person should handle it."

Student B's possible mindset: "What is this problem? I'm busy, will deal later..."

Effective questioning example: "We have an issue where X occurs, we expect Y, but observed Z; logs suggest possible cause A. Our project is waiting online, urgent resolution needed."

II. Inefficient Solution Presentation

During an online technical sharing session, the presenter described a solution in abstract terms, making it hard for listeners to reuse.

Instructor C: "Our solution calls the apiserver for scheduling, which then queries metadata from the database and sends requests to business servers..." Student D: "I need to explain this to a client, but I need clearer wording."

Suggested improvement: use simple language and analogies to make the solution understandable for non‑technical audiences.

III. Core Decision Points Not Highlighted

When presenting a three‑data‑center architecture, the decision point was buried, leaving the client confused.

Solution: after the presentation, list the two candidate options, highlight advantages, and emphasize the decision point in bold.

Insufficient perspective taking – focusing only on one's own needs.

Using language the audience cannot understand.

IV. Solutions

Adopt perspective‑taking mindset: aim to solve problems together.

Apply the Feynman learning technique: explain concepts as if to a ten‑year‑old.

The Feynman method consists of four steps: choose a concept, teach it, identify gaps, and simplify with analogies.

V. Applying the Feynman Method to RPC and Service Registry

What is RPC?

Technical explanation: RPC (Remote Procedure Call) abstracts network details, allowing developers to invoke remote services as if they were local functions, achieving high cohesion and low coupling.

Plain example: three friends coordinate a parcel pickup; one calls another to pick up the package remotely, analogous to RPC.

What is a Service Registry?

Technical explanation: A registry provides high‑availability service registration and discovery, consisting of Client, SessionServer, DataServer, and MetaServer roles.

Plain example: a real‑estate agency acts as a service registry, connecting buyers (clients) and sellers (services) through offices (SessionServer), a database (DataServer), and a central system (MetaServer).

Key components:

Client – applications that register or discover services.

SessionServer – entry point that forwards registrations to DataServer.

DataServer – stores service metadata with high availability.

MetaServer – maintains cluster metadata and notifies changes.

Illustrations:

VI. Building Your Own Scenario Library

Maintain a personal glossary of high‑frequency terms.

Prepare everyday‑life analogies for each term.

Continuously take notes and update the library.

By translating technical jargon into relatable stories, engineers can communicate more effectively and deepen their own understanding.