Learning in publicالتعلّم أمام الجمهور

Learning in public is publishing what you understand while you are still learning it, so that people who know more can correct you. In finance it is both more useful and more dangerous, because a mistake here can touch customers or breach a contract.

Weak understanding appears when you explain a financial decision to someone able to challenge it.

Why publish when I have not mastered it yet?

This objection stops most people, and it rests on a misunderstanding of what publishing is for.

You think of it as announcing expertise. It is actually a tool for discovering ignorance.

Try this now: explain in one paragraph the difference between clearing and settlement, without returning to this page. You will probably find you hold the general idea and stumble on the detail you thought you had understood.

That moment is the entire value. Reading gives you a feeling of understanding because the words are already arranged in front of you. Writing reveals that the arrangement was the writer's and not yours.

So publishing as a beginner is not a pretence, on one condition: write as a learner rather than as an expert. "Today I understood why money does not move at the moment of approval" is honest and useful. "Let me explain payment systems to you", from a beginner, is a claim the first specialist will puncture.

There is a second practical benefit: free correction. Publish something incomplete and whoever knows will correct it. That is faster than discovering it yourself a year later, and far cheaper than discovering it in a job interview.

Publish one small unit

Do not promise a book about FinTech. Choose one concept learned this week, such as reconciliation or idempotency. Explain one example, one common error, and one practical decision on a page.

Name the reader. Explain double-entry to an app developer or settlement to a merchant. A defined reader prevents unnecessary jargon.

Do not wait for perfect style. A correctable draft exposes gaps faster than private notes. Check numbers and sources, especially for regulatory claims.

Build a ledger with fake money

A project forces an idea to produce a result. Build a small program moving 1,000 halalas from a customer to a merchant. It must post two sides, reject imbalance, and calculate balances from movements.

Add deliberate failure. Send the same key twice, stop between debit and credit, and import a bank file missing one row. The system should prevent duplication, preserve balance, and expose the reconciliation difference.

Use synthetic data and a local server. The goal is to test the rule, not launch an unlicensed company.

Document why values are integers, entries are immutable, and timeouts produce unknown outcomes. Explanation proves the code is not accidental.

Read the primary source

News about a rule is not the final source. Regulators publish rules and consultations, then news and advisory firms summarise them. Each layer may remove a condition that changes meaning.

Start with the Saudi Central Bank or the regulator for the market being studied. Read scope, definitions, effective date, and addressed firms. A rule for banks does not automatically cover every finance app.

Separate consultation proposals from effective rules. Label a proposal and its date. When an update arrives, compare versions and identify what changed, who is affected, and when.

Use an original number

Central banks and payment schemes publish statistics on values, counts, and fraud. Instead of saying digital payments are growing, choose a table, calculate a change, and explain its limits.

Payment value may rise because prices rose, not because users doubled. Count may rise through many small transactions. Read unit, period, and coverage before telling a story.

Publish the query or calculation where possible. Link the public file, download date, and cleaning steps so another reader can reproduce it.

Ask for a specific correction

Do not ask only for general thoughts. Ask whether the design handles duplicate webhooks or whether settlement timing is correct. Specific questions attract specific expertise.

Thank the person, then check the source. Do not change text merely because a commenter sounds confident, and do not defend an error for appearance. Add a visible dated correction.

Public learning is not legal advice. Where application varies by licence or country, state that and cite the source.

Protect people and employers

Never publish customer data, internal dashboards, or API keys. Even redacted names can leave revealing amounts and times. Use synthetic examples or public data.

Do not describe an active workplace incident without explicit approval. It may harm investigation, breach a contract, or reveal a weakness. General lessons can be shared later after review.

Separate personal analysis from employer policy. Do not use a company logo to imply authority you were not given.

Build a learning loop

Choose a sustainable rhythm, perhaps one explanation each week and one project each month. Let pieces build: entries, idempotency, reconciliation, then one payment incident combining all three.

Keep unanswered questions as the next reading list. A correction about a race condition becomes a test. A correction about regulatory scope sends you back to the original definition.

Do not measure only likes. Ask whether a reader reproduced the example, whether a useful correction arrived, whether the project improved, and whether you can explain it in an interview.

Grow toward useful contribution

After several pieces, organise them into a small guide or repository. Remove repetition, update links, and date every rule. Do not let obsolete posts look current.

Contribute a precise question or runnable example to a professional community. Operational experts often reveal details absent from courses.

Learning continues when consumption becomes production and review. Read a primary source, build an example, explain a decision, and invite correction. Each loop increases precision and leaves visible evidence for colleagues and employers.