lojack

> This post is a <insert-startup-here> advertisement

same thing you said but in a different context... sir, this is a hackernews

Lets see: We have GitHub, and GitHub Enterprise Server, and a GitHub API. Then there's the command line and a desktop version, and one that is just browser based I guess. Then you have different pricing plans, Free, Team, and Enterprise? How is Enterprise different than GitHub Enterprise Server? It's very easy to find evidence to confirm our bias.

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

Definitely not a prompt and pray type thing, though you can do that if you choose. It shows its work, in the newest version there's three modes (planning, executing, auto accepting edits). You can also hit Esc at any time to redirect as you see it going in the wrong direction.

> The reason for this law is simply to bring the various agencies under executive authority in line.

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.

> In every place I’ve worked, outside of independent contracting, the sales person didn’t do the trench work.

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 first time I had the plug pulled on a public API a product I worked on used sucked pretty bad. At this point its happened to me so many times that its just another line item of business risks thats an inevitability. I've never worked at a company that failed to recover as a result. Then again, I've never worked at a company whose entire business hinged on one single API.

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.

> Anyone who's ever had to work on a system that had copious unit tests deep within will know the pain of not just changing code to fix a bug, but having to change a half-dozen tests because your function interfaces have now changed and a healthy selection of your tests refuse to run anymore.

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.

As with all music recommendation engines, I want the ability to remove things from the mix. I have zero interest in music similar to Kidz Bop, it's just something I happen to play for my kids.

Interviewers tend to have one of two different mentalities...

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.

but is a traditional database cryptographically secure? if a super user with write permissions (or, say, direct access to the physical data store) modifies records are users able to validate the integrity of the data?

I also said:

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

Good leadership that sets clear direction and initiatives followed by good middle management that takes these initiatives and disseminates it into something relevant and actionable by the teams doing the work. If you're lacking this then its worth trying to ask for this information to help inform your decisions.

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.

> is probably one request in a long queue of requests that team is dealing with

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.

correlation != causation

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.

Does removing PII preclude data from being surveillance?