Simple Thread

> My top theory is just that it's convenient for management purposes. That company's are bad at assessing progress, that we're afraid of situations that aren't ultra-well scheduled & predictable, and that we treat programmers like cogs in a machine because we're too afraid to try for better.

This is because the classical consecrated need for project management. Back in the day, you would have factory workers overseen by managers to a) establish a process for the work to be done which is easy and precise - "plan the work" and b) oversee it - "work the plan". The process is, in their view, necessary so why question it?

SW development is a creative process which doesn't really lend itself to rigid guard railing of classical project management.

Some advocates outright speak against managers because of the penalty the rigid process has on creative throughput.
Quote from https://www.simplethread.com/agile-at-20-the-failed-rebellion/ :

> The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning. For example, Ken Schwaber was vocal and explicit about his goal to get rid of all project managers – not just get the people off his projects, eradicate the profession from our industry.

From what you said: Not looking at code is bad, not because Claude can slip a few bugs (it can), but because LLMs tend to default to writing more code and features than needed, which isn't a good thing. I see a lot of people making 10+ PRs per day, but most of them are just going back to fix earlier PRs.

Claude always likes to "go big," for example, by choosing tools that can support millions of concurrent users or by adding unnecessary layers of abstraction that create more maintenance pain. I guess that's good for LLM companies, since more tokens are spent fixing the mess it caused.

Every time I enter plan mode for a huge feature, I end up cutting about 30-60% of the task scope before the LLM can actually start the work. I review the final code, and I still find things to cut. As said before "The best code is no code, or code you don’t have to maintain" [0]

0: https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

Note that context and useReducer do _not_ completely replace Redux.

See the following resources for more details:

- Mark Erikson - Reactathon 2019: The State of Redux (https://blog.isquaredsoftware.com/2019/03/presentation-state-of-redux/)

- Mark Erikson: Redux - Not Dead Yet! (https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

- Dave Ceddia: React Context API vs Redux (https://daveceddia.com/context-api-vs-redux/)

- Mike Green: You Might Not Need Redux (But You Can’t Replace It With Hooks) (https://www.simplethread.com/cant-replace-redux-with-hooks/)

- Sergey Ryzhov: From Redux to Hooks: A Case Study (https://staleclosures.dev/from-redux-to-hooks-case-study/)

- Eric Elliott: Do React Hooks Replace Redux? (https://medium.com/javascript-scene/do-react-hooks-replace-redux-210bab340672)

- Chris Achard: Can You Replace Redux with React Hooks?](https://dev.to/chrisachard/can-you-replace-redux-with-react-hooks-20gm)

In contrast,

https://www.simplethread.com/cant-replace-redux-with-hooks/
https://daveceddia.com/context-api-vs-redux/
https://medium.com/javascript-scene/do-react-hooks-replace-redux-210bab340672

TL;DR Context can replace some but not all of Redux. Redux can figure out which components to rerender based on what's being computed. Context doesn't, so it's basically the same as refreshing your entire component tree every time something changes. You could build it yourself, but at that point, you're just reinventing Redux.

I also like the Redux Toolkit (https://redux-toolkit.js.org/) which is an opinionated way to write Redux that cuts down the boilerplate a lot. createSlice is easily one of the best features, you can encapsulate Redux logic for each different type of content, like authentication, users, posts, etc.

I'm interpreting "creative and fun" as either synonymous with "overly clever" (which is hard to read, hard to debug, and hard to maintain [0][1]), or written a non-standard way just for the sake of being different. For example, here's a collection of FizzBuzz solutions[2]. Most of these are incredibly unreadable.

[0]https://www.simplethread.com/dont-be-clever/

[1]http://www.delabs.io/clever-code-is-bad-code/

[2]https://ditam.github.io/posts/fizzbuzz/