AdamCraven

Have enough supplements to cover your bases and ideally cover it off with whole foods when possible.

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.

I used to have CFS, but apart from the occasional temporary post viral fatigue that many get, it’s gone. And what is CFS but long term post viral fatigue?

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.

I always wondered if some hidden pattern would be exposed when visualising numbers in unconventional ways in numbers with no known pattern such as Pi or prime numbers. A sort of multi-dimensional rendering that suddenly reveals a hidden pattern.

Well, they buried the lede with this one. Using LLMs were better for some tasks and actually made it worse for others.

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.

As someone who uses a mixture (django, Hugo), I say it’s fine use dynamic sites to run a blog - there’s millions of them out there.

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.

https://adamcraven.com/writing/

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

The minimal design on the blog looks great.

It's because a lot of engineers are learning to become better plumbers, not better engineers.

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.

I would avoid Alice Miller, because she abused her own children[1]. “The body keeps score” I’d recommend instead

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

It gets you more of whatever you love doing - even if no one reads it - because you get better at whatever you write about.

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...)

What are the genetic variants? I can’t access the paper, but I assume if anyone can we’d be able to run our DNA results (from 23andme, etc.) through this to see how high we score.

It does actually work on Intel macs - albeit very slowly. I left the process on in the background and my computer kept locking up. Once I realised what was causing the lock ups - I checked the process and it had indexed a very small number of the photos.

Thank you! I can confirm it doesn't work on Intel Macs. But it does indeed work on my M1 laptop. This is going to be a huge timesaver.

I've bought it - I would also buy a desktop verson if you're interested in making one.

I worked at Nokia as a SWE in Berlin when that email dropped into my inbox. A few days later, it reached the press. We mostly thought ok, fine. What’s next?

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.

It's the main feature that's missing from this - I'm working on it - context sensitive principle lists, with ranking, which can slice up reality in the way you've said.

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

Yeah, I know what you mean.

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.

It's funny you chose that principle in particular because it does have an exception listed:

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.

I imagine teams will shared their principle lists on blog posts and put reflections there.

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.

Oneshoe, thank you.

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 <insert favorite programmer uses> 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 :)

The eventual benefit is having access to many community sourced principles as a resource, which are getting better over time as people contribute.

Then being able to create your own lists for unique situations. Say "Lupire's CTO list" or "Lupire's management principles" and to share that with your team or as a reminder to yourself.

Of course you should always be able to export it and put it in a format that's useful to you. And that's been really important to the design. From using markdown format to embedding license information and meta data with the principle, it should help a lot with portability.

Haha! It won't be long until there are some there.

I may take out the filters by technology choice for the time being, because there's nothing there.

In software engineering, the smallest behaviors interact to cause more complex ones.

In most teams, it's hard to point to those small behaviors because they have become habitual and you may have forgotten what they are. Forgotten the "why".

What I see in teams that don't work well, is teams don't have that guidance or don't share similar mental models to allow them to work effectively together. So you end up arguing at a higher level than the actual problem because you can't put your finger on what you believe.

Principles build capability. Take Redux, it has just three core principles: https://redux.js.org/understanding/thinking-in-redux/three-p... and from those core principles you can almost build the whole framework.

But more importantly it provides capability and confidence to people using the framework to extend if needed in a "redux" way. Instead of looking at the documentation, they know the authors intent. The "Why"

That said, the site is really in it's earlist phase and the principles will be improved over time with more in depth information as more people contribute. Eventually, a voting system will be in place so the best principles will come to the top.

Can you show me where that is or what visualization that is?

I haven't put anything on the website intentionally, perhaps it's auto generated.

The only page that I haven't purposely optimised for mobile is the editor, as you can't really create principles on your mobile.

A lot of thought has gone into the licensing. Hopefully I've covered all bases.

You can't be an author if you aren't the author of a principle or the principle is too generic. If the principle is already open source (e.g. on wikipedia, has a creative commons license) you can submit it but not claim you are the author for it and submit it under the same licensing terms (CC-BY-SA) as long as it doesn't break the license.

Codifying the principle for the first time takes effort and people can iterate on it to make it better over time. Many people may have had similar thoughts before, but if it's not a general principle already being used the first to turn it into a principle - to put a stake in the ground - benefits everyone and can help improve everyone's capability.

I believe the author should be rewarded for that effort, as long as it is their own unique work.

I really like that you've thought about these - and feel free to submit them not only will you get a founding badge but if you're the first person to create it you'll be known as the source of them in the future.

It's not really about better or worse, what I've found is different people have different backgrounds and what principles they find useful is based on several things, which may be immuntable - such as strongly held values.

You're never going to make me not care about aesthetics for example, as that is intrinsic to me and that will affect the principles I like and ultimately the people that I work best with.

An analogy I like to think about is that people with very different principles are like two people holding a rope and pulling away from each other - you aren't going to get anywhere fast.

Whereas people with similish principles, will generally go in the right direction. Sure, they'll get tangled up from time to time and you won't always want to get in exactly the same way. But there's a collaborative nature to it and you'll both improve.

Some principles do have this already, it depends on the princple. They tend to be more code focused, such as compute properties when possible: https://principles.dev/p/compute-properties-when-possible/

It would be hard to do it for every case, as principles interact together to create more complex behaviors. I'll be discussing this more in "emergent behaviors" in "principle-driven engineering" at some point. But the essence is architecture can arise from a few principles together. It's a bottom up approach to architecture where team members understand the "why" so there are shared mental models between the team.

Well to quote the "what" of the principle https://principles.dev/p/iterate-in-thens/

You should iterate sequentially on a focused chunk of work at a time. Once that chunk has been completed THEN start on the next chunk of work. This is opposed to doing multiple chunks of different of work in parallel.

It's really a way of working as opposed to operating on code.

Indeed. That is definitely the next steps to allow individuals and eventuall companies to create their own principle lists.

There are no principles that make sense in every situation, there are no teams that will have the same principles.

Imagine being able to have a team and then adopt those principles easily into your team? That's the goal.

All principles on the website are currently in this repository: https://github.com/PrinciplesDotDev/principles In fact, this is the database for the website.

So you can download them from there and put it in an ereader or import it into an application that supports .md format.