they do, at least to some degree, but their comments are dead. You'll see them if you turn on show-dead somewhere

their comments are dead, probably related to it being a new account

I really did create a new account to respond :)

They don't really say. My guess would be something embarrassing, and that's why they are keeping it to themselves. Maybe passwords in Drive og Gmail. Or just passwordless login links (like sibling said)

> Become an expert in 1 thing

Any suggestions to what that could be?

I'm a backend developer looking to specialize in something with a clear demand.

Top-of-the-head ideas are things like: Kubernetes, Postgres, Caddy, Self-hosting, Go or Google Cloud

Obviously, one has to try to gauge the demand before spending too much time on it

My take on it is more around domain speciality, than a purely technical focus.

I'm a web developer / designer-lite (amongst other things in previous lives), and have embedded myself as the web-tech guy for an embedded / hardware team. I help provide better customer facing interfaces (through websites, apps, etc) to both end users and manufacturer that the company uses.

I've made small, simple tools that can be packaged up along in a device's flash (it's ~2KB), that allows a user to interrogate the device via serial, capture all the commands + responses, & trivially email them to an engineer. It's designed for troubleshooting devices remote, without needing to ship JLink's or debuggers or what not to clients. It's a very small thing, but it's cool to hear people using it to help troubleshoot with users, in a way that's much simpler than trying to jump on the phone with them & guess what they're seeing on their screen.

I also specifically help make manufacturing test systems which sit closer to a web-app like experience (in terms of usability and visuals), because I've observed that providing end-of-line manufacturing staff with poorly cludged together test systems leads to a bunch of errors which don't need to exist (they're often just quickly thrown together CLIs, which are unpleasant to use and buggy all round - especially for less tech savvy manufacturing staff).

I also happen to really like embedded engineers, they're fun to hang around with - and I get genuine satisfaction out of being able to help them out in areas they haven't specialised in.

> My take on it is more around domain speciality, than a purely technical focus.

Yeah, I think that is good advice. You just need "an in", somewhere to start.

Sadly, all of this stuff is a commodity. The market is flooded with such "experts." I'm not saying you aren't better than all of them, you may very well be, it is just very hard to differentiate.

I think you're right that it would be hard to differentiate.

I don't think there are many actual experts though, experts as in the people your developers call when they can't figure it out themselves. But the marked is probably small-ish, and there's a large effort to become a real expert.

Absolutely none of those are “specialties” that will set you apart

The US this week invoked God when bombing people

Of course, Iran does to, but let's not pretend everything would be peaceful without Islam

Thunderbird is great <3 use it daily, for all my work and personal mail. Donating

Edit: They won't let me: "We couldn't verify that this email address is able to receive mail. Try again or enter a different email address to continue."

Cutest cat ever

For a solo dev, what are the advantages of _not_ building on your own machine?

Is the compiling and test running too resource intensive?

Do you build every commit? If so, why?

I see the value in larger teams, but for solo stuff I just find it slow and annoying. I'm using go, and it compiles fast, so that could be a part of it.

> For a solo dev, what are the advantages of _not_ building on your own machine?

I end up with all kinds of random crap on my own machine. It's very easy to accidentally e.g. globally install a library that wasn't properly listed in my dependency management. So having a separate standardised/controlled build environment is a good way to catch those. It also helps with flaky tests or random "works on my machine" problems - this way my tests are at least getting run on two quite different machines (different OS/arch/etc.)

Output from Kagis LinkedIn Speak -> English.

Probably more accurate? :

"Earlier this year, we admitted we have no idea what to do with VR or Horizon. We’re splitting them up because they’re both failing in different ways, and we’re turning Horizon Worlds into just another shitty mobile app. This mess is going to break everything, including the app on your phone. To "streamline" things—which is code for cutting costs—here is everything we’re taking away from you through 2026.

• Meta Horizon Worlds:

By March 31, 2026, we’re pulling Horizon Worlds and Events from the Quest Store. We’re also killing off Horizon Central, Events Arena, Kaiju, and Bobber Bay in VR. You can play your other favorite VR worlds until June 15, 2026, but after that, we’re deleting the app from Quest entirely. If you still want to use it, you’ll have to stare at a tiny phone screen like everyone else.

• Meta Horizon Hyperscape Capture (Beta):

By March 24, 2026, you can’t watch Hyperscape captures in Horizon Worlds anymore. They’re stuck in some beta app in your library that nobody uses. You can still record stuff, but you’ll be doing it alone because we’re killing the social features.

• Meta Horizon Plus (MH+) Perks:

By March 31, 2026, we’re stripping the Horizon-specific crap—like Meta Credits and digital clothes—out of your subscription. We’re charging you the same price for less stuff, but hey, you still get the monthly games.

We’re still spending money trying to make the Quest suck less—we added a keyboard and let you move windows around, and we’re forcing a new interface on you whether you want it or not."