[nemaar]

I really believe this is the only way you can write good software. It's mind blowing to me that most people try to "figure out" the problems before seeing what it actually is. I always feel strange when someone is writing a "study" by reading the documentation of some API or even worse, by reading someone's feature request. The writer of a feature request usually knows even less about the whole thing and really did not think things through. We need tools and programming languages where you can create really dirty but working solutions and make it iteratively better. You need to find all the edge cases and pitfalls and for that you need to fail. Of course you need to fail fast, this method does not work if the iteration is slow and the thing is in production when you find out that it barely works.

[mike_hock]

Where do I go to get paid to actually put in the TIME and effort required to produce something elegant and high quality?

[nothrabannosir]

As a contractor working on project basis, who can leverage this technique to produce code of such high quality that a commensurate price can be commanded.

You’d need to find a niche that values this level of quality, but if that exists, and if the theory is true, then there’s your gold.

[splittingTimes]

Love to see that magical place.

I come to think that the whole concept of MVP/prototype became a bane to software development when the management/business side got aware of its existence. Architecture and design sessions can be skipped because we just build a prototype.

I have yet to see a prototype that did not end in production. It's "good enough software", let's move to the next feature.

When you are really lucky you can revisit your prototype a year or two later and try to improve it's design now that you got some data on its actual usage, but you have to figure out again, what the heck you actually did...