I think the difference is in "worry too much". You can write shitty code and push boundaries. You can write clean code and push boundaries. But if you're spending too much time worrying about if your code is tidy enough to publish what you created (or not publish because it isn't), then that's time wasted on not exploring the idea.

There's been a few posts on HN that I remember which could be summarised as "I made this cool and useful thing, but I'm worried I'll be criticised because it's not polished enough. Should I just throw it away?" That's the "worry too much" view.

I’ve spent the last two weeks agonizing over the design of some API endpoints for a side project I’m working on (clean and tidy).

This is stopping me from actually making any meaningful progress on some other challenges in the codebase. (pushing boundaries)

And for the actual problem: is drawing a card actually move with a source and destination?

/player1/draw

/move/player1_deck/to/player1_hand

I keep getting hung up on the fact that move feels “more right abstractly” but now the move endpoint has to know about _all states_ to know if the move is valid.

If you're developing something that you aren't currently capable of testing or keeping 'tidy', should you just give up? If you focus on developing that thing and make the tests work later, it is absolutely possible to push boundaries.

There was no testing framework capable of testing my latest JS library so I built my own; but here's the catch: the testing framework for the library is bootstrapped by the library itself, necessitating building a large amount of the functionality before getting CI in place.