It's never 1 vs. 2-3 days, the unit is rather months and years than days. Besides it's much more complicated than such an analogy can explain.

Sometimes you need to test some ideas. Then you focus on building a prototype that just "works" as soon as possible, so you can test. I've spent so much time wasting months and years building products that were just decided not to be launched at all at the end. It's a shame, but mostly not of programmers but managers...

Sometimes you have to make sure to get into market at the right time. Sometimes you have a pressure of a delivery for a client, sometimes you're competing and sometimes you have end-consumers that terribly need a feature...

It's always context-dependent.

First of all, of course there's standards but "quality" is relative. How do you measure quality? Is premature optimisation quality?

Nonetheless, time is easy to measure.

But I think fast & quality code is also possible, by selecting right open-source tools and not inventing the wheel, doing the right architecture from the beginning, and not having a co-developer who wanted to just learn and experiment a "cool" but super-unnecessary framework. Yeah, it's possible but rare, and not so often that hard...

I care far more about quality code that is easy to maintain, and easy to pick up (for new team members). Optimisations can always be added to easy to maintain code, but if you have optimised early it can make it difficult to maintain or for someone to pick up. Unless I know why I need to optimise something, I'll always go for quality.

I usually prefer fast code first. The keywords being _usually _and first.

Most companies, especially smaller ones, want their product to work. However, on the long run, they also want it to be maintainable, optimal, etc.

As a lead developer of a startup company I expect my colleagues to write working code first, with tests at least for the so called happy paths. However, all such code must have a follow-up where they have to add tests for edge cases, optimise it for speed and memory consumption, etc. so we don’t make regressions later.

Deadlines are our enemies but untested code is the enemy within, more dangerous than anything else.

Most companies want both at once ;)

In reality companies need a balance of stables and volatiles. If you only have volatiles you'll eventually crash and burn. If you only have stables you'll ship too slow and too late.

When there's no balance things go really bad. You get people frustrated at the lack of pace from all these damn rules; or pissed off at having to constantly clean up after the cowboys shipped barely-functional crap again. (one of the many dilemmas CTOs face..)

The best result is probably for people to be able to treat stable and volatile as roles - know when to push and cut some corners, know when to go back and tidy up, always respect each other for playing those roles. Hard to do.

I'd hire someone who can do both.

Sometimes, especially in the initial phase of a project, you need quick code to test ideas. Once you figured stuff out later on, however, you need quality code and documentation.

It really depends on the situations and the stakes involved. Id the project is late, most of the time clients dont give a hoot about how well document the code is if their "paid for" requirements are not done. Most of the time its best to have it working in the best you possibly can and have regular code reviews. that way you dont have angry clients and also you have clean code.

Depends on the project.

A lot of startups and even larger businesses create experimental products that require fast, sloppy code to cut down costs. Rather than having well-documented code that'll get scrapped in a week anyway after the MVP fails, or the product is so simple it doesn't need to be architected -- just assembled crudely.

Then you have gigs where you work on an existing product pushing new features to it, and those require more documentation to ensure people down the road know what happened to the main pipeline.

It's all part of the pyramid of quality. You can either have something that works great, takes no time at all, but incurs great costs -- or sacrifice one for the other. And usually, people don't want to sacrifice time or cost, so you'll find that the quality dwindles greatly.