I'm doing this with the SaaS I'm building (outside of my day job). My URL endpoint functions were directly executing SQL on the database until I decided that I couldn't go on like this, and only then did I write some classes to represent the business logic objects. It sounds ridiculous, but it gave me the flexibility to experiment with what those objects should do before imposing a formalism on them, and I found that very valuable.
At my day job, I'm expected to use TDD, and I don't like it. It's not that I don't like tests - I don't like writing them, but I like it when they're there, so I write them while feeling a bit grumpy. My problem with TDD is that I'm a big picture thinker, and I start from the inputs and work incrementally towards the outputs, without having a good outline of how I'm going to get there, so I can't write unit tests before writing any actual code, because I don't know what the units are going to be yet.
I also find my colleagues' code to be factored in a slightly unnatural way, because it reads like they've structured the code to match the tests, rather than written tests to test aspects of the code.
Maybe I should just be a hermit-programmer.
At my day job, I'm expected to use TDD, and I don't like it. It's not that I don't like tests - I don't like writing them, but I like it when they're there, so I write them while feeling a bit grumpy. My problem with TDD is that I'm a big picture thinker, and I start from the inputs and work incrementally towards the outputs, without having a good outline of how I'm going to get there, so I can't write unit tests before writing any actual code, because I don't know what the units are going to be yet.
I also find my colleagues' code to be factored in a slightly unnatural way, because it reads like they've structured the code to match the tests, rather than written tests to test aspects of the code.
Maybe I should just be a hermit-programmer.