How I Program in 2024

Static vs dynamic typing

• Some argue dynamic languages shine when context is stable and known (e.g., files you know exist); heavy type-checking there feels like overkill and slows development.
• Others praise mature static type systems (TypeScript, Scala, etc.) for catching whole classes of errors, typing DB queries and APIs end-to-end, and dramatically reducing unit-test needs.
• Complaints focus on “fighting the types” and boilerplate in languages like older Java/C#, and cultural issues like bikeshedding in TypeScript-heavy teams.
• Several note that the ideal amount of typing is “small but judicious” and that types, abstractions, and tests are tools, not dogma.

Shell and foundational tools

• Broad agreement that learning at least one shell well pays off long-term, especially for remote work, quick automation, and debugging environments.
• Advice: know when shell is the right tool; don’t build large, complex systems in shell because of its design pitfalls.

Tests: value, limits, and domain dependence

• Many insist automated tests are essential even for solo work: they prevent regressions, enable safe refactoring, document behavior, and reduce reliance on memory.
• Others emphasize domain: UI, graphics, and fast-changing workflows are harder and sometimes less cost-effective to test; small, short-lived scripts may not warrant tests.
• There’s pushback against brittle, over-mocked unit tests and coverage quotas; integration/end-to-end and property-based tests are often seen as higher value.
• Some treat tests as temporary scaffolding that can be discarded after major rewrites; others see this as wasteful or risky.
• A minority claim to never write tests and rely on manual or user testing; this is strongly criticized as offloading cost and risk to users.

Version control and workflows

• Confusion over the article’s “giving up versions”: thread clarifies this mostly means de-emphasizing history/branching and merge-conflict anxiety, not abandoning tools like git entirely.
• Most commenters see basic version control as near-zero-cost and indispensable, even for single-developer projects (history, rollback, branching experiments, multi-machine work).
• Some argue that complex branching workflows and process around VC can add cognitive overhead and shape architecture in suboptimal ways; you can choose simpler usage patterns.

Solo vs team, scope, and constraints

• Many note the article’s philosophy fits solo, small, largely frozen-feature desktop apps, not large, evolving systems with many users and collaborators.
• Several advocate intentionally austere setups (fewer tools, minimal abstractions, data-oriented design, holistic rewrites) as a way to escape local optima and think more clearly.
• Others counter that in professional contexts with paying users, tests and disciplined version control are hard-won practices, not optional niceties.

LLMs and modern workflow

• A few participants describe workflows where LLMs draft significant portions of code and tests, with humans focusing on design, verification, and fixing AI mistakes.
• Some speculate richer types and structure will make AI-generated code more reliable, reinforcing interest in static typing.

Overall reception of the article

• Reactions range from appreciation for honest experimentation and alternative workflows to calling the piece confused, misleading, or “trolling.”
• The most common criticism is that presenting “giving up tests and versions” as a route to a “better program” is highly context-dependent and dangerous if generalized.