Yes, I think this is an anti-pattern is similar to the one I often see, basically getting the order wrong like this:

1. Define the problem.

2. Gather information about the problem.

This seems reasonable. "We need to know what we're trying to solve, not boil the ocean."

But it is really common that the information tells us that the problem definition is slightly or really wrong. Hence the importance of gather information, then define the problem... and iterate.

"First define the problem" also feels reasonable because picking the right problem requires a lot of context and experience. Some would add "taste." So in group discussions, people often suggest bad problem definitions. Others then want to get focus and traction. That impatience often results in committing too early to the problem definition.

Go To Market/Project Management?

> Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.

My last company did this. It usually devolved into a design-by-committee full of compromises to make various stakeholders happy and often yielded a worse artifact.

It became more effective once people got burnt out on the process and most stakeholders stopped caring and started rubber stamping, allowing the one or two people willing to put in the energy to come up with something coherent.

I worked for AWS for several years, eventually leaving during the big "return" to office push because my geographically distributed team working on a product that didn't exist back before the remote period was told we had a month to either move to one of three cities where our team was allowed to work out of our transfer to a team in our area. My wife had an autoimmune condition that would put her at risk if I commuted, so I asked my manager what processes there were for exemptions, but he literally hadn't been told anything by the higher-ups and that as far as he was aware, there were no processes defined at all and we'd have to just try to talk with HR and upper management to try to figure something out. I didn't think that the company expecting me to rush to figure it out when they were the ones who put an artificially constrained timeline on us to either abandon what we had been working on it uproot our lives, so I ended to just giving my notice a couple of days later instead.

My point here is that companies that love to have extremely formal processes around for to handle technical things are not necessarily less likely to have extremely arbitrary decisions without any process for recourse defined when it comes to how employees get treated. If someone describes a technical process that they say they use for everything that a literal reading seems pretty dubious in regards to things like burnout or micromanagement, I don't think it's that crazy to recognize that the reality is probably at least as bad as the obvious implication. Sure, they're not directly saying "I overwork my employees by imposing short deadlines on everything and I nitpick their processes if they different from my own", but there are enough managers who do act this way that it's kind of hard to think someone who cared about being perceived as saying that wouldn't go out of their way to clarify where the nuance is if it truly exists.

I think how important this step is something you realize once you consider the alternative, which is trying to fix a problem, without knowing, what the problem is. It is going to result in weird workarounds instead of addressing the actual issue.

Define, identify, name

[dead]

Fundamentally they just want the best effort>output ratio. You get information about this during exploration (hence "bias to action"), but you can also get information from taking a moment to step back. It's almost as if there is no catch-all rule for problem solving, which is why these posts have limited utility in isolation (but it's nice to be well-read in the area).

Just another instance of him being wrong, i guess. (Which he absolutely, most definitively loves!)

“let Claude figure out what’s going on before doing something”

“then ask Claude to do it fast with no mistakes”

(edited for accuracy)

There’s bugs, and there’s also just a ton of bizarre choices that no human would ever make.

CC (the desktop version) has a built-in terminal. It’s great idea when working with worktrees!

But the terminal is _in the sidebar_. Not as a panel that pops up from the bottom like in… every IDE ever that has this feature, but in the sidebar.

You can drag it to the bottom using tiny drag targets if you want, but if course this only persists for a duration of a single conversation.

And there’s a built-in keyboard shortcut to toggle it being shown/hidden. Again, great idea!

But using this resets the panel to its original position, again, making it appear in the sidebar.

Bonus points: when I tried to submit this via the GUI version of /feedback, it told me that it was disabled by workspace policy _after_ I filled out the form and hit submit. Brother, just hide the button that makes the form appear in the first place!

Users of Claude aren't customers, they are the product (a living training set data generators). The customers are governments and megacorpos.

Ridiculous CC bug I encountered, that others have encountered as well: I asked Fable to review a commit. Suddenly my Fable quota for the week was at 100%, while a moment ago it was at 55%. A few days pass (1 day before the weekly reset) the quota resets back to 55%. ?!?!?!?!

Anthropic never listens to their customers or community. It's basically their culture at this point.

He would, but he keeps hitting his weekly limit. /s Seriously though, you would think they would have the (agentic) resources to do better QA on their flagship product. Not a week goes by without some kind of regression.

Step 1 "Understand the available information" is apparently a hard step.

(I too have been incredulous that this remains an open issue; if this gets it fixed, bring on the boris blog posts!)

He also edits bug titles to reduce the appearance of the severity while not participating in the discussion to explain why.

https://news.ycombinator.com/item?id=48948656

Author here. How can I repro what you’re seeing? Double check you don’t have /focus mode enabled.

[flagged]

Author here. These are unrelated, just happened to both be the same week.

It is a burden all of its own.