petrichornetrainfall

Exactly.

It makes sense when the people who got into programming because it was a well paying job with lots of benefits start going into the deep end with AI. Because they never actually wanted to write code or engineer anything in the first place, it was a means to an end.

But when the people who cared about their craft, and got into because they loved programing, when they completely drop all their high standards and give up writing or architecture anything, thats where I start feeling lost.

I really dont know what else I would do for a living. But im not sure how much longer I can stay professional dealing with all the slop PRs and short story length READMEs that dont actually tell you anything.

I completely agree, my point was more about decisions impacting the end user (the the one OP referenced) are typically out of their control.

I’ve definitely experienced overcomplicated implementations like that (wfh is a life saver when I can turn off the camera so my face doesnt get me fired when some dev suggests something like that). I’ve also experienced a bunch where the engineer just isn’t managed and roped in, and comes up with something just because that thought it was interesting or to see if they could.

AI has been such a bizarre experience, I figured managers and people who dont actually write code anymore would love it, they boss the agents around just like their workers, but seeing some of these truly amazing engineers who use to block my PRs previously for the littlest hypothetical gold plated criticism now just spamming these 100+ change PRa that they literally cant defend because they didn’t even look at the code…its just disorientating.

The example you provides is because managers/executives/shareholders demanded it, not because of software developers wanted it.

If it was easy and simple, then you wouldn’t pay for Apples genius bar to do it for you.

Even team leads and department heads have limited input on decisions that impact usability from and end users perspective.

I wont say software engineers never make things needlessly complicated, they do build things that are easy to understand from their perspective sometimes. Its also dramatically harder to make something complicated simple, and easy to make something simple complicated.

Tldr: people who do the actual work dont get a say. You’re getting mad at the McDonald’s employee for only giving you 2 sauce packets, instead of corporate for creating that policy.

So right now im kind of doing option 1, but .local (I’ll switch to .internal) and not using * ( which I will change and see if it let’s me use the subdomains I configured in caddy that werent working before)

Option 2 it what I considered switching too, I have adguard running on my router, but was testing option 1 when I decided that I might want to skip ahead to something more advanced. I really dont want to have to install certs on each device to get past the warning for https.

Option 3 is on my backlog, I have a vps I planned on setting up pangolin on later down the road after I got some of my services spun up, but maybe I should take care of that now instead.

Option 4 is something I briefly looked into before realizing its way over my head, and im also pretty risk adverse.

Sumarry: so maybe option 3, and possible option 2 if its still needed when on my local network without having a client running.