The more dogfooding projects the better. And yes, rule of three applies.

Spot on, I've worked in multiple small, medium and large companies. And these internal platforms almost always turn into ivory towers of useless churn.

Even if being forced to use it internally, in a lot of cases the projects ended up buying the same solution (or a working version of it) from an outside vendor when it came to fulfill actual customers needs on the outside.

If that wasn't possible we built what we needed ourselves.

If you have internal customers, I still believe you need internal incentive alignment. Otherwise what the platform builds and what is actually used and needed drift apart.

And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.

If you don't have a project-0 to test those assumptions against, you don't need to start that platform.

[0] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

I mean this is kind of what happens with any advice that has nuance to it, that's not carried with the advice.

E.g. if you have a point in 3D space with x, y, z coordinates. Array points as SoA of individual dimensions makes sense only if you do a lot of averaging and such on the individual dimensions.

If you mostly use the 3 coordinates together, SoA will have bad caching behavior.

So the better advice would be to try to keep things that are used together in the same cache line, whether it's on dimension or all 3. Usage makes the difference.

Agreed. Good design is when the things do what you expect them to do without reading the manual, don't reuse wording with other meaning in the wrong way. That way if you do encounter nee wording, you know you should read the manual.

I know this is contrary to your advice but mechanical pencil, get a Kuru Toga, it's a really nice improvement and not very expensive. It auto-rotates the pencil tip, so you don't have the sharp end at some point.

For permanent writing get a Uni ball gel writer, it's supremely smooth to write with. Also not hugely expensive.

They're both not the cheapest option, but an amazing writing experience without being the fancy kind of expensive.

Can we use this instead of grout in the bathroom somehow?

Yes, the math department.

In any case linear algebra, stochastics, calculus; plenty of engineering and science applications for all these.

It makes you feel that way because it is that way. They're not self-sufficient.

Especially in a filesystem I know where I placed something, but not always the title, so even if the search function was ok, which it mostly isn't, having to know the wording used for the title is really inconvenient.

I still can't wrap my head around how people find their files in the non-filesystem world. Whenever I need to work with files I take out my laptop.

At least codex listens to me telling it to use rg instead of grep, cause grep is often so slow. But when adding rtk it uses grep through rtk which is kind of annoying.

It's easier to find a needle in the haystack if the haystack is 50% needles.

Besides OO -> Functional this applies everywhere else in Computer Science. If you understood the fundamentals no new framework, language or paradigm can shock you. The similarities are clear once you have a fitting world model.

Even if it's once off, some people handle a lot of once-offs, that's exactly where you need good CLI tooling to support it.

Sure jq isn't exactly super slow, but I also have avoided it in pipelines where I just need faster throughput.

rg was insanely useful in a project I once got where they had about 5GB of source files, a lot of them auto-generated. And you needed to find stuff in there. People were using Notepad++ and waiting minutes for a query to find something in the haystack. rg returned results in seconds.

Still if you go blue collar you have to build your own business.

But that's the thing, in other languages you don't need a workaround to work on primitives directly.