https://store.deepcomputing.io/products/dc-roma-risc-v-mainb...

Always have the right version for it "locked". It works well with most tools except those that save stuff in the .config folder as it messes up isolation.

If you find the nix language daunting, for basic stuff like nix shell setup its easy but also LLMs are good for it.

The author then recounts advice he gives to juniors, which is to stash the work and rewrite it, claiming that the next day the work will be rewritten in 25% of the time and 2x quality. This is unsubstantiated though. For juniors this suggests it will help them develop their capabilities to reason about implementations of problems without needing to face a a large amount of them.

The author then gives another advice which is to ask for a solution to a problem then after the initial proposal, ask for a 24h solution. This is meant to generate "the real solution". He likens it the a path algorithm heuristic to reach your goal quicker.

Overall the methods are not well discussed in terms of pros and cons, nor substantiated with experiments.

Opinion: I think they may help some juniors who need to build up experience and may become stuck in development patterns. But they would rarely be useful to develop someone to be a senior, if all they do is chase fast implementations. In a way the post gives conflicting advice: write twice and write better, and think twice and think about the fastest way to achieve the goal, instead of engineering a problem.

The author hasn't really convinced me of these approaches, and especially the last one smells of eXtreme Go Horse.

The Benchmark numbers are massaged to look really impressive but upon scrutiny the improvements are at most <1.86x compared to the leading product LangChain in a further page describing the measurements. It claims to beat it on all aspects but where it gets close, the author's library uses a warmed up version so the numbers are not comparable. The author acknowledged this but didn't change the methodology to provide a direct comparison.

The author is Bhavnick S. Minhas, an early career ML engineer with both research and industry experience and very prolific with his GitHub contributions.

Congratulations to the achievement that is OIDC!

Opinion: having seen this with many friends I think the author does good to acknowledge it, but the main thing to figure out is why they're writing. To be prolific at writing does not need to imply prolific at publishing.

I've actually started to write these review style comments because far too often the articles posted here don't have substance and interesting debates happen around bad data. So I wanted to see a change and critique the content not just the general concepts behind it. I now write more without having to accept my contributions are significant. But also create a network effect where friends read my reviews instead of being swayed by the upvotes and comment sizes, or worse the algorithm.

Now onto my opinion. The Staff that I've met in my life are more of the solitary type, the Individual Contributor class of person who have decades of experience in their expertise and supporting skills. Yes they may have the responsibility defining the work for others, but that mostly happens as an architect. They herd seniors not mentor juniors.

The article itself doesn't work hard enough to set the bar and explain to me why I should give the title to someone when in some companies these are just the responsibilities of a senior or at a stretch Principal. With extremely rare exceptions, this has become position inflation for the sake of looking good when going to VCs.

The article speculates that it can be used for sender and receiver tracking, but also offers a positive option which would be blocking malicious shares.

No explanation is given by Google when reached.

Fine-tuning is suggested to improve jobs like tooling upgrades but no concrete numbers are offered.

Lastly RAG on documentation. The RAG has a simple system prompt to improve uncertain responses. They're tracking meeting and support requests but don't show any results. They mention frustration with nonsensical answers but use a RL human feedback technique to improve responses. No numbers offered.

Overall a simple overview of what they tried but the strong methodological start doesn't get reflected in the numbers reported later on.