Claude code is actually one of the most straightforward products I've used as far as onboarding goes. You download the tool, and follow the instructions. You can use one of the 3 plans, and everything else is automatic. You can figure out token usage and what models and versions to use and how to use MCP servers and all of that -- there's a lot of power -- but you don't need to do ANY of that to get started trying it out.

You're not being:

> That critic who doesn't try the stuff he criticizes

You're being:

> That critic who is trying to confirm their biases

Just to be very clear, since it actually matters... this is an executive order, not a law. No one voted on it, it was just declared to be true.

Have you ever worked at a place where the sales people promised features that didn't exist? A bad sales person can ensure you're in the trenches doing work that is urgent but not important. A good sales person anticipates requirements, identifies when they're not currently available, and proactively works with the right people to get the important features prioritized strategically.

The sales people talk to the customers, so from a certain perspective they're the ones in the trenches and talking to customers while you're in the back office plugging away at a keyboard.

The likelihood of things breaking or behaving in unexpected ways are data points I think about when assessing risk irrespective of whether an API is public or not. In some industries even the public APIs are more risky than using the unofficial Venmo API likely is.

In my experience this problem tends to be caused by heavily mocking things out more so than the unit tests themselves. Mocking things out can be a useful tool with its own set of downsides, but should not be treated as a requirement for unit tests. Tight coupling in your codebase can also cause this, but in that case I would say the unit tests are highlighting a problem and not themselves a problem.

Perhaps you're talking about some other aspect of unit tests? If that's the case then I'd love to hear more.

Some are trying to see you fail. They're looking for a reason to say "no". They tend to not be of any help on a problem, will often try to find ways to trick you. They also tend to have an ego problem -- you need to prove to them that you're worthy of joining the team.

The other class of interviewers are those that want you to succeed. They will answer questions, and help clarify things. Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work. People that shut down when they get nervous tend to open up to these interviewers. They also tend to be the people that are more pleasant to work with.

> Similarly, the work OP is doing may be much less important than they think it is.

For the record I fully acknowledge that this may not be possible and they very well may need to work within the system in a less-than-optimal state. Understanding the root of the problems help you navigate and ideally enact change even if it's more localized.

You've explained away the crux of the problem without even identifying it as a problem. Queues are an inappropriate construct for managing work. If something urgent & important takes weeks to even get looked at then there is a prioritization problem. If something that isn't urgent or important even gets worked on at all then there is a commitment problem. Based on what OP has described, the company is likely doing a lot of work they shouldn't be doing and working on things in the wrong order. Similarly, the work OP is doing may be much less important than they think it is.

Now, I agree that it's important to understand how the system works, but IMO it's equally as important to understand how it can be improved. Long lead times is definitely not a good thing, and also not a foregone conclusion at big companies.

OP was commenting on why there may not necessarily be a causation, and you commented on how the doctors tend to think there's a correlation. It just as well could be that schizophrenia tends to lead to increased marijuana consumption as people are self medicating. I'm no expert, so I don't have any strong beliefs around causation, but I do think both lines of thought (marijuana causing schizophrenia, or vice versa) seem pretty logical to me.

It's pretty widely believed that there is a correlation between the two, but the reason behind the link is where there's a lot of debate.

I suspect there has always been pressure to not leave your baby with someone else and go off and do your own thing. The difference is now people are physically more distant from everyone else (I blame the ease of transportation) so being around close friends and family is the exception and not the standard.

If you want to get really technical, you also need to consider the number of people playing. When the jackpot gets extra high more people tend to play, so the likelihood of having to split a jackpot (which happens all the time) becomes higher. Without doing the math I would guess EV of the return is rarely ever greater than the cost of a single ticket.

10x is 100 times bigger than 0.1x FWIW.

> but I argue that it is at least partly due to the prevailing code-base.

Its almost exclusively because of the prevailing code-base. We can't forget that the prevailing code base was built by developers of varying skills. You can have "100x" developers build it or you can have "0.1x" developers build it.

> One of my least favorite people to work with is also a "high throughput" developer who is a prolific creator of software, but everything created by this person is an un-maintainable, un-documented, un-tested, brittle block of procedural copy-pasta that ends up in the critical business path. And yes, this developer "snapped" about a year ago and it has been a 3 person project ever since to scramble to fix this stuff.

Was this person the aforementioned "Rick" from this article?

Often that is the case, but sometimes you reach a point where you ultimately need to guess, but you can make an informed guess based on the number of mines remaining. Then the question becomes, is it worth guessing and potentially losing faster, or are you having a really good game and want to risk losing late in the game?