Wow. I’m not particularly sensitive, but that seems like the right amount of very bright strobe that gives me headaches in concerts, especially at night in the dark. That’s very much the level of trying to find out a way to get to the roof to unplug it.

Entirely true.

I’m currently working on a little project that’s interesting to me (a low-spoiler walkthrough system for adventure games) and after a lot of back and forth, I decided to cut all of JS out of the picture. Just get rid of all of it, and do good old 90s server-side rendered HTML with modern CSS placed on top of it.

And that’s, honestly, a joy. The first draft of a page looks like the first screenshot, then you add some semantic classes to the html and throw some simple CSS at it and it looks acceptably neat. And I could get rid of so much janky toolchain I just fail to understand.

Inside, I like Abyss, similar to the OceanDeep theme of Vim.

When I’m on the balcony, it’s hard to see anything, so them I switch to Solarized Light.

I just enjoy the scene of the oldtimers strutting in like true chads and showing the youngsters how to take care of the big lady. It’s so wonderfully corny. And it’s such wonderful bullshit, and when you learn how many hands were necessary to run such a ship, it’s even more fun.

A bit from an ops-side, but I think it applies. I think pair-work, pair-programming, pair-troubleshooting is a tool for specific situations. It’s amazing in some places, and an exhausting waste of company resources in other places.

Like, if we’re in a hard situation with many unknowns and possibly horrible consequences of mistakes. Critical systems down, situation is weird. Or, implementing config management for something entirely new. Or, trying out new code structures, ideas. That’s when being two is great. You can bounce changes you make to the system off of your copilot, so you can be very safe while being fast. You can have two opinions about shaping a piece of code and APIs. You can iterate very quickly if necessary.

On the other hand though, there are things that require deep thought. Like, I had to figure out how 4-5 teams use an infrastructural component, what’s the live cycle of the component, when to create it, when to delete it, how to remove it. It ended up being twelve lines of code in the end, but like 1 phone call every two lines of code, and an hour of thinking per line of code. Pair programming would not have been compatible with this.

Or, the third kind, is crunch work. The best way to do crunch work (besides automating it) is to just put up headphones, find flow and hammer it down. Have it reviewed later if necessary. But why would we need 2 guys following the same runbook for the upteemth time?

It’s a great tool to share knowledge and to handle critical tasks with high error potential and I wouldn’t want to miss it for that. But it can be overused in my book.

Well, you’re looking at a method, and imagine two things.

The first is a link to a confluence article. You click on it. Nothing loads. Ah, right. Activate the VPN. Click the link again. You have no access. So you send your IT a ticket to gain access. One week later you get a mail you have access know. For what? Who’d remember last week?

Alternatively, there’s an inline comment, or a markdown file in the same repo so you click on it and your IDE opens it. And then you modify the piece of code and you realize you still have that markdown file still open, so you adjust a few things and also note down a weird quirk you found during debugging.

However, in the first case… well, you finally had access to the documentation, so you want to modify it to bring it up to date. Well, guess what. You have read access. So back to another ticket with IT that you’re actually working on this and you’d like to update the documentation. After a week, you’re notified: Well they need approval of the documentation owner for you to get write access. They are on vacation. When they get back after 2 weeks, they approve the request, and it goes into a second round of approvai with your teamlead. And guess what? Right, he’s not in for the next 2 weeks. By the time you finally have write access, you’re not working in that department anymore. And no, that other department doesn’t use that confluence.

Overall, documentation tends to be somewhat of a chore for many people. If it’s close - it’s in the same repo, you can open the file in your IDE, you can commit updated documentation with your code in the same PR - there’s a slightly higher chance for folks to update documentation. If you put in the hellscape of a process some companies have for their tooling there, no one will ever touch the documentation.

Zwingst du uns nu zu den 3-5 laut gerufenen Worten? Ich find das ja eher unnötig und provokant.

Feel free to ping me as well if something sets up. I currently don’t have the time or personal grit to run a full instance on my own, but I know how to run linux, postgres, mysql, networks and other things. Ansible/Chef mostly as well, some puppet, some salt. Been doing this for 10 years or so on different stacks.

I’d be happy to be part of some “Lemmy-OPs-Support” group, wherever it may be to chime in with experience.

Other claims say that this was from a time when you could just add mods to your sub without requiring their consent, though.