> Who wants to give over their financial life to a computer program?

Where do you think your income and bank balances are tracked and stored? On pieces of paper?

>Unfortunately most software is just not well defined up front.

This is exactly how I feel about TDD, but it always feels like you're not supposed to say it. Even in environments where features are described, planned, designed, refined, written as ACs, and then developed, there are still almost always pivots made or holes filled in mid-implementation. I feel like TDD is not for the vast majority of software in practice - it seems more like something useful for highly specialist contexts with extremely well defined objective requirements that are made by, for, and under engineers, not business partners or consumers.

This advice may make sense for some languages, but it certainly doesn’t make sense for Python.

Python generally provides one and only one best way to do things. With one exception (single quotes vs. double quotes) I can’t think of any cases where my company didn’t espouse or require using regular, idiomatic Python.

My company consistently preferred using expressive features do the language. For example, using list comprehension instead of for-loops.

After learning Python, reading up on the frameworks used at my company (Django and Django Rest Framework) would be the next best use of a new dev’s time.

This advice might be specific to Django and Django Rest Framework. Both frameworks are old, popular, and opinionated; other people have thought through the best way to do things.

Understanding all the packages in the standard library is by no means a requirement, but knowing the language itself backward and forwards pays enormous dividends when debugging.