sillyquiet

no, its not. Not in any white collar professions, not in any blue collar jobs, not in the military, not in academia.

You are only safe when you don't have bosses and all responsibility and power rests on yourself.

> but that argument depends on assuming we have a complete archaeological record, which we of course do not.

In other words that argument depends on the available evidence rather than speculation, like, you know, how science should be done.

Just because they don't mention this not-widely-accepted hypothesis you're going to dismiss it? Ok.

Eat your own dogfood right?

See also the trailers for "Predator". Movie is still fantastic, but plays out so much better if you don't know the nature of the predator.

I gotta say that your distinction between 'hackers' and 'developers' is pretty ill-informed - just out of curiosity, have you primarily worked in start-ups?

Sprints when used correctly are invaluable to a development team. Source: My own experience as a junior dev and a lead dev on teams working in this methodology.

Note it's not useful in all (most?) scenarios or in all stages of a product's development.

When you are in support mode for a product that's stable, standing up something from scratch, working on a POC or experimenting with frameworks or libraries - it's not useful, use kanban or something else.

But when you are working on a/b tests or adding features to an existing product it's extremely useful.

When done correctly: You get a two-way promise between leadership and a dev team. The dev team commits to getting stuff done within that <sprint-length> time - therefore they must carefully decompose work where that makes sense. Leadership commits to LEAVING THE DEV TEAM ALONE for that <sprint-length> time - no priority changes, no "Product Manager Chad had a dream if we implement X we get 1000% more revenue!", none of that nonsense. This means for bigger efforts, you get <sprint-length> chunks of working code "done" at time. This in practice means the devs drive how much they can get done in a certain amount of time - if a PM wants an earlier date out the door, that's <x> fewer sprints of decomposed work that gets done.

The tricky thing here is the use of the term "correctly" above. Sprint-based methodology isn't a tool for management to dictate or predict performance and it's not a tool to micromanage tasking. If leadership DOES have this distorted view of it, then it is useless overhead to no benefit for anybody.

It's also not useful at all if only the dev teams practice it - everybody has to respect the commitments required to do sprint correctly - if they don't, use kanban or something else.

So... developers aren't productive?

This is a weird take.

My mother-in-law was a nurse at an orthopedic surgery center. She always said the major classes of patients she saw were:

1. old folks getting joint replacements 2. young athletes 3. middle aged construction workers or laborers

Way too early. From the dates, its more likely to be Roman sailors and/or Roman-affiliated traders.

Blind being the semi-toxic mess it is, I could see this being true, but I could also see this as an epic troll.