The original poster has the basics of schematic reading down — they know the symbols and can trace a layout — but they're asking the question that separates hobbyist scribbles from documents an engineer can hand to a colleague five years later: how do you draw schematics properly and professionally? They specifically ask about international standards, where to learn, and the unwritten rules.

The thread is a goldmine because experienced engineers chime in with the conventions that nobody formally teaches you. A few of the highest-signal points that surface:

• Signal flow goes left-to-right, power top-to-bottom. Inputs on the left, outputs on the right, positive rails up, ground down. Violating this makes schematics feel "wrong" even to readers who can't articulate why.
• Standards exist: IEEE 315 and IEC 60617 define symbols; IPC-2612 covers schematic documentation practice. ANSI/IEEE conventions dominate in the US; IEC symbols in Europe and most of the rest of the world. Mixing them in one drawing is a tell of an amateur.
• Don't route signals through pins. Pins of a component shouldn't have wires crossing through them; bring traces to the pin and stop. Net labels beat long wandering wires — once a schematic crosses a page boundary or has more than a couple of crossings, labels are clearer than lines.
• No four-way junctions. Always offset T-junctions so a dot is unambiguous. A missed dot at a four-way crossing is one of the classic schematic-reading bugs.
• Group by function, not by physical layout. The schematic is a logical document — power supply in one block, MCU in another, analog front-end in a third. The PCB is where physical reality matters; the schematic is where intent matters.
• Reference designators and values on every part, plus a title block with project name, revision, date, and author. Future-you will thank present-you.

Several commenters point to Henry Ott's Electromagnetic Compatibility Engineering and Phil's Lab YouTube channel for the deeper craft, and to looking at open-source hardware schematics (Adafruit, SparkFun, Olimex) as reference examples of what clean documentation looks like.

The meta-lesson is that schematics are a form of writing. The goal isn't to capture connectivity — any netlist does that — it's to communicate intent to a reader who wasn't there when you designed it.