If you see an orthopedic surgeon (the much more common name for this type of doctor in the US) about almost anything you will almost certainly end up with an MRI (good chance your insurance won't cover this fully) and some kind of recommended intervention.
"Most teams haven’t yet figured out how to build their own Ramp Inspect or Stripe Minions (if that’s you, reach out — we can help!) but basically everyone is at least using cursor in the side bar."
It's pretty disappointing that people on this site of all places have no idea what CEOs do. Many of them are certainly overpaid, and like any other profession, many are not good at their jobs, but they aren't sitting around drafting memos and coming up with deciding who to fire all day.
This is probably because the people who feel like they receive the most benefit from LLMs never actually knew much about or were just incapable of writing good software before they started using LLMs.
Receiving an absolute dung pile of half-broken implementation is honestly what I expect from most working software engineers. Now the step where they spend even a second thinking about what they are doing has been removed. My job as a principle engineer became doing most of the thinking for people and then providing the only worthwhile code reviews before LLMs became a thing. LLMs just made these people even less useful and my job became even more about reviewing their low quality work that I could have done in less time manually.
LLMs also don't solve the much bigger problem of most software engineers having no ability to work with others to clarify requests or offer alternatives. So now bad and/or misunderstood requests can be implemented faster.
I was recently considering what these people would do to us if they found a valuable use for part of our bodies. The Matrix was brought up by someone in response.
The interesting thing to me about this example is that it had to be someone lower level in or near the administration with less wealth, but who knew about a military operation. Hard to imagine any of the rich people around him risking a bet for such a small sum.
It is SMS based. Each week they offer a different bean from a different roaster, and you reply with the number of bags you want. I've discovered a number of great roasters this way.
JIRA obviously allows one to customize workflows as well, and I frankly don't really care about the visualization of it. The problem is that at many companies, there is one group that is allowed to change the workflow and they are more interested in conformity than allowing teams to work well.
The problem is that most developers don't not actually understand DRY. They see a few lines repeated a few times in different functions and create a mess of abstraction just to remove the repeated code. Eventually more conditions are added to the abstracted functions to handle more cases, and the complexity increases, all to avoid having to look at a couple lines of repeated code. This is not what DRY is about.