Spent a while helping PhD friends untangle their simulation codebases, and the same problems keep showing up regardless of field — physics, comp bio, chemE, doesn't matter:

1. No separation between config and code. Parameters get hardcoded into the script, so every new experiment means editing source files directly. Six months later nobody remembers which version produced which result.

2. Parallelization bolted on as an afterthought. MPI/multiprocessing code gets duct-taped in after the serial version already works, so it's fragile and undocumented. Nobody else in the lab can touch it.

3. Zero reproducibility guarantees. No seed control, no environment pinning, no run manifests. A result from March can't be regenerated in September, which is a real problem at review/rebuttal time.

4. Visualization as a one-off script per figure. Every plot is its own throwaway file instead of a pipeline that regenerates all figures from a single source of truth when data changes.

None of this is really a 'science' problem — it's an engineering problem that eats weeks of PhD time that should go toward the actual research question.

If you're setting up a new simulation project, worth spending a day upfront on: a config-driven entrypoint (Hydra/YAML), a thin parallelization wrapper you don't touch again, a run manifest that logs seed/git-hash/params per run, and a figures/ pipeline that's just a function of your results directory.

Built this pattern into a set of starter templates after doing it manually too many times — happy to share specifics if useful to anyone here.