TheCapeGreek

500k/yr, not enough savings to last even a year, and really no job prospects in sight?

Doesn't add up.

I was hearing the same about an acquaintance who is an experienced <reasonably well paying stack> IC, earning "market rate" for the tech which is about the same as C-suite pay for non-tech companies in my country. Struggling to find work, running out of savings. Turned out they were declining top market end Python IC roles because they wanted to specifically earn the same as <well paying stack> instead of taking a ~30% paycut.

Do not let your title or previous earnings inflate your ego into homelessness. Save well. Even the good jobs don't last forever, so make them count.

I've been pretty happy with my M1-2 devices like most posters here seem to say, but I don't have the same level of core stability while doing dev work. Am I doing something wrong with my workloads?

- Orbstack, but just for one containerised service - Laravel Herd for app environments, so all native services instead of containers with bigger VM overhead - Brave browser, profile for work and personal - PHPStorm (quite a hog on RAM) - Now agents in the mix

Had an M1 Pro 8GB but I found 8 to really not be enough. M2 Air 16GB has been a much better sweet spot, albeit it feels like the battery life on it is worse than M1. I've recently started trying to use Zed more and more as my editor instead of PHPStorm and things feel mostly stable, but I still feel like a beefier machine would be good for work purposes.

6 lines of dockerfile changed for me, no issue.

Read a youtube comment that I think sums up some of the fanbase's thoughts: Bioware has been going downhill since the last 30 minutes of Mass Effect 3 gameplay. Even with the later expanded endings it felt disappointing. Not to mention "Marauder Shields" being your final boss.

I've been able to execute several highly niche, large scale refactors in a production system in the last 6 months, entirely enabled by AI tooling. The kinds of changes that individually by hand would have taken months and you would never get top down approval to do because it would take paid developer time away from client-focused work.

This has stabilised the system, fleshed out unfinished ideas, expanded testing capability, introduced new developer-experience oriented tools, and refactored sensitive systems to be more flexible for future use. Not to mention addressing the kinds of uber-niche tech debt that would take years to bite and months to fix.

It's far from fantasy.

Not just comprehension, but authority.

We tend to forget in tech-oriented forums that most of us are bound to those who pay our salaries, and for many developers that payment is to be focused on revenue-generating, or client-focused work.

Developing advanced comprehension and being able to use it for long-term system stability are unfortunately not always paired in the daily work.

"Production languages" is a false dichotomy by implying PHP isn't one.

There's been a patch since yesterday.

Hah, good shout on the JS community side of things. Felt the same coming from Laravel land, and even the inverse problem - I started using Livewire for my frontends so I wouldn't have to manage JS frontend frameworks, but now that Claude can do it, the value prop of Livewire is much less to me.

It's about depth of involvement, steering and ownership.

I had Claude build me some TamperMonkey scripts here and there, I don't claim I wrote those.

I do claim I built my side project with it being mostly vibe coded, because I've steered, planned and guided every aspect of that site regardless of how it was built. I own it, I maintain it. Months of building on the side.

I built a review skill that has a bit of custom project knowledge, our team's agreed engineering standards & tools, a standardised format of how it should respond, and instructions to check for PR description accuracy as well as meeting all ticket requirements.

This kind of offloads the responsibility of deep code review to the planning phase: ensure the ticket spec is correct for what needs to be done on a product/team/technical level, and verifying daily CRUD app code is a breeze.

Human judgement of the review is still required, because the biggest way issues slip through is through one-slice "it looks fine in this issue" solutions that actually violate undocumented project knowledge.

To remedy that, we've started storing architectural decision records in the repo as well.

Basically, the more context you can give it (duh), the better agents are at review of day to day work.

Taking this approach helps in teams of varying skill levels to standardise the kind of expected feedback on PRs, as well as letting developers run a self-review whether they wrote some code with AI or not. There's still plenty of review feedback going back and forth on PRs, but our defect rates have gone down and clients have been happy with the output.

Why would you want this to work on a dedicated gaming device that can emulate the titles outright?

Have a look at Decky loader and Emudeck.

For the same reason I want my car to have FSD instead of my FSD to know how to assemble a car to drive by itself.

Anecdotally, the niche it solved for me for a while was "Safari for optimal performance on mac, but with proper extensions like ublock".

I used it regularly for almost a year, eventually got off because of some UI bugs that came up and because the Safari dev tools feel so clunky/need relearning compared to Chrome & FF.

Anecdotally:

The main caveat as someone who works on mostly average web CRUD apps, is that "Use PG/SQLite for everything" usually falls flat when the tools I use day to day don't support that use case super well or have rougher edges.

If your framework/ORM/whatever of choice doesn't support the full feature set of that driver compared to Redis/ES/Whatever you're replacing, you'll find yourself going down rabbit holes doing workarounds instead of staying with the "happy path" and just using separate tech for what it's specialised in.

If you already are doing most of these sorts of features by yourself instead of with frameworks, maybe it's fine, but this does start to feel like a time-to-release hindrance if you don't want to fiddle with the minutia.