да нету подхода сразу хорошо писать

хотеть только можно

С моей точки зрения если человек работает инженером, получает куеву тучу бабла и не может СРАЗУ сделать отдельный модуль для функции которая явно нарушает single responsibility - нало его сцаными тряпками гнать

И так далее по списку

Можно писать сразу приемлемо. вот только толь не все умеют, толи не хотят

Если тебе надо сделать сперва foo а потом bar, и вместо того чтобы сделать

fn main
  foo
  bar

ты пишешь

fn main
  foo

fn foo
  do_smth
  bar

То надо гнать сцаными тряпками сразу

Качество ПО определяется удовлетворением конечного заказчика от его использования, все правильно. Все остальное это личные проблемы программистов, как им удобнее этого добиться - с тестами или без.

Это если не делать поправку на риски, считая, что заказчик не перестанет быть довольным из-за непредвиденных обстоятельств.

Точнее, что софт не перестанет ВНЕЗАПНО работать, и заказчик не станет ВНЕЗАПНО недовольным

Риски тут обоюдоострые. Можно так зарыться в тестах и перфекционизме, что перестать успевать вносить изменения с удовлетворяющей заказчика скоростью.
Ну а насчет переставать работать - массово тесты пошли навскидку лет 15 назад. До этого делали все без тестов и как-то работало. В банках эти их майнфреймы с коболом вообще без всяких тестов работают уже многие десятилетия. Так что _просто_ надо не делать ошибок при программиовании.

ну то есть какиой-то контроль качества в любом случае проводится самими программистами, но это не обязательно тесты.

Страна хакеров

Короче теоретически есть наверное подход когда ты просто гонишь, но помоему в этом и разница между школьником и человеком работающим за бабло, что можно делать более менее нормально не теряя в скорости разработки

Тесты хрен с ним, но какая разница - в одной функции ты пишешь или разбиваешь на функции? В одном модуле ты пишешь или в двух?

Думаешь ли ты про абстракции и апи или нет...

Инетерсно, а есть ли какие-нибудь практики или языки, которые ну просто не оставляют выбора кроме как разделять код правильно?

есть, конечно. вот, к примеру, на ассемблере наговнокодить довольно сложно - оно работать перестает быстрее, чем говнокод появляется. но на ЯП высокого уровня это слабо распространимо

Практики есть, языки - возможно Haskell

1С, вероятно SAP 🤡

Не думаю, что хаскель поможет не говнокодить, только если в плохом смысле. Там где можно забить на типизацию, срезать угол и сделать проще хаскельная типизация тебе этого не даст. А в ситуации когда человек думает не абстракциями, а частными случаями можно и  хаскельная типизация но поможет (точнее поможет но только отчасти).