How to Turn Invisible Dev Work into Self‑Service with the RQN Error‑Message Pattern

A module lead approached the author complaining that the team’s workload was overwhelming, largely due to many "invisible" tasks like answering integration‑test queries, responding to API questions, and handling production‑issue inquiries.

Error Message Design – RQN

The author points out that these activities add little value because they could be automated. To address this, a structured error‑message format called RQN is introduced, where each letter represents a part of the message:

R – Reason : the cause of the error.

Q – Question : a clear description of the problem.

N – Next step : guidance on how to resolve it.

For example: "Because the financing discount information for the customer was not found, the discount calculation failed; please check or maintain the financing discount rate on the business platform." This self‑descriptive message eliminates the need for repetitive manual replies.

Supporting Solution

When a function involves multiple or asynchronous interfaces and cannot provide a specific error reason, the author suggests exposing a complementary operational interface. For instance, function A may call a query service B that aggregates possible error messages and data from several systems. If an error occurs in A, the front‑end automatically invokes B and presents the combined information to the user or business staff.

This approach enables a "self‑operating" effect, significantly reducing developers’ manual effort. It aligns with the programmer’s virtue of laziness: continuously simplifying work by checking whether the provided services can be made self‑service.