CSMastermind

Engineering hours are finite, so if they're spread across interpreting signals from two different sources, they might not go deep enough to make either one as good as it could be.

Having your engineering resources more focused on a particular approach might actually yield better results.

I say this as someone who's dealing with LiDAR + vision vs pure vision in a different domain, and at this point, I actually think our pure vision systems are better.

I'm also completely fine if it gives me hold mustic while it's working.

Would make my walks much more productive.

Onboarding my non-software engineer teammates to it has super-charged them and essentially given them all their own personal developer that can automate tasks for them. Managing codebases, etc. is still a hassle though.

90% of the power of Excel was that it was functionally a database that a normal person could actually use. I think we'll see something similar with coding agents.

All software is actually a state machine and almost all complexity comes from unmanaged state transitions. Especially if you have errors, concurrency, async actions, and distributed systems.

The most important task any software architect has is defining how you know what is true about the system.

Consider a few examples:

await sendEmail(); await saveUser();

That's obvious right? Well what happens when saveUser fails and some retry sends a duplicate email?

---

If you're relying on a webhook to let system A know when system B has changed things, what happens when that failed and now the two systems are out of sync? This is why event-driven architectures often work well: they externalize state transitions.

---

A classic React problem, you define state like this:

``` const [loading, setLoading] = ... const [error, setError] = ... const [data, setData] = ... const [isRefreshing, setRefreshing] = ... ```

Now there's all sorts of invalid states you can be in. Like "loading true, data true, error true".

**

You should strongly prefer: state machines, lifecycle enums, event logs, immutable events, append-only histories, strict versioning, idempotency keys, and explicit workflow stages.

You should avoid like the plauge: hidden globals, timing assumptions, inferred behavior, synchronization, side effects, boolean explosion, mulitple sources of truth.

Event sourcing, CQRS, Redux, Kafka, workflow engines, finite state machines, transactional outboxes, CRDTs, database normalization they all do the same thing _control where the state lives_.

- Good design is a single idea pervaded throughout.

- More generally, your goal should be to minimize surprise.

- If your system allows it, people will do it.

- Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution.

- Isolate the parts of your system that transform data from the ones that use it. Data models outlive code.

- Coupling is the root of most evil.

- Versioning is inevitable.

- Make state explicit.

- Every piece of information should have a single source of truth.

- You should spend more time thinking about naming things correctly.

- If testing is difficult, the design is wrong.

- You will regret every undocumented decision.

- Communication is a tax that you should justify before paying it.

Remember that the job of an engineer at any level is to use rules of thumb to solve problems for which there is incomplete information.

Apparently, he's the reason tennis balls are yellow.

I guess they were traditionally white but when they started broadcasting matches on TV it was too hard to see the ball.

David who was at the BBC at the time suggested they use yellow balls instead so they would come through on camera. Ever since then tennis balls have been yellow.

He had a habit of seeking out and documenting mathematical problems people were working on.

The problems range in difficulty from "easy homework for a current undergrad in math" to "you're getting a Fields Medal if you can figure this out".

There's nothing that really connects the problems other than the fact that one of the smartest people of the last 100 years didn't immediately know the answer when someone posed it to him.

One of the things people have been doing with LLMs is to see if they can come up with proofs for these problems as a sort of benchmark.

Each time there's a new model release a few more get solved.

So this is proof of the models actually getting stronger (previous generations of LLMs were unable to solve this one).

I'm simplifying things quite a bit, but almost all military contracts are 8-year (typically split into a 4-year active and 4-year reserve period). If you leave on your own volition during this period, you typically have to repay the cost to the government to train you. And any contract that you're on where you received a signing bonus you have to pay back.

The actual mechanism for doing this is a different between officers and enlisted and they're some paperwork but functionally you can leave if you're really motivated to and for the most part people won't stop you (outside of a few conversations where people advise you against it).

The type of discharge you receive depends on the circumstances but generally there's a way to still get an honorable discharge (hardship, education, family, conscientious objector).

There's also the more practical quitting special forces vs leaving the military entirely. Tier 1 units only want people who want to be there and if you don't you can get transferred to some other job in the military in like a day if you really wanted to.

Oh just like a real developer

With that said, the automation of law enforcement is deeply concerning to me. I'm of the opinion that most of our laws are calibrated based on enforcement costs that are simply being removed and it's going to fundamentally transform society if we continue to automate in this way.

Both happened after they kicked journalists out of the Pentagon and I have to think that it played at least some role in the secrecy.

The earlier strikes on Iran's nuclear facilities before the change were leaked, though not the details of the mission, just that they were happening.

Increased supply lowered prices for the same levels of demand?

Seems unlikely.

Reporting also contains narrative explanations by management of: the company's financial health, updates on any new or existing market risks and the company's strategy to deal with them, any changes to controls or accounting procedures, updates on any new or existing litigation, and more.

These reports need to be certified for truth by the CEO, CFO, and relevant officers under penalty of 10+ years in jail and millions of dollars in fines personally.

It's also common to do a press release, earnings call, and investor presentation but those aren't required.

If you listen to the government officials explain the situation:

All this began after the Maduro raid, when executives from Anthropic allegedly called an intermediary vendor, Palantir, seeking specifics of how their software was used. Because this is classified information, Palantir refused to disclose it, which led to Anthropic threatening to shut off service to Palantir. Palantir reported this to the pentagon who then contacted Anthropic directly.

Obviously, the military can’t have Palantir’s services suddenly stop working mid-operation because one of their suppliers objects to it. So they can’t risk having Claude anywhere in the supply chain.

Assuming the government isn't lying, then the designation is completely and entirely appropriate. You can substitute out any other vendor, and they'd receive the same treatment.

I assume it's for political reasons because they dislike the current US administration, as all of the government's claims that I've seen have been completely reasonable, and their actions justified.

Resist everything the Trump government does, whether it's good, bad, reasonable, or indifferent, is just a viewpoint that I find shortsighted.