TheCapeGreek

From the customer perspective, often nontechnical, who cares?

Like another comment said, it's more that Service is being bought through Software, not Software itself.

We as an industry seem to keep forgetting that we don't get paid to build software for its own sake.

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.

>[...] you are asking it to continuously compress its output into a lower-bandwidth format. That compression is lossy.

Yes, that's exactly what I want. I want to know what is done with a high level why, NOT a paragraph explaining each line of code modified.

A frequent tweak I've made on coding work with Claude in the last month is asking it to restrict its comment length to 1 line/sentence max. I just want `// This happens because XYZ upstream`, not `// Historically from ticket blahblah there was some dummy code where we discovered ancient runes and that led us to looking into your birth records and then triangulated an issue in XYZ upstream that we compensate for here`.

The model's "most information dense representation" is very similar to how we compress data in the first place: most of it is redundant or unnecessary for the purposes of storage. I'll "decompress" the 1-liner context myself when I read it again in 6 months. But I can't stand reading just so much slop commentary when we're all writing more code at once and having to review more than ever.

Building South Africa's version of TCGPlayer/Cardmarket/etc, for Yu-Gi-Oh! https://lekkerduelist.co.za

There's competition in the other TCGs, and of course a 2-sided marketplace is one of the hardest things to seed. So this is mostly just a project that I can put any fresh ideas into that I wouldn't be able to at my dayjob.

Because VILT is dead and Livewire is now on version 1100?

I've worked on both stacks in the last few years across several clients. Honestly like with anything in tech it seems to mostly fall apart with half-regarded usage of the tools in growing teams that don't care about their quality in favour of "get ticket done".

In a small local scene with several whatsapp groups, I put "don't be an edgelord" as a catch-all rule rule when I started a discord in the community.

Lo and behold, the EXACT person I had in mind when making the rule, moaned about it.

Works as intended.

For better or worse, AI is beating on video essays too.

Maybe my attention span is truly stuffed, but I really can't stand it when a video essay is the most succinct source on a topic - waiting for someone to express their thoughts in speech, with sometimes slow cadences or their own waffling, combined with sponsor segments (yes I use SponsorBlock, but sometimes or on other devices ads get through), etc.

So I use AI summary for a lot of informational videos now unless I actually am watching it for the entertainment and production value. I don't need 10 minutes on "this will change the way we look at XYZ" that has only 1 minute of real information in it.

Yes, which is why I commented why I did - poster was pointing at the Netherlands which seemed to misconstrue the current state of the problem.

Personally I think the verdict is still out on if Opus & co are actually worse, or the rate at which we move with these tools now is faster than we're used to for managing tech debt and compounding complexity with rapidly built software.

If nothing else, using the smart model for planning to hand off to the previous gen for implementation still seems like a useful pattern.

Is this about EU Chat Control? Because that was mostly pushed from Denmark no?

I'll mirror some other anecdata here: Not finding Fable to be amazingly godlike at actual coding, but it does seem better at planning, architectural thinking, and reviewing code. Used it to think through some longer form refactors that involve some product decisions and changes, and found it to provide more thoughtful feedback. However that's just my subjective experience, and I don't think it's provably that much better to make me want to go pay for API pricing when the free trial is over.

My plan is to make hay while the sun shines: get some planning in over the next week or so, and just let Opus take care of it when I get to actual implementation.

There is one underrated feature that I switched to Bitwarden for, away from KeePass: the emergency contact access. You can designate contacts that can request access to your account. If you don't deny the request within a time frame, they are granted access.

So much of our lives is now digital. Important accounts of all kinds, banking, etc.

Waiting on several giant corps to grant your loved ones access after they go through the bureaucratic hole of documentation is... rough.

Putting my master password in my will feels the same as just writing it on a note on my desk. Putting it in a note in a safety deposit box is high effort and cost.

Anyone got a better alternative way to set this up if self-hosting and not going with Vaultwarden?

Responding here to short-circuit all the replies to this:

You shouldn't be looking at just various kinds of earplugs as options for this. You can get custom made earplugs for your ears for differing use cases (sleep, concerts) at an ENT.

> Images buy you a versioned artifact with all the code-level dependencies baked in.

Fair enough, that buys a little bit of time to not break deployments I supose.

> When the build process completes, it tears down the overlayfs

Ah okay, I misunderstood you then - I was referring to Docker-less servers and my build steps running there, not building the images on the machine.

Thanks for the info!

I guess what I'm asking for is what the point is of a "baked" image for interpreted language ecosystems. Already using multi stage builds.

"Builds" are the same as deploys, so when working with server(s) instead of larger scale deployments, I'm not seeing the benefit of the whole "build image, pull on server" pipeline when I can just ditch the registry and added layers by doing those steps on the server as I would normally in other kinds of scenarios.

But I have seen this in action, which is why I'm wondering if I'm missing something.

The clearer benefit to me seems to be in this scenario to use it as a fast environment provisioning tool.

> you end up having to copy all the build dependencies (source code) to the host

> disk, i/o exhaustion

This is why I mentioned specifically for ecosystems like PHP, which are interpreted. I'm specifically asking for that use case.

I'm not building binaries, my "build" steps are actually deployment steps (npm build, composer install, etc) that I'd be running in exactly the same way on the host. The image I'm deploying by definition also contains my source code because I'm not deploying anything compiled.