Comment by infamia
3 hours ago
> Something that people learn quickly when they work with me is that my approach to pretty much every problem is: > ... > 6. Act with urgency to achieve the goal
If everything is urgent, then nothing is. This guy sounds miserable to work for and with. Assuming this is accurate and not just hyperbole, he is essentially saying he has no prioritization skills because everything is urgent. I think most people who have been around the block have worked with people like this, and unbeknownst to them, their coworkers develop a default snooze button associated with most of their requests and projects.
Heavens. Is it possible you're reading into it a bit? He's miserable to work with? From this one blog post?
A more generous read, or, at least the reading I took: "once we (think we) know what we're doing, we violently execute."
So, "boo" on you. This guy sounds awesome.
I was literally writing almost this exact post but decided to reload the page first.
Developers get triggered about managers breathing down their neck when they read things like this that’s why you get such strong reactions.
How often do people that make this kind of assertion end up themselves being the ones that are miserable to be around I wonder
[dead]
> Heavens. Is it possible you're reading into it a bit?
Perhaps, which is why I hedged with the possibility that it is mere hyperbole. However, I think what did it for me was his statement that he provides and expects feedback to anyone not following this recipe, which is at utterly without nuance. Incidentally, you can execute with focus and intention without urgency and arguably be more effective over the long haul.
I disagree, on the principle of "slow is smooth, smooth is fast"
This principle is basically a movie quote, though.
1 reply →
This list also makes zero sense. It says to gather missing information after gathering all known information but before defining a problem. How could you even know what information is missing, much less information that is important, without knowing the problem? And if you're to gather missing information, that you somehow know about, doesn't that make it part of gathering known information? The rest of the list is just as dumb. This list is like a middle schooler was asked to come up with a problem solving framework.
This guy is usually all over threads in which he gets to show off his internal knowledge of Claude Code. I'm sure he'll be here after getting clowned.
The entire Bay Area seems like the most insufferable people known to man. These people have zero introspection.
> It says to gather missing information after gathering all known information but before defining a problem. How could you even know what information is missing, much less information that is important, without knowing the problem?
The post’s description of these steps is reasonable IMO. I’d write it as “put in order the relevant information you have” and “find the information which you know you need but don’t have at hand”.
By way of bad analogy, one could imagine writing up a document first off the top of your head, then filling in more of the document based on the documentation of the relevant systems, corresponding to these two steps the author describes.