Какое соотношение во времени в программирование между печатанием кода и исправлением ошибок?

А, это от кучи факторов зависит.. .
Например, пишем модуль. Его отладка "абы работало" занимает обычно не очень много - соотношение где-то 3:1 грубо. Потом он отправляется на тестирование. Сколько его будут тестировать, чего там наловят, и все ли выловят - большой вопрос. Еще много зависит от въедливости тестера. Например, он может сделать предъяву не по функционалу, а по эргономике. Так, из принципа. Процесс этот итерационный, хотя чем ближе сроки, тем сговорчивее тестеры - опасаются.
Опять же, смотря кто и как составлял тех. задание.. . Бывает, что там все расписано и все всем ясно, а бывает, что об одном и том же предмете у программиста и тестера складывается совершенно разное мнение - и тут начинается такое.. .
Допустим, оттестировали модуль. Следующий этап - тестирование интерференций. Или как оно по-русски.. . В общем, как наш модуль взаимодействует с другими и не поломали ли мы чего в старом функционале. Тут вообще чистая лотерея, но ВНЕЗАПНО обычно все оказывается ОК. Неизбежные мелкие косяки правятся методом перетирания программерами в курилке, покрупнее - перетирает начальство. Если начальство очканет по-крупному, переносят сроки сдачи, но это редкость. Затем все утрясается и назначается развертывание - это когда обновления заносятся в продакшн и программеры и тестеры сидят пол-ночи, хавают халявную пиццу и ждут, что что-то свалится. Если ничего не свалилось, все на халявном такси разъезжаются по домам, а иначе начинается АДЪ со срочными правками и проверками, и если к утру он не кончается, делается грандиозный откат, и через пару дней все начинается по-новой.
В целом, после всей хренотени, соотношение из 3:1 превращается где-то в 1:3 из-за совещаний, согласований, нестыковок, ругани и сопутствующей херни. Такие дела.
К слову, так оно не всегда и не везде. Существуют гораздо более совершенные модели тестирования и отладки, но и у них существуют свои недостатки, вроде известной дилеммы "кто сторожит сторожа". Времени там тратится гораздо меньше, но и просочившиеся баги гораздо эпичнее. В общем, какая-то такая картина...

Точный ответ дать нельзя. Все зависит от техники, скорости мышления, адаптированности того кто пишет.
Все сводится к тому, что означают базовые термины, такие как "писать программу", и "исправлять ошибки"

Писать программу - означает, воспользоватся языком программирования для РЕШЕНИЯ поставленной задачи.
"Исправлять ошибки" - означает находить те места в которых программа начинает выдавать НЕ ОЖИДАННЫЕ результаты. ( Те которые явным образом не учитывались при разработке )

Обычно когда ставятся такие вопросы как этот, то все "навыки программирования" сводятся к "навыкам применять ПАТТЕРНЫ проектирования вместе с ООП. К примеру, если ты все пишешь на процедурном коде - то время на исправление ошибок уходит гораздно больше и с возрастанием обьема кода, тестировать становится все сложнее.

Хорошая практика диктует нам:

1) Не писать на процедурном коде. Вместо этого писать класс (ы) которые отвечают за определенную деятельность системы. Например класс Config, Login.
2) Очень четко разделять структуру. Например, все важные классы кинуть в папку Систем, Классы связанные с Юзером кинуть в папку Профайл Итд.
3) Использовать паттерн MVC (если это веб приложение)

4) Тестировать каждый класс. Можно написать свой тестовый Юнит, а можно скачать готовые (их не мало)

5) Использовать контроли версий типа Subversion или Git

В Итоге: Получается четко-структурное приложение, которое легко дописывать, легко тестировать, легко использовать.

К примеру, ошибка в конфиге - открываешь конфиг файл, дампишь переменные или массивы и буквально за минуту находишь ошибку.

Нужно улучшить?
Определяешь что нужно улучшить - открываешь класс и просто дописываешь.

вообще соотношение находим по формуле)) )
(время написания) / (время исправления) ~ 1 / (уровень программиста)