OP here. I've worked at two embedded software shops, and every time we are working on a new product and cramming to get it shipped, we run out of code space. Each of those times, PR's stay open for 2-3 weeks waiting to be merged until engineers can work their magic and reduce the size.

I've even seen instances where deals take place. We'll clean up our module today and you can merge your 1k feature, but we'll need 1k in 2 weeks and you need to find it for us by then.

Software engineers usually laugh when I tell them about my struggles with code space and memory. I do enjoy it though.

Right there with you. I've dealt with the dreaded overflowed by XX bytes message more then I'd like to remember.

I've also run into the issue where you tell the business hey, this isn't going to reach QA for another 2-3 weeks now. And when you explain the details that we are 20 bytes over memory (etc) and need to make space they think of it like removing some characters in a sentence on a word document, not understanding it might take reorganizing an entire module or 2 or rewriting entire state machines or whatever it takes.

And yea, the deals thing is funny cause it seems to happen in every embedded system where multiple people are involved on the project.

I'll laugh with you but not at you. It is a blast to do embedded work

> they think of it like removing some characters in a sentence on a word document

Too real. In the past, the way we usually went about saving space when we needed it was removing small animations, shortening log messages (eventually encoding/hashing them), compressing icons that were stored in the firmware, and ensuring large functions don't get inlined.

LTO was also an option, but wow, does it slow down build times and make the development cycle a pain.