The point of the article was to choose your language based on economic impact, rather than technical debates that are a facade of an engineer's identity beliefs.

With that pov, I don't see any contradiction by saying the language is an important decision, and rewriting your project in a new language is probably a bad idea.

You should consider documenting your durability requirements, failure modes, important context related to the feature/component your working on, as you would a junior engineer. Then, you can re-use the context documents. If the AI doesn't know what your expectations are, it will just assume you need a PoC, and give you PoC code quality.

This is amazing! Thank you!!

The quickfix window is so small, so I added the "-c only" option to make it the only window that first pops up. Then made it a function so it's easier to call:

``` vgrep() { rg --vimgrep "$1" | vim -c cb! -c copen -c only - } ```

$> vgrep "restore_tool"

Our team recently adopted the Diataxis framework, I guess. We followed this guide:

https://documentation.divio.com/

We've been referring to it as the Divio system though, which appears to be the same thing.

I've used RocketChat at a previous company, basically a clone of slack. I didn't have to manage it, but it seemed to work great.

I don't have to manage it at our company, so from a user perspective it's good enough.

Sure, there are some issues once in a while. Like with everything.

We use rocket chat in uni to communicate with team members for project, I think it is good enough for this purpose.

I managed RocketChat. It was pretty easy, but we weren't stressing it.

I do manage an instance of rocket.chat, and I am no longer a fan.

rocket.chat is open core, please avoid it

Can you elaborate on this? I am currently using RocketChat and would interested to hear of security issues or similar problems it has.