The Failed Commodification of Technical Work
Attempts to turn software development into an assembly-line commodity keep colliding with the messy reality of complex systems, shifting requirements, and creative problem‑solving. Commenters note that many low-level tasks and tools (from mail merge to cloud infrastructure) have been successfully standardized, but this mostly pushes remaining work higher up the stack, where domain understanding, good judgment, and clear requirements matter even more. The result is tension between managers seeking predictability and plug‑and‑play solutions, and practitioners who argue that treating programmers, data work, or even medical practice as interchangeable factory labor often leads to brittle systems, failed projects, and hidden “grunt work” rather than real efficiency.
Scope and Limits of Commodifying Technical Work
- Many commenters agree some “technical work” has been successfully commodified: mail merge, basic bookkeeping, simple websites, WYSIWYG editing, hosted email, etc.
- The consensus is that the remaining work is less about wiring libraries and more about requirements, design, and domain understanding, which are harder to standardize.
- Several argue the low‑hanging fruit of commodification is largely gone; further abstraction pushes problems up the stack and increases the need for specialists.
Grunt Work, Complexity, and New Roles
- Some expect automation to reduce grunt work; others claim total grunt work stays roughly constant or grows, just shifts to new layers (DevOps, SRE, Cloud*, data roles, manual ops in big orgs).
- New technologies both automate old tasks and generate new routine tasks and integration burdens.
Low‑Code, SaaS, and SQL-Abstraction Skepticism
- Strong skepticism toward tools that “remove the need to code,” especially SQL abstraction layers and BI drag‑and‑drop tools.
- Common pattern: abstractions help for simple cases but leak complexity on non‑standard needs, forcing experts back to the underlying tech.
- Some note SaaS products that don’t yet solve real customer problems, instead using early adopters’ use cases as unpaid R&D.
AI Tools and Learning
- AI coding tools are compared to low‑code: they can generate boilerplate but don’t remove the need for problem‑framing and integration.
- Several report AI-generated code that references non‑existent packages or glosses over the hard parts.
- Concern that widespread AI use may erode junior learning by encouraging “answer‑copying” rather than understanding.
Factory vs. Craft: Process Debates
- One camp emphasizes programming as a craft akin to bespoke carpentry: best learned via apprenticeship, ill‑fit to full Taylorist “factory” treatment.
- Another camp notes that parts of software work are repeatable and should be systematized, standardized, and managed like production.
- Phoenix Project / Scrum / Agile practices are hotly debated: some see them as useful lightweight structures for repeatable work; others experience them as dehumanizing, performative bureaucracy that ignores the intrinsically exploratory nature of most development.
Management, Tools, and Organizational Debt
- Recurrent theme: leaders treat complex software and org problems as appliance purchases (Workday, EMR, CRM, ServiceNow), underestimating customization, maintenance, and domain modeling.
- Organizational structure itself is described as a kind of tech debt that no tool can fix; misalignment between business expectations and software reality drives many failures.