Put in More Work than Anyone Thinks Is Reasonable
My current project has two competing pull requests, one of them will be merged and the other will be picked over for any useful code to salvage from it into the surviving branch, then deleted.
If I was under a time crunch, I wouldn’t be doing things this way. It isn’t the fastest path to a library that’s good enough to solve the problem once. The thing is, I’m specifically writing a library that is hopefully going to see broad adoption, at the very least as a common dependency for in-house projects. This means front-loading suffering exploring how two divergent patterns can work is worthwhile as it will hopefully save re-work and API churn down the line.
My hope is that this project leads to something worth releasing soon, I have high hopes for the second implementation, what I thought was going to be the uglier and harder to streamline API slimmed down nicely from my original mental model of it when I applied some of the lessons learned in the original approach that I took.
Where the illusion comes in is that the API that ships is going to have a commit history that looks like it took about half the time and half the work to get to the real solution. Some of that may end up in documentation explaining why certain decisions were made, but a lot of it is going to be hidden in structure of the API looking like decisions that just worked out.