> 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.
If someone literally publishes on the internet that they require their employees to act like every problem is urgent, it's not clear why you think we shouldn't take them at their word. It's a pretty common thing for bad managers to expect people to work full-tilt 100% of the time rather than understanding that tends to burn poorly out. I'm honestly not sure how someone could spend a decent amount of time in this industry and not be able to recognize that pattern and have thoughts about how to avoid it unless they just don't really care about it much, so while you're entitled to disagree, it's hard not to get the impression that being so affronted by the parent comment pointing out that the blog post doesn't seem to address the very real pattern of phrases like the article uses being euphemisms for pretty horrible work cultures that you just also don't particularly care about it.
Personally, I've seen far too many talented people in tech be worked too hard for too long by management that either is too clueless or too uncaring to the point where it can take years for their health and happiness to recover not to find it extremely alarming when someone says stuff like "everything is urgent". The likelihood that they mean pretty much exactly what they say rather than mean something more nuanced is high enough that the fact that don't seem concerned about the implication says more than enough.
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"
and similarly, the need for slack in software teams
This principle is basically a movie quote, though.
No it's not, though?
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.