I think that you are trying to overengineer a solution because you feel that your first approach is normal or rudimentary, but not all problems that need to be solved require `good` solutions. Some are very straight forward like a simple CRUD or some might not require any further changes to the solution you have right now.

The root of the issue you are facing might be that you are too focused on this duality concept and worry about the current zone you are in. I would rather suggest on focusing on solving the problem in front of you and not worry about how `amazing` or `normal` it is. Because sometimes you might need to build and try out a normal solution and then iterate to make it better. If you feel like your solution can be improved but you are unsure of how to proceed, create a RFC. A colleague who might see the problem with fresh eyes or has solved something similar before may help you out.

Replaced `crap` with `normal` since I believe no solution is `crap` if it solves the problem. It might require improvement in a lot of ways but that does not mean it is `crap`.

It's frustrating to have to come up with solutions, however effective, to problems that should never have existed in the first place.

From personal experience: yes. The problem is the perfect solution is usually only obvious in hindsight, after you've done the work, so the quicker you get there the quicker you can get to where it "should" be.

Because taking care to do something right has value too and that takes time. Not everybody is wired the same way and by prioritizing speed over correctness you may end up with sub-optimal solutions.

> So long as there is value to be had from delivering a result faster, I would expect a correct solution delivered faster to be better than the same correct solution delivered more slowly.

Correct is not a binary proposition, and by making it the same solution you are making my words say something that I did not imply: a solution can keep you moving but a good solution may save more work than just implementing any solution and may well be more future proof. Depending on the context it may in fact be the only solution that is really valid.

> It's like the classic "pick two" triangle of cheap, quick, or high quality. Of course we assign more weight to solutions that don't make us choose.

High quality may in the long term be cheaper and even faster, but you'll never know.

I really like that idea. So for a given project where there are 5 ways I can say "I'm going to solve it using approach 4. It may turn out to be better or worse than the others but that's not what matters; using this method is what I'm doing" and have that as my goal, not finding the optimum method amongst the 5 possible ways.

I don't think the person you're responding to is a perfectionist. He just has a different view on how to improve things.

This makes it sound like you're saying just not to solve problems when they're too annoying, but I somehow don't think that's what you're trying to say.

It's the opposite that is usually happening to me: I go to sleep thinking I finally solved some problem. When I wake up, literally the first thought is a clear counter-example on which the solution does not work. It's frustrating.

if you don't follow the plan, you haven't planned correctly. a good plan has built-in mechanisms to make you follow it. OP's project tries to give you one potential mechanism for that.

And there’s your problem right there: Assuming that nobody has ever tried to solve this problem before so not bothering to look around at existing solutions.

This is a failure of lack of context, in two ways:

1. The author lacked knowledge about the various possible solutions and the strengths and weaknesses of each one.

2. The author lacked knowledge of the context into which the solution would be applied, e.g. a sophisticated solution might not make sense for an unsophisticated team to maintain.

This is irrationally pessimistic.

Nothing is perfect, but there is a huge, meaningful difference between slightly flawed and completely flawed. It doesn't need to be perfect. It just needs to be good enough.

Many things _can_ be done decently well the first time. Often times it just takes a small cultural mindset shift, and some minor improvements to the approach.

That not everyone is as solution-oriented as you, and that being solution-oriented isn’t inherently superior.

Because perfect really often is the enemy of the good. If a perfect system isn't practically achievable, in the near term at least, is there really no point in making any improvement at all? In any case sometimes the best route to an ideal or near-ideal destinations is one step at a time.

This is a number 3 problem.

Precisely. And, building the truly best solution, is often a mistake, in that it can take pointlessly long.

Good enough is good enough, and others might find things to improve, and be correct that it'd been better in their way — the important thing is instead to realize that actually making any improvement one might have found, can be far down on the priority list. Maybe there'll always be other more important things to do, so it'll never happen.

> > "at least possible that it's over all the best solution"

can be rewritten as:

> > "at least possible that it's a good enough solution"

And maybe it can make sense to make improvement suggestions, and then, when the others say "yea but there's too much else to do", then, ok, maybe forget about it and be happy anyway.

This needs to be clarified. If taken literally then people will never improve and Joe average will continue to post bullshit on the internet.

Most solutions are probably comparable to much of what is on the internet, but that doesnt make it ok. We need to filter what we see on the internet. If you learn a new concept that's good, and maybe it's what you need. The key is to keep trying to do better while looking out for fads.

I've seen a lot of change over the years regarding big new paradigms. Some I tried, some I tried and passed on (Java) only to see them fade. Maybe I'm ready to start a blog ;-)

That is where i get started- how do they expect the ideas? Do you just got to have a nice solution - or do they expect solutionpaths, with all problems worked out and a polished result plus estimate at the end.

Ideas alone are worthless. Realizations - and the path through the labyrinth of failure is whats valuable.

That sounds like a massive barrier to entry and more effort than solving the problems I currently have.

IOW, it turns out that "fake it til you make it" doesn't work if you don't actually make it.