I’m a bit skeptical, there’s a reasonable amount of passed-down wisdom I’ve heard claiming (I think justifiably) that
If you write messy code, and say “I’ll clean it later” you probably won’t. So insofar as you eventually want to discover something others build upon, you should write it clean from the start.
Clean code leads to easier extensibility, which seems pretty important eg if you want to try a bunch of different small variations on the same experiment.
Clean code decreases the number of bugs and the time spent debugging. This seems especially useful insofar as you are trying to rule-out hypotheses with high confidence, or prove hypotheses with high confidence.
Generally (this may be double-counting 2 and 3), paradoxically, clean code is faster rather than dirty code.
You say you came from a more SWE based paradigm though, so you probably know all this already.
Yeah, I agree with all this. My main differences are:
I think it’s fine to write a messy version initially and then clean it up when you need to share it with someone else.
By default I write “pretty clean” code, insofar as this can be measured with linters, because this increases readability-by-future-me.
Generally i think there may be a Law of Opposite Advice type effect going on here, so I’ll clarify where I expect this advice to be useful:
You’re working on a personal project and don’t expect to need to share much code with other people.
You started from a place of knowing how to write good code, and could benefit from relaxing your standards slightly to optimise for ‘hacking’. (It’s hard to realise this by yourself—pair programming was how I discovered this)
I’m a bit skeptical, there’s a reasonable amount of passed-down wisdom I’ve heard claiming (I think justifiably) that
If you write messy code, and say “I’ll clean it later” you probably won’t. So insofar as you eventually want to discover something others build upon, you should write it clean from the start.
Clean code leads to easier extensibility, which seems pretty important eg if you want to try a bunch of different small variations on the same experiment.
Clean code decreases the number of bugs and the time spent debugging. This seems especially useful insofar as you are trying to rule-out hypotheses with high confidence, or prove hypotheses with high confidence.
Generally (this may be double-counting 2 and 3), paradoxically, clean code is faster rather than dirty code.
You say you came from a more SWE based paradigm though, so you probably know all this already.
Yeah, I agree with all this. My main differences are:
I think it’s fine to write a messy version initially and then clean it up when you need to share it with someone else.
By default I write “pretty clean” code, insofar as this can be measured with linters, because this increases readability-by-future-me.
Generally i think there may be a Law of Opposite Advice type effect going on here, so I’ll clarify where I expect this advice to be useful:
You’re working on a personal project and don’t expect to need to share much code with other people.
You started from a place of knowing how to write good code, and could benefit from relaxing your standards slightly to optimise for ‘hacking’. (It’s hard to realise this by yourself—pair programming was how I discovered this)