Developer's block

Premature optimization & code quality

• Strong pushback against “for experts only: don’t optimize yet” language, but broad agreement that indiscriminate optimization produces unmaintainable “spaghetti” and deadlocks.
• Several argue most worthwhile optimizations are big-O fixes and better DB/RPC patterns; micro-optimizations rarely matter.
• Over-application of “best practices” is described as a sign of insecurity and a major source of messy codebases.

Developer identity: creative writer vs plumber

• Some see dev work as literal writing from a blank page, closer to creative writing than plumbing.
• Others say it depends: working on someone else’s product feels like plumbing; building your own feels like authorship.
• Many frame it as a spectrum: mostly mundane plumbing, occasionally flashes of “brilliant” design; both are crafts.

Breaks, pacing, and corporate pressure

• Multiple commenters endorse taking breaks, listening to the body, and maintaining a “sustainable pace” (reasonable hours, using vacation, real lunch/coffee breaks).
• Others note corporate culture and tight deadlines make this advice hard to follow; learning time often requires explicit managerial support.

Sleep, exercise, and off-screen time

• Numerous anecdotes of going to sleep stuck and waking with a clear solution; sleep is seen as a key “side task” for the brain.
• Walking, hiking, cycling, showers/baths, light chores, meditation, stretching, and short naps are praised as idea incubators.
• Some push back that chronic pain, insomnia, and childcare can make “just sleep and exercise” unrealistic, leading to a mini-argument over empathy vs “generic advice.”

AI/LLMs as anti-block tools

• Many say LLMs are excellent for breaking inertia: generating first-draft code, features, tests, docs, or names, which they then refine or rewrite.
• Some treat AI output as a “shitty first attempt” to react against; others emphasize scrutinizing every generated line to learn.
• Opinions differ on granularity: some ask for “one whole step” changes, others prefer very small, guided steps.

Scoping, structure, and testing

• Defining “done” and explicit quality expectations helps decide what to polish now vs later.
• Reusing boilerplate, infra, and project templates can reduce friction, though some find templates quickly go out of date.
• “Release early, release often” and quickly assembling an integrated but stubby system are seen as powerful for momentum.
• Discussion clarifies “test harnesses” as standalone apps that drive and observe the system under test, complementing unit tests and improving reproducibility.

Concrete tactics for getting unstuck

• Write deliberately bad or throwaway code just to move forward; refactor later.
• Build debugging or logging infrastructure when blocked.
• Switch to simpler tasks (bugs, docs, prep work) or another “mode” (reading, sketching, coding, relaxing) instead of forcing progress.
• Talk through the problem with another person (or rubber duck) to trigger clarity.
• Occasionally switch languages/paradigms to refresh perspective.

Documentation and contributing back

• One point of contention: whether to resist the urge to immediately fix poor dependency docs.
• Some argue deferring doc contributions means they’ll never happen; others prefer to wait until they understand the library better, but still feel a moral “debt” to contribute eventually.