I'm not disagreeing with you but there's a large number of programmers who viscerally disagree with "test first".

https://www.youtube.com/watch?v=NyiMOmCqu00

Another life trick I've learned is that you are also allowed to:

1. Say no and disagree with people

2. Walk away from any relationship (personal or professional)

3. Do what you like, believe what you like (as long as you are not harming yourself or others).

4. Move

5. Hire experts to work for you (if you can afford it)

6. Spend your money as you please

7. Engage in conversation with strangers

8. Drastically change your life (new career, new field of study, etc) 9. Talk to strangers.

It took me a long time to realize that being an adult means taking control of my life, make decisions and being okay with their consequences because _I_ made them.

Neither musicians or authors are going anywhere, and it's kind of bizarre to say so.

People make music because they want to. They always have, since the dawn of civilization. Even if we end up somehow making music bots that can generate something OK, people won't magically stop wanting to make music.

And for both cases, it's important to remember that ML/LLM/etc can only re-arrange what's already been created. They're not really capable of generating anything novel - which is important for both of those.

> It's because what you see as the inferior approach involves less effort and friction for the developers.

I can see that.

From the other side of the PR though, it involves significantly _more_ work from a reviewer.

The "red tape" of separating commits and opening separate PRs should be removed by the team.

The effort of separating commits and opening separate PRs is minimal once you're comfortable with the tools.

I encourage colleagues to be comfortable with these workflows, because a reviewer's time is generally no less valuable than their's.

And ARR is not revenue. It's "annualized recurring revenue": take one month's worth of revenue, multiply it by 12--and you get to pick which month makes the figures look most impressive.

Honestly, I'm just trying to understand why people want to return to CGI. It's cool that you can fork+exec 5000 times per second, but if you don't have to, isn't that significantly better? Plus, with FastCGI, it's trivial to have separate privileges for the application server and the webserver. The CGI model may still work fine, but it is an outdated execution model that we left behind for more than one reason, not just security or performance. I can absolutely see the appeal in a world where a lot of people are using cPanel shared hosting and stuff like that, but in the modern era when many are using unmanaged Linux VPSes you may as well just set up another service for your application server.

Plus, honestly, even if you are relatively careful and configure everything perfectly correct, having the web server execute stuff in a specific folder inside the document root just seems like a recipe for problems.

> 1) Your salary demands exceed the budgeted amount for the position

I've thought about this a lot lately. This is true for the obvious reasons, but it's more true than it seems.

As an older, experienced dev I sometimes flirt with the idea of aiming for a mid-level developer job where I can just cruise. I'd expect the paycheck to be proportionately smaller than where I'm at now, but that's fine.

But there's no way this would actually work out. Red flags would be raised all over the place at most companies like this. For one, it'd be viewed as a red flag that I'm cool taking that huge paycut. And then of course no one appreciates being told that you want to come in, get a week's worth of work done in a day, and then clock out.