However, could be this was a one-off genuine mistake (things are hectic). I'd love to know more

One such account which is purportedly doing this is https://twitter.com/truthabtchina. To summarize this, among other rumors:

    - lots more people have died that communicated (there's an estimate of ~22m due to missing cell phone contracts)
    - riots are happening between regions where lockdown occurred, and regions next to them)
    - lockdown isn't practically over in areas where resurgence of infection is happening (pending other containment approaches)

I do think it's quite reasonable to assume some areas of China are getting back to normal.

I also think it's quite unreasonable to assume info _isn't_ being censored and controlled, especially post journalist-eviction.

I see the immediate health layer as subject to physical limitation, the economic layer subject to informational limitation. If by resources you mean money, then yes, I very much agree.

I'm _not_ saying we shouldn't help the rest of the world. That's the very next thing. I'm saying, let's make sure we're not drowning before trying to help others not drown.

This is a really weird line of reasoning because I don't think it even holds in the case of a broader unity.

Engineers:

is working [edit: replacing 'under' with 'with' due to replies! good clarification, didn't mean under] with a non-technical product manager a dealbreaker for you? (Do you look to filter out places you'd work at while job searching?)

Conversely, have you ever worked under a non-technical product manager you loved? Would you mind sharing details about your situation?

Yeah - entirely depends on your subdivision vernacular. Some people make subtasks in a ticket, some people make tickets linked to other tickets, some people do both and link those to "features" which are themselves tickets (like the environment I work in).

Just depends!

None of this "button here" "wire it up later" "now add the db table" etc.

People are going to say the user story you listed is _way_ too vague, general, or otherwise "not right" or "something they've never seen." They're going to reject it/pick it apart for a litany of reasons, all of which triangulated against their individual experiences. Me too! Here goes:

I've found "user stories" miss entire dimensions of context from the business side which are incredibly important to developers. In lesser-performing orgs, this is often a way the "business folks" (and yes - in some orgs, there is a distinct divide) wield information asymmetry to pawn off blame onto devs when "things aren't right." This information about how people are really gonna use the software vanishes somewhere along the way before it turns into a user story. This post gets at the heart of it pretty well: https://jtbd.info/replacing-the-user-story-with-the-job-stor... (which, btw, if this makes sense to you, is something you're strangely passionate about, and you're not familiar with "jobs to be done" then go get intercom's free ebook on it right now)

I have another guess. This is less of a prediction, more of a thing I'd like to find out: of all the people who reject your user story, how many of them have worked at places where their product manager isn't a technical person?

My guess is: most of them. I'm also guessing PM's get super specific because developers moan at them over minutiae, info gets cut out/they don't realize it's important, and there you go.

I'm betting most orgs adopt agile as a means of combating poor engineering dept performance, and generally (not all the time - but generally) this is directly due to the people managing the technical people not knowing what they're doing, so it's essentially a set of default behaviors that protect both sides and guarantees some minimum (read: not maximum) of performance. So these product managers who don't understand any development are put in charge of developers consider writing tickets their job, and instead of understanding reality -> reflecting that in tickets, they write their tickets and try to coerce reality to follow.

Frankly, take a bunch of people who already didn't want to change their process, force them to hear "you should update your process that's how things are supposed to be" every day, and after a couple months they actually start to do it.

Ticket shaping is super hard. I don't trust a non-technical PM to do it right, unless they happen to be experienced and/or have devs alongside them who are essentially just doing their job for them. Add onto this the fact that typically management consider all parts of software development a linear process.

Not to say you can't have PM's who are nontechnical, and can bring all the right context/organize everyone in the right ways. I believe they exist, I just haven't worked with any. Devs are generally ineffective at communicating technical context in non-technical ways, and reality is an emergent mix of both business & technical.

this has turned rambly. tl;dr - user stories are such a vague/overloaded concept for so many reasons, if you have the choice read up on "job stories" and try and switch to those. They're no less confusing to implement, but they force you to find answers to much better questions.

Swinging the conversation beyond the dosages of either side doesn't produce interesting insight

I get things done faster and more maintainably (for future me and other devs) when I do it in rails. Hopping into apps that rely on (request, response, next) always hits me with a learning curve every single time I come back to em, which gets worse as complexity rises. It could also be that I'm very bad at thinking in terms of pipes and need to practice that more.

I also find that in rails, there really aren't _that_ many ways to do things. And, in general, apps that age gracefully always figure out how to phrase their domain concepts through the smallest restful url's/resource mappings they need. There's a lot to be learned from the approach the smaller micro frameworks take, and you can get the best of both worlds in a lot of ways.

Crappy garena, banlists, vs 5 ai in wc3 when no internet... :')