To be clear, I found it wasn't a good use of time to spend years experimenting with many supplements that end up working temporarily and then having an antagonist effect on something else that appears months down the line.

The best use of time was taking a holistic approach. Supplements didn't save me - but without some basic supplements I wouldn't have been saved. And I agree, some basis in nutrition is important.

One thing I learned is to ignore figuring out the exact supplements, because you’re playing an impossible balancing game with poor feedback mechanisms. There’s too many inputs.

What helped me was a combination (no one thing can solve it) of therapy (being able to listen to and not suppress emotions), key supplements (magnesium/iron - check out lactoferrin and anaemia of chronic infection), exceptional oral hygiene to reduce inflammation (4 minutes per brush), exceptional gut health (many viruses cause problems with the gut), exercise (eventually), and more…

I never used niacinamide or any of the supplements you used, which shows you that there’s no single approach. I agree that it appears to correlate with an unaddressed infection.

The first task was a generalist task ("inside the frontier" as they refer to it), which I'm not surprised has improved performance, as it purposely made to fall into an LLM's areas of strength: research into well-defined areas where you might not have strong domain knowledge. This also is the mainstay of early consultants' work, in which they are generalists in their early careers – usually as business analysts or similar – until they become more valuable and specialise later on.

LLMs are strong in this area of general research because they have generalised a lot of information. But this generalisation is also its weakness. A good way to think about it is it's like a journalist of research. If you've ever read a newspaper, you often think you're getting a lot of insight. However, as soon as you read an article on an area of your specialisation, you realise they've made many flaws with the analysis; they don't understand your subject anywhere near the level you would.

The second task (outside the frontier) required analysis of a spreadsheet, interviews and a more deeply analytical take with evidence to back it up. These are all tasks that LLMs aren't strong at currently. Unsurprisingly, the non-LLM group scored 84.5%, and between 60% and 70.6% for LLM users.

The takeaway should be that LLMs are great for generalised research but less good for specialist analytical tasks.

They are usually easier to administer for less professional users, as well as being able to quickly modify from standard web interfaces.

If it’s backed by a cache like redis it’ll easily handle Hackernews level traffic, even at very short cache times.

Alignment between people and technology, mostly. Much aggregated from my other site (https://principles.dev).

- https://principles.dev/blog/first-principles-thinking-a-visu... - post with 3d graphics

- https://principles.dev/blog/where-are-all-the-software-carto... - one that took the longest to write

- https://principles.dev/p/relatedness-pattern/ - A principle

Trying new technologies means you're mostly becoming better at using someone else's APIs - this is the path to eventual burn out as the churn continues.

There is a better path - See through the hype. Ask those around you what's the downsides to this approach? And you'll often get blank stares... Why? Because they don't know either - And if they don't know the downsides, they don't really know. They are following the hype curve.

Focus on the fundamental engineering principles and asking better questions - take the bottom-up approach and the reward is you'll find teams that aren't taken by the hype curve so easily.

PS. There are a lot of good technologies that come out, but staying behind the hype curve a little helps you make better judgements over time.

[1] https://www.amazon.co.uk/True-Drama-Gifted-Child-Phantom/dp/....

If you knew no one would ever read your writing, would you still write it? If yes (the likelihood is no one will read it apart from your future teammates) you'll have found your subject.

It can give you jobs, learning & connections, but it also takes time. Time that can be used for other things that could get you the jobs, learning & connections you want without writing. There's no one way to approach it, you need to find what works for you.

For me - I've written a lot (mostly as principles), but only recently I've focused on learning how to write, which meant I needed a blog to write on and a way to make it fun for me ( https://principles.dev/blog/first-principles-thinking-a-visu...)

Before that, we’d been building an app for Nokia N97 handset users, an ever-decreasing market - all the engineers on the team had iPhones.

We thought after that email that the next step would be to go on Android. Sure, Nokia would contract a little as it lost its platform, but the platform wasn’t that valuable. It was the great handsets - software wasn’t Nokia’s forte - the leadership structure just didn’t have the vision to bring it together.

When the meeting rolled around, we all went to a big conference centre at the heart of Berlin to watch the announcement of the future vision. Stephen Elop appeared on a gigantic screen, talked a bit before laying down the new vision. It was going to be Android, right? It made perfect sense, the ecosystem was growing and aligned to Nokia. But, no - Stephen announced that the future of Nokia was with Microsoft.

I walked out of the conference when I heard that - standing outside of the conference hall. I knew two things at that moment. One, there wasn’t going to be a future for Nokia - there was no way Microsoft under Ballmer’s leadership could produce an ecosystem. Secondly, I realised that Elop was still Microsoft’s man - He didn’t make the logical choice that fit with Nokia’s culture - It was going to be a takeover by Microsoft.

The project I was working on soon got a new boss. We thought this would align with the new vision of the company. He took us into a room and projected a picture on the wall of a mountaintop surrounded by clouds. He said, “I know you must feel a bit like this, unclear about the direction, clouded about what the future holds. Don’t worry… I also feel like that, too”.

The new boss did eventually make a decisive decision - the N97 app that we were building was to be kept, but it was going to be focused on an even smaller niche of the market, N97 users who were pro skiers. I left soon after.

The takeover by Microsoft did eventually happen, and the rest is history.

Going to be a hard one to get right, so I'm taking my with that one.

I've a few principles for that: https://principles.dev/p/documentation-should-be-close-to-th... and “They Ain’t Gonna Read It” (not on the website, yet. But it is here: https://blog.nuclino.com/brown-m-ms-or-why-no-one-s-reading-...)

The trouble with the documents you've mentioned is they don't really create capability and it's really the social structure that enforces those values and principles as opposed to the documents.

With engineering it's different because it provides tangible value.

From a team perspective it can help you transfer mental models. Programming is an abstract activity that benefits greatly from those shared models. They build capability, help people learn rapidly, settle disagreements, bring the team together as one and are used in things like code reviews and filtering of technical decisions. People come back to them again and again - it's integrated. Then when a new member of the team comes a long, you're not going back to those discussions again and again.

As an individual. One of the reasons you look back at your principles to remind why you believe something or to be more convincing. They provide value, so they keep being used. It's also part of that persons identity. It defines what they care about and helps them join teams with people who are aligned.

So I agree to an extent - They Ain’t Gonna Read It... Unless it provides value.

https://principles.dev/p/one-single-source-of-truth/

> Exceptions > Highly distributed systems - Some systems rely on data consistency to be reached eventually or may never need to have accurate data.

I've written about exceptions here: https://principles.dev/documentation/#exceptions-optional

In general, exceptions should be quite broad and people can add these to the principles if they know of them.

They can also have higher priority "contradictory principles" which override the lower priority principles in certain cases.

Overlapping of principles create complex behavior so it is usually better to have a list of principles in priority order (this will be covered under emergent behavior in "principle-driven engineering") which can override the "single source of truth" principle.

An example might be: Engineers will know they should use single-source of truth, but as performance should be critical (or they have a specific business rule that states something must take less than 5ms) it will override that principle.

Does that answer your question or do you think it needs to be more refined than that?

I wonder if making the principles editable by the team would be a useful feature, so you'd be able to add your own exceptions to them for your particular use case.

Not all of it would appear on the principles.dev, as I think the reflective nature would be best handled elsewhere. But acknowledging pros and cons on the website is very valuable.

The next big piece of work I have to do is on principle lists ( https://github.com/PrinciplesDotDev/principles/discussions/2...) and figuring out what features to include and where to draw the line is going to be tricky... I need to find the principles behind it, really.

It's interesting that you say they would be a valuable resource for a junior and mid-career engineers. I agree, it would. What I've found is it generally attracts people who are a) leaders (in some form or other) b) care about programming deeply.

On the SDLC, it could work. The temporal aspect is something I need to think through in a way that's not too complicated. Getting feedback at this stage is beneficial, even if this hit HN a lot earlier than I was expecting.

Establishing your own principles is burdensome, but using others is not. Having access to everyone else's principles and being able to see what other successful teams use, makes it easy to take other people's capability and add it to your own. Imagine if you could see what principles Rob Pike or or the principles behind a library, framework or a particularly productive team? This gets me excited. It gives people the building blocks to make great things.

I totally agree that individual principles is extremely important. If not for the very fact that finding and being on aligned teams is an amazing experience for everyone involved. Happier, more productive teams.

I would love to have an informal chat with you, you get what I'm doing and it needs people like you to for this to succeed for the community. Drop me an email if you can take me up on the offer :)