Woodworking as an escape from the absurdity of software

Many software developers describe turning to woodworking, gardening, or other hands-on crafts as a way to cope with burnout and the perceived absurdity of modern software work — from agile rituals and story points to constant tooling churn and linters. Commenters debate whether the core problem is software itself or corporate structures that disconnect engineers from users and meaningful outcomes, with some arguing that better boundaries or smaller companies can restore satisfaction. Several warn against romanticizing trades as an escape, noting that client-driven woodworking or hospitality comes with its own stresses, and suggest treating physical crafts as protected hobbies rather than new careers.

Software estimation, Agile, and “T‑shirt sizes”

  • Big subthread on whether engineers can estimate time accurately.
  • One side: time estimates are inherently bad; unknowns (bugs, external systems, staging≠prod, library issues) make even “1–2 days” vs “1–2 weeks” unreliable. Ranges and “effort” are seen as more honest than “time.”
  • Other side: estimation is hard but not impossible; ranges plus experience can be useful for planning and prioritization. Estimation becomes bad when rushed or politically pressured.
  • T‑shirt sizes / story points: some see them as sensible effort sizing; others note they are always converted back into days, undermining the abstraction.
  • There’s frustration that estimation is treated as a quick guess instead of real engineering work (prototyping, research).

Users, support, and modern software quality

  • Several comments vent about supporting non-technical users and “civilians” who don’t read docs, corrupt inputs, or blame software for process issues.
  • Common feeling: modern software is brittle, overloaded with features, and often user‑hostile; engineers rarely get time to refactor or polish UX.
  • Some are embarrassed to say they work in software because of general app/website frustration in the public.

LLMs and the future of software work

  • Mixed views: some say “software dev as we know it is about to disappear,” others push back, noting LLM limits (data quality, hallucinations, need for careful task decomposition).
  • LLMs help with stable, slowly changing stacks; they’re more frustrating with fast‑moving web tooling due to hallucinated APIs and outdated libraries.
  • RAG and feeding current docs are suggested mitigations.

Craft hobbies: woodworking, gardening, embedded, retro, etc.

  • Many respondents echo the OP: physical crafts (woodworking, gardening, metalworking, sewing, cooking, embedded, retro consoles, small games) provide tangible results, slower pace, and mental reset from abstract software.
  • Strong advice not to “monetize the hobby” if you want to preserve its meditative quality. Professional woodworking and other trades are described as hard, low‑margin, client‑driven work.
  • Some highlight cheap, incremental entry (hand tools, classes, makerspaces); others note real constraints of space, cost, and time.

Big companies, startups, and meaning in work

  • Split experiences:
    • Some find big companies soul‑sucking (layers of management, “cost center” mindset, endless ceremonies) and prefer small, fast‑growing firms or solo products where they see direct customer impact.
    • Others prefer big‑co stability, limited hours, and using surplus time/energy for hobbies and family; startups seen as stressful, underpaid, and chaotic.
  • Recurrent theme: burnout, mid‑career disillusionment, and desire to work on products one would personally use or find ethically meaningful.

Linters, formatting, and “the tyranny of tooling”

  • Large subthread on linters/formatters:
  • Pro‑linter side: automatic formatting reduces bikeshedding, eases code review, and is essential for large teams; style rules should be enforced by tools, not PR comments.
  • Anti‑/skeptical side: rigid rules can harm readability, stifle minor stylistic communication, and feel “tyrannical” when used as hard gates or over‑configured.
  • Some differentiate: formatters for syntax are widely liked; overly opinionated lint rules about structure and style are more controversial.

Broader reflections: work, identity, and balance

  • Many argue the core issue isn’t software per se but corporate culture, bureaucracy, and “bullshit jobs.”
  • Strong support for having non‑coding identities and hobbies to avoid tying self‑worth solely to economic output.
  • Several note the privilege implicit in being able to choose boring but well‑paid work and then “buy back” fulfillment via hobbies; others point out many people don’t have that option.