Reading a schematic is a lot like reading a table of contents. It tells you what to expect on the PCBA but it doesn't tell you much about how the PCBA actually performs.
Electronics is much more practical than Software so you'll find that EEs and embedded software engineers take the pragmatic approach of looking at the physical signals to figure out what's happening instead of trying to understand the system from the schematic and first-principles. There's a huge amount of behavior that can only be observed, not anticipated. For example, capacitive coupling between lines on a board only presents itself in the physical PCBA. The schematic isn't going to tell you anything about that.
Think of it this way--the ICs and components are combined like functions in a program on the schematic. They're abstracted as taking a set of input signals and providing a set of output signals. The physical characteristics only make themselves known at the implementation level, which is like the PCBA layout. Even so, you actually have to power the board on or run the program before the performance characteristics and behaviors make themselves apparent.
> you'll find that EEs and embedded software engineers take the pragmatic approach of looking at the physical signals to figure out what's happening instead of trying to understand the system from the schematic and first-principles
wat? With software, you can basically probe the workings of a system without affecting it, as well as easily roll back state. Whereas when some rare transient fries several codependent components and desolders a transistor from the board, you're stuck abstract reasoning about what the heck happened, if only to make sure you've actually replaced everything that broke.
FWIW if you have reason to worry about capacitive coupling, you should most definitely have the parasitic capacitance on your schematic, at least the one in your head.
But yes, there is a lot of measuring and not being proven until something is actually built. Heck, many types of circuits can't even be built on an easy medium like a breadboard. But needing to invest more effort means applying more forethought.
A Schematic is far more than a simple ToC. It gives the complete "static" structure of a system. It should allow me to identify/map major modules/components on the PCB and make some sense of it before even i turn on the system and probe it to identify "runtime" behaviour.
Electronics is much more practical than Software so you'll find that EEs and embedded software engineers take the pragmatic approach of looking at the physical signals to figure out what's happening instead of trying to understand the system from the schematic and first-principles. There's a huge amount of behavior that can only be observed, not anticipated. For example, capacitive coupling between lines on a board only presents itself in the physical PCBA. The schematic isn't going to tell you anything about that.
Think of it this way--the ICs and components are combined like functions in a program on the schematic. They're abstracted as taking a set of input signals and providing a set of output signals. The physical characteristics only make themselves known at the implementation level, which is like the PCBA layout. Even so, you actually have to power the board on or run the program before the performance characteristics and behaviors make themselves apparent.