I think one thing to consider is the requirements. I am guilty of overcomplicating a pretty straightforward high priority process in an embedded project. But wh

I think one thing to consider is the requirements. I am guilty of overcomplicating a pretty straightforward high priority process in an embedded project. But when I asked, ok, what jitter is acceptable when driving these pins, the “product owner” (lol) just said as little as possible. Or if it was ok if the period was 75ms plus a few hundred cycles they said, well it would be better if it wasn’t. When I asked if it was ok if I used a ton of interrupt and DMA resources, they said that was fine. I was enjoying myself writing a little high precision callback and signaling framework, and exploring the fancier abilities of the micro. Now, it worked fine, easy to work with, though not straight line c code, high quality unit tests in automation, sounds good. But really, if I was solving that problem for my own project I would have used like one interrupt, taken half the time, been much more straight forward to modify, and I can’t imagine it would have worked any worse. But I was giving management the option of good or perfect, without saying hey, when I leave, which I did, other developers are going to need to carefully read my docs and spend some time to get up to speed on the “perfect” option, and I have no reason to think the results of the good option will be measurably worse…