I think I know why you can't hire engineers right now

FWIW, this was simply an example to refute the absolute claim of the parent and the article that only the savings rate matters for when you will be able to retire. This one counter example disproved that.

Now as for your claim, I would agree that it is generally unwise to do that. It doesn't necessarily mean that your lifestyle has inflated in a bad way though.

If I make 50k with 10% savings rate (5k savings), single bread winner w/ a family of 2 and I get a raise to 55k, I will now save 6k w/ a 10% rate. The other 4k are used to finally be able to go to the museum with the kid, buy them some used skates so they can go skate in the park in winter whenever they want instead of renting skates once per winter etc. While I agree that this is "a lifestyle inflation" I wouldn't say it's one that affect the retirement in the way you mentioned.

Now if we are talking lotto winner kind of raise while keeping the savings rate at the exact same and low mark, I would totally agree with you. 50k w/ 10% gets a raise to 300k and starts behaving like the parent mentioned (fancy apartment, extravagant travel etc.) I completely agree with you.

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.

Even if it's all documented with a README, with container images and Ansible playbooks or whatever to make it all happen… still people will be complaining that it's oh so complex and that's not how we did it in my previous job and what about secret management, or load scaling, or full disk encryption, or how would this be deployed to a moon-based server, or whatever they can think of how the probably less-than-average crap you've built isn't maximally convenient for them.

So, even if you have everything 100% automated, most people will look at that and conclude that your automation is complex legacy bullshit and you should have automated in some other way.

Just saying.

Lol, if you say so!

It goes both ways. Emigration _from_ the US to another western country is also incredibly difficult.