One time (BitFlash) I was building an SVG rendering engine for mobile devices back when 32kb was a huge amount of space on a phone and we had to count the microjoules of energy per instruction for battery efficiency.
We started with C++ which is very flexible. As I built it and optimized it we had two problems. One the SVG spec was a moving target and second the same optimizations we learnt had to be applied across the entire codebase in many classes simultaneously.
The obvious solution is to build a domain specific language right? But we couldn’t afford to run an interpreter at runtime. So I wrote the spec as a mix of C++ structs, enums and comments and a Perl script (it was 2000) to compile that code into optimized C++ for the parser and DOM and rendering loop.
I also built my own metabuild tools (this was 2000) to generate makefiles and the like to quickly cross compile to new mobile phones. We were able to cross compile and deploy to a new handset from a manufacturer once while the bigwigs were in a meeting talking terms. That definitely impressed.
Another example was that I was brought in 4 months into a VoIP SIP hardware phone project that was floundering. It had gotten nowhere. I had never built such a thing but I had to quickly build a working phone.
We had a very detailed spec from the distributor of the set of use cases we had to implement.
In my opinion, hardware has this annoying requirement to never crash or have bugs because hotfixing is a nightmare. These phones were for trading desks so I think the pressure was high as well to not go down.
With four months lost I know most people would just dive in and start coding and never stop until a spaghetti ball was shipped.
However that is the road to hell as you are just creating chaos in the codebase instead of order. The whole point of logic is to create order.
So yes I did dive in to the code just long enough to spike one phone call with the SDKs to make sure I knew how the tools worked.
But my solution was to “waste time” after that to draw out the spec document as a hierarchical finite state machine in PowerPoint.
Once I had a simpler visual of what the spec was saying, I then wrote a hierarchical finite state machine library. And I then wrote out the phone logic as in the language of the HFSM instead of as a spaghetti ball of smash smash code.
This let me contain all the mutex logic in a tiny part of the code base so I could stop worrying about race condition bugs which plague phones.
I was also able to build a test first library with another domain language. I wrote the tests as message sequence charts (2D arrays with mock objects) that drove the phone. The spec had a number of MSCs so this made it a lot easier to prove correctness.
By going “insane” like this I did save the project’s bacon. Not only did I deliver on time, but I was able to prove the SIP SDK the distributor ordered us to use was broken fundamentally and survive the obvious, “must be your code!” objections rather handily.
Those are fun stories; I painted myself in the best light of course. 95% of the time I was panicking before I came up with a solution and the other 95% I was panicking management would wonder why I spent two months on a side quest. Those are so long ago that I think it is ok to tell them.
Nowadays we have package libraries that full of modules like this. It’s amazing how much people have simplified with better ways of expressing ideas as data instead of code.