How to deal with All-or-nothing mindset?

Ah, a question I can answer.

This used to be a huge problem for me, but it's become much less of an issue. It's a bit weird, but I think what helped the most was that I really got into the concept of "thin-slicing" as my default approach at work: "what is the least amount of work I can do that gets me closer to where I want to go?". I'm really ruthless with it now, like

- do I need to design my whole db schema right away? hell no, I need one table

- do I really even need the db layer to get to prove out what I'm trying to see? actually no, I don't

- do I need a UI? yes, but I only really need these elements, I don't need auth, I don't need X, I don't need Y, I only need Z.

It's really easy to fall into trying to optimize multiple things at the same time and thinking about second and third-order consequences of choices that you make. My new ethos, as bad as it sounds, is "focus on making something shitty. when i've got something shitty, then i'll make it less shitty" and repeat as needed - the compounding effect of "less shitty" is "eventually awesome". That doesn't always fly at work, but it's IMO the best way to get things done. I'd say 9 times out of 10, you learn so much more from making the shit thing than you do prematurely optimizing something in your head.

One thing I've found incredibly powerful over time is sussing what "Good Enough" looks like in the context of whatever task I'm dealing with. I just can't overstate how much Good Enough is important. It saves you doing extra work, and from doing redundant work, and from getting forever stuck on one thing so you can't move on to the next.

The other thing to mention is that there's a false dichotomy between quantity and quality. Quantity is the only way to get to quality. At elite levels, improvements happen because you change how you do things. But to even get to that point, a lot of quantity work has to happen.

In other words, your gut is telling you that super-optimising is making you better, but it's not.

All the time.

I think it's honestly a kind of mental creative hangup, like procrastination. Many times procrastination, all-or-nothing, and a feeling of the worst that can possibly happen will happen can easily derail me.

What's helped me is first admitting that these coping mechanisms might not be helping. Sometimes, they are useful, for example, in not spending huge amounts of money on a random idea that may or may not be feasible. But if it is a simple decision with small impact to your life, realize that. Realize the stakes are low, and the amount of time you are putting into it is higher than it merits.

Next what helps me is timeboxing. Just do it. To make this more fun, I think of it as a challenge. Can I code something in an hour, or before a movie is done, etc.

Experience has taught me what you worry about is rarely what gets you anyway. It's what you don't know might happen that gets you.

Best of luck.

Get a dart board. Then throw darts 100 times in a row. This will force you to confront the reality of imperfection. If you are sufficiently compulsive you will have taken the first steps towards a new hobby. Perhaps that is what you really need. Or not. Darts are fun anyway. Good luck.

I have a tendency to do this sometimes. For me it helps to reframe the problem to a target spec. For example if I was making a 2D game I might get carried away with batching and atlasing things until I could draw tens of thousands of sprites rather than actually working on the game. Instead, if I write down somewhere: the game will have a maximum of 2-300 monsters on screen at any time, thus the engine target is 500 monsters at 60 fps. Then I have a clear pass/fail for the task, if I can draw 500 monsters then I'm done, even if I'm doing it in a dumb or brute force way.

Also, recognize that you might be drawn to working on problems you know how to solve and drawn away from problems you're not sure about. If you're good at optimizing code but not sure about handling player movement or whatever, you could be feeling the pull to do the thing you're good at.

I was recommended "The Gifts of Imperfection" by Brene Brown for this problem. As self-help books go it's decidedly light on woo.

It's useful for me to think about what I'm trying to accomplish.

Am I trying to learn something new? Am I trying to get something out quickly?

If you start out with the latter as the goal implement a naive solution with a TODO to come back to. If what you release starts gaining traction and you want to continue to work on it you'll come back to your TODO.

I've struggled with this a lot as well. I think the solution is to work backwards, get automated deployment working first so there's nothing stopping you from shipping, then work from master to force you to ship small changes without getting stuck on never ending feature branches.

As you become more expert, you will largely write the best code the first time.

You will also realize that the best software starts small, or as a fast toy to start with.

When you see a debate over 10x developers, that's between people who are not.