Десять лет назад, когда я зарабатывал на жизнь исключительно фрилансом, я был вынужден максимально точно оценивать свою работу. Если фрилансер ошибается с оценкой и делает работу медленнее, скорее всего, ему просто не заплатят. Если ошибается и делает быстрее, то один-два раза "лишние" деньги могут и остаться. Но если у такого фрилансера нет сильного личного бренда (у меня не было), клиенты постепенно уйдут к тем, кто делает работу быстрее и дешевле.
Так вот, фриланс приучил меня максимально детально разбивать проект на подзадачи и максимально точно оценивать их. Вы сейчас возразите, что это совсем не agile, и большие проекты так не делаются, потому что требования меняются — и будете правы. Но я не делал большие проекты с командой, я делал маленькие сайты в одиночку.
Кстати, именно поэтому я считаю фриланс отличной ступенькой к независимости для состоявшихся специалистов и ужасным началом карьеры. Фрилансер буквально не может учиться чему-то новому на своих проектах: ему никто не заплатит за потраченные на новые технологии лишние часы — ещё и пожалуются на медленную работу. Сильных коллег, готовых стать наставниками, тоже нет. Теоретически остаётся свободное время, чтобы учиться, вот только у фрилансера-новичка ставка такая низкая, что и свободное время уходит на работу.
До самого недавнего времени привычка разбираться в каждой мельчайшей детали так и не покидала меня. Как будто для того, чтобы написать цикл на Python или JavaScript, нужно знать разрядность регистров процессора. Продолжая аналогию с высокоуровневыми языками программирования, это не только бесполезно, но и вредно — эти языки целенаправленно абстрагируют программиста от тонкостей архитектуры процессора.
Иногда такая скрупулёзность может быть полезной: например, при планировании переезда в другую страну. И то есть эмпирический предел, за которым новая информация уже не помогает подготовиться к трудностям, а только заставляет больше нервничать.
В промышленном программировании (миллионы строк кода, сотни и тысячи разработчиков) попытки разобраться во всех тонкостях работы модулей и систем вокруг того маленького кусочка, который изменяете вы, не приведут ни к лучшему пониманию системы, ни к быстрому выполнению задачи. Даже допуская, что все ключевые части системы внятно задокументированы (нет, сынок, это фантастика), одних только теоретических знаний всё равно не хватит.
Придётся не раз ошибиться, выкатить баги в прод и потом быстро исправить — чтобы через серию таких ошибок составить внятное представление о системах, с которыми вы работаете, и выработать правильную интуицию для рассуждения об их свойствах. Поэтому же важна минимально сложная архитектура системы и корректное проектирование на уровне компонентов. Чтобы, как в известном меме, снизить количество WTF-моментов.