It depends… The myriad of reasons to have a dedicated release day have often to do with synchronizing marketing, support and the other departments.

My question is what does QA mean for your org? Does it mean defect detection? Testing? Acceptance? Those are all different things. The teams i see that are able to release every day have a strict separation of Quality Control and Functional Acceptance. QC used to detect defects and regression and is handled by highly automated processes accounted for by engineering. Then acceptance is done by a dedicated product/quality team that figure out if the new functionality actually is built to spec and solves the customer problems. This also involves blogs, documentation, customer contact, release notes, tutorials and workshop for the support team etc… This second part is handled by feature flagging, so that the product teams can bèta test, run a limited release and track adoption.

It really depends on what kind of software youre running and what your relationship is towards the end user and the rest of the org. Something that is the same in all cases is that your requirements and acceptance criteria need to be very clear from the start and regression resting needs to be fully automated.

Vue has had the fastest growing adoption for the last few years according to the Stack overflow and JetBains surveys.

I’ve had better experiences onboarding young developers onto Vue projects than React. I also feel that Vue skills transfer better to other applications rather than front-end.

The dev availability is different per region. We see that applicants in northern Europe for example is still very Angular leaning, while SE Asia is more Vue. I think React is mostly a West US phenomenon.

It’s difficult problem to solve. Lemmy’s stack is a bit unconventional. The rust backend is not idiomatic and the ui is based off a template of an isomorphic not-quite-react framework. Its not impossible, but it will take a while for alot of programmers come onboard.

That being said, there’s more to it than writing code. Better bug reports, reproduction, updating docs and triaging/managing the issues is possibly more important than writing PRs. Don’t be discouraged!

Article is a bit dated and hard to read. The gist of the author is relatable though 15 years later: redundancies have been hella annoying, especially if they are unknown. Bad abstractions, however, create dilemmas, dead-locks and chicken-and-egg situations. And it’s impossible to create good abstractions unless you have no colleagues and no customers.

I would take some frustration over grinding to a halt any time.