Doing it right (via the algorithm above) is a trivial few lines of code. The thinking behind the state machine that gives both high reliability and low latency isn't trivial. It is, however, obvious once you know the trick of maintaining an extra auxiliary variable in addition to counter/timer variables, and understand that you don't need to wait for the bouncing to finish before registering a change. Think sort algorithms; everyone comes up with bubblesort first, but you can do much, much better with only tiny changes after a bit of thought.

On the one hand yes on the other hand I’d boldly claim incorrect debouncing is the most common (and usually exceedingly obvious) defect in embedded systems.

And yet… I’ve seen it done wrong so many times, resulting in either spurious inputs or lost inputs, depending on how it’s been implemented.

I agree with you, don’t let it discourage you from embedded hardware. If you want to be successful in the embedded space, though, this is a great easy example to show that you need to take into account a bunch of physical effects when you’re doing hardware. Capacitors change their value with temperature and applied voltage (!), resistors have capacitance and inductance (which may or may not matter), clock crystals change frequency with temperature, switches bounce, ADCs have sampling capacitors that need to charge, chips power themselves up from active-high TTL lines, etc.

I’ve been doing embedded for 20 years now and one of the biggest things I’ve encountered with new learners is that the Arduino platform is amazing for people to get into the field but they’ll hit a point where something mostly works and they don’t have the rest of the background necessary to debug or understand why it doesn’t work as well as they thought it would. Or works great and then “randomly” blows fuses/burns out of there isn’t a fuse.

So trivial that I want to throw away by the window my microwave everytime I use it!