It may seem like it, but no engineer writes "right" code on the first try. They get it working, then they iterate, cleaning it up to make it "right".<p>Experience teaches us where to start, where to think ahead a little, and how to structure code such that it can be refactored in the future.<p>Writing code the "right way" means 1) getting something working 2)taking what you've learned and refactoring and/or.<p>If you care about maintaining a chunk of code for 6 months, or a year, you'll quickly learn to refactor. If you are prototyping, right likely isn't a priority to begin with.
If you build it they might come. If you don't build it they can't come. Therefore you must build it for them to come. Therefore the most important thing you do to make them come, is to build it by any means necessary.<p>Them of course means customers.
Most of the code I write at work is just automating processes and I usually do it piecemeal until managing it all gets too unwieldy then I refactor and simplify. I'm not exactly building one to throw away, but I'm using a lot of essentially placeholder code that I know I'm going to replace with a more coherent system once I see the pieces working together. Sometimes the quick and dirty stuff is good enough and I never need to touch it again, though.
> Twenty minutes of debugging later, it turns out I’d forgotten to call .show() after creating a Toast.<p>It amazes me that people still think that strong typing isn't useful.