stoops

Nah. I know a very successful, multi-time Founder/CEO who won't schedule meetings before 10:30 because he doesn't like waking up early. He'll accept meetings with VCs as needed, but then complain to us about it if he has multiple in a week or a particularly early one (8am).

It's comforting, as I'm the same way. I'd rather work 10-10, than 8-4.

A pragmatic interpretation of this is to:

* subclass or compose String whenever possible. (Id, Name, Address, AddressLine1)

* subclass or compose Number/Matrix types whenever possible (e.g. Users, Packages, Widgets)

* Use immutable collections (e.g. Google Guava library in Java)

I have built very powerful software with small teams using these principles.

At scale, your day to day programming becomes easy as the compiler is doing all the error checking.

It is also very slow to program this way. You write A LOT of boilerplate, and there's only so many code-generation libraries you can throw at it before it becomes a pain to setup your IDE.

But it is worthwhile for complex applications. We did not have bugs.

This is really interesting. For systems programming, files usually have clear ownership and modification context. If I call exists(), it should still exists for as long as that thread is paused.

It's an anti-pattern to throw errors for expected behavior.

I love math.

Thank you for the beautiful explanation.

I wrote a paper on this a number of years ago. Here were my primary sources:

https://arxiv.org/abs/cs/0007021

https://arxiv.org/abs/1203.1895

I believe the second depends on the first.

This exemplifies why I quit my last job.

But primarily,

"We promote engineers and managers when they have demonstrated that they are consistently performing at the next level. Promotions don’t unlock new responsibilities; the new responsibilities and increased scope come first and then we recognize it with a promotion."

Every discussion I had with my manager, my promotion was six months away, despite IC contributions exceeding the sum total of the rest of my team when measured per-project via our number one KPI: annualized cost savings (larger org was seen as a cost center).

Unfortunately these "principles" are becoming harder and harder to avoid.

Thank you for this comment. I will withhold any future donations until I do further research.

Sounds like that person doesn't really understand that NASA is a political entity and the Public Relations of an ongoing successful mission is more valuable long term than more scientifically pragmatic experiments in the immediate.