Broadly speaking, a few principles guide my software engineering these days:
* Automated tests: Great, must-have, let you make guarantees about what your software will do, write them and have them.
* User stories: Great, must-have, make sure you're writing the correct thing, make them and implement to them
* Test-driven design: Terrible, big waste of time, borderline anti-human practice, assumes omniscience. Don't stress about this; just write code.
@mtomczak @freeschool I think something that has worked for me once or twice is writing documentation first. Somehow writing docstrings that explain how to use the API gives me just a touch more freedom to be allowed to get it wrong the first time.
Tests first while I'm still thinking about the shape of the problem just exacerbates my tendency to try to land the perfect thing in one go.
@freeschool Sorry, that should have been "test-driven development."
What I mean is specifically unit test-driven development, like in https://methodpoet.com/unit-testing-vs-tdd/. Consistently, I find that when a new feature is requested, the details of how the feature is to be implemented aren't well-enough understood to begin writing unit tests against them. So most attempts to do TDD that I've seen result in ripping up 100% of the unit tests and starting over, eventually.
The exception is minor modifications to existing features, where changing the test first and then the implementation works fine. But if new classes, functions, or entire APIs need to be developed, I find that writing the unit tests first gets in the way of the exploration necessary to nail down the desired shape of the finished product.