It depends a lot on your mentality toward writing code. I find matching the long/short-termness of engineering practice to the overall mentality of the organization results in the least friction.
Concrete example: if you're building a system to last 5-10 years, act like it. Spend time getting the architecture, the variable names, and the module structure correct. But realize not everything must be built to last. I read somewhere else on HN that some groups inside of Google plan a piece of code to handle 10x growth in traffic/storage/resource use before it's thrown out outright and rewritten -- so don't overdesign.
Maybe the real lesson is to invest in sufficiently good modularity that it's easy to throw things out without too much pain. Nothing lasts forever.
I can't find the reference but my rule of thumb is actually to build for 10x and design for 100x. That is to say if my service is now processing 1k requests/s I'd like the capacity for 10k requests/s and I'd like the existing architecture to be scalable by adding more nodes up to 100k requests/s.
Concrete example: if you're building a system to last 5-10 years, act like it. Spend time getting the architecture, the variable names, and the module structure correct. But realize not everything must be built to last. I read somewhere else on HN that some groups inside of Google plan a piece of code to handle 10x growth in traffic/storage/resource use before it's thrown out outright and rewritten -- so don't overdesign.
Maybe the real lesson is to invest in sufficiently good modularity that it's easy to throw things out without too much pain. Nothing lasts forever.