Writing toy software is a joy

Joy of “toy” software vs. production work

• Many relate to the core point: tinkering on “toy” code is fun; depending on it is stressful. Once you try to actually use a toy (e.g., invoicing app, finance tooling), bugs, edge cases, and deadlines quickly erode the joy.
• Several embrace having “two bikes”: a playful, breakable toy and a reliable daily driver. Others say they only enjoy software that’s truly useful, even if small and personal.

DIY vs delegating (self‑hosting, SaaS, and cars/bikes)

• Some stopped self‑hosting critical infrastructure (email) because rare but badly timed failures and maintenance overhead weren’t worth it. Others report decade‑long smooth self‑hosting with minimal babysitting, seeing it as essentially “set and forget.”
• Analogies to bikes vs cars illustrate tradeoffs: tinkerer tools (bikes, self‑hosted stacks) are repairable and customizable but can leave you stranded; SaaS and commercial services are less hackable but offer reliability and support ecosystems.

LLMs: joy, learning, and risks

• Strong split: some say LLMs supercharge toy projects, letting them focus on architecture, UI polish, or weak areas (CSS, infra) while delegating boilerplate. Others argue the joy is in understanding, not in “hand‑setting code,” and LLMs can short‑circuit that.
• Many use LLMs as “search on steroids” or rubber ducks: for overviews, reverse‑searching concepts, navigating bad docs, or scaffolding prototypes, then heavily editing.
• Several warn that over‑reliance degrades deep learning and problem‑solving (“easy chair for the mind”), and that LLM‑generated answers can be subtly wrong or biased. Some recommend using them as teachers, not interns, or even typing out suggested code by hand to internalize it.

Scope, difficulty, and value of toy projects

• Multiple commenters find the author’s time estimates (e.g., GBA game in 2 weeks, physics engine in 1 week) wildly optimistic unless you build extremely stripped‑down versions and already know the domain well.
• Debate over “reinventing the wheel”: one camp calls it pointless; many others defend re‑implementing compilers, shells, git, DBs, etc. as powerful learning exercises that later pay off in real work.
• Stories highlight toy projects directly enabling career advances (e.g., understanding pattern‑matching algorithms for a production language; graphics and game engines leading to dream jobs).

Keeping toys simple: stacks, configuration, deployment

• People praise minimal stacks (single binary, few deps, VPS + systemd, rsync) and warn against over‑generic “configuration engines” that add complexity for hypothetical users.
• A recurring theme: to preserve joy, constrain scope (e.g., one week per project), accept 80–90% solutions, and resist turning every toy into production software.