A schematic is a drawing, not source code. Of course you're going to want to print it out and mark up the paper. You're making a severe category error. Ther

A schematic is a drawing, not source code. Of course you're going to want to print it out and mark up the paper. You're making a severe category error. There is a visual language for communicating design intent in schematics that is not just formatting, or making things pretty (you can make a "pretty" but unclear schematic) or entering wiring connections into a computer. If you follow it, other engineers will be able to understand your work more quickly and with fewer questions for you. If you don't care, you will look like someone who doesn't care. It is the difference, say, between writing individual words or short declarative sentences as opposed to building complex sentences, paragraphs, a short report, etc. As documentation, in a production environment, your schematic will have a life beyond your EDA package. I've done sustaining work on designs that have outlasted the design packages they were done with. Without having to open them up, because there were schematics available in standard documentation formats. Eagle - as used in that lilypad design from 2013 - already has a sunset date. It's also a reality that EDA packages have poor backwards compatibility and even worse, their "import" functions rarely work at all well on non-trivial designs. That would be a fair criticism of the industry but for the most part redrawing a schematic and checking it against a netlist is not the end of the world. If you have one. As an aside, it wouldn't shock me if lawyers print out source code, either. They print out everything else and store it on paper.