
Ask HN: How to deal with All-or-nothing mindset? - allnothingthrow
I&#x27;ve have this mindset when I&#x27;m trying to solve a problem when working on a hobby project.<p>When I encounter a problem, I _must_ output code at peak efficiency and optimization or it just isn&#x27;t worth it.<p>If I&#x27;m working on a project at work (or at school) time constraints &#x2F; teammates counterbalance my tendency to lose much time working and&#x2F;or thinking too much for a little problem that should be solved in a relatively short time.<p>However, since in hobby projects I don&#x27;t have such constraints, I lose too much time researching optimal ways to solve a problem and not get any work done. Eventually I lose interest not having got much work done.<p>Does anyone have experience dealing with this mindset?
======
pschuegr
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.

------
he11ow
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.

------
cbanek
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.

------
sfgweilr4f
<not sarcasm>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.</not
sarcasm>

------
joeld42
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.

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

------
ishjoh
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.

------
m_ke
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.

------
redis_mlc
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.

