I designed a PCB after 12 years of backend work. Here's what I'd steal for software.

David He — Wed, 07 Oct 2026 14:26:03 +0000

I've written backend code for over a decade. When I designed my first carrier board, it changed how I think about the code I ship. Hardware people work under constraints most of us ignore, and a few of their habits are worth borrowing.

Datasheets tell you how things break

Every chip datasheet has an "absolute maximum ratings" table. It says exactly what voltage or temperature will destroy the part. Most API docs only tell you what works. They rarely say what happens at 10x the expected load, or what a malformed payload does to the service.

Try writing that table for your own service: max payload size, max concurrent connections, and what happens past each limit. You'll find out how much you didn't know.

Trust the footprint? Never.

Vendor library parts look official, so you drop them in and move on. Then the board arrives and the part doesn't fit. On a breadboard, parts always fit. On copper, they only fit if you checked the datasheet.

So I check every footprint against the land pattern before I route anything, especially tiny parts and mounting holes. It's boring, and it's far cheaper than a respin.

Software has the same trap. We import a library, trust the docs, and never read what it does when the input is weird. Verify the thing you're depending on.

The tool refuses to let you ship a mistake

PCB software runs design rule checks. If two traces are too close, it flags them, and you fix it before anything gets manufactured.

Most of us have linters, but how many of us have hard checks for config? A bad timeout value or a missing env var should fail the build, not page someone at 2am.

When a revision costs weeks, you review harder

You can't hotfix a board that's already printed. A mistake means a new spin, new cost, and waiting. So hardware engineers review everything before sending it off, and they use checklists.

Software got fast deploys and lost some of that discipline. I'm not saying slow down. But a short pre-deploy checklist for risky changes (migrations, schema changes, anything hard to roll back) costs almost nothing.

Put protection next to the thing it protects

Decoupling capacitors sit right beside the chip they serve. Placed far away, they don't do their job. Timeouts, retries, and rate limits work the same way. Put them close to the caller that needs them, not in a shared layer three hops away.

What didn't carry over

A lot of my software instincts were useless at first. Debugging with print statements isn't an option when you're staring at a board. You need a multimeter and patience. It was humbling, and I think it made me a better engineer.

What's one habit from outside software that improved your code? Tell me in the comments.

DEV Community: David He

I designed a PCB after 12 years of backend work. Here's what I'd steal for software.