To me this "find the best solution and not a solution" sounds rather crazy. You'll spend your days trying to figure out the best way to do things, instead of actually accomplishing things.
You'll end up in a situation like this
while (true) {
findBetterSolution();
}
implementSolution();
Of course you should not just rush into things and do the first thing you can think of, but wasting your time looking for that mystical "best solution" is crazy. Iterative development is generally the best way to do things: Create a "good enough" solution, that has been developed based with some thinking, and then if there are issues with it later fix them then.
When you set up your own business you will soon realize you can't just sit in a dark room forever implementing your "best solution" and do need customers to use your "slightly less than perfect solution" to get money in, and to get real feedback from. The assumptions you make about a "best solution" without any real user feedback are simply going to be wrong and are going to lead you down a path of a lot of wasted time and money.
A wise man once said: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"
But first, we have to know which 3% and chances are really, really, really good that it's NOT the little chunk you're hung up on trying to find "the best" solution to/for.
Paralysis by analysis is a real thing and slows everything down while the "loop-ee" doesn't even realize they're executing an O(∞) search algorithm.
There are certainly cases where I can say "this is a critical path that I should spend some time optimizing more", or "this part is going to have to cope with a lot of different situations and I should think about it in advance", but in most cases "hey this works" prevails.
Sometimes a day, a week or a few months later I see "oh, didn't expect this to happen, now I guess it needs some refactoring", but that's a lot better than having delayed everything else I worked on by trying to predict the future and accomplishing nothing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
To me this "find the best solution and not a solution" sounds rather crazy. You'll spend your days trying to figure out the best way to do things, instead of actually accomplishing things.
You'll end up in a situation like this
Of course you should not just rush into things and do the first thing you can think of, but wasting your time looking for that mystical "best solution" is crazy. Iterative development is generally the best way to do things: Create a "good enough" solution, that has been developed based with some thinking, and then if there are issues with it later fix them then.
When you set up your own business you will soon realize you can't just sit in a dark room forever implementing your "best solution" and do need customers to use your "slightly less than perfect solution" to get money in, and to get real feedback from. The assumptions you make about a "best solution" without any real user feedback are simply going to be wrong and are going to lead you down a path of a lot of wasted time and money.
I thought exactly the same thing.
A wise man once said: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"
But first, we have to know which 3% and chances are really, really, really good that it's NOT the little chunk you're hung up on trying to find "the best" solution to/for.
Paralysis by analysis is a real thing and slows everything down while the "loop-ee" doesn't even realize they're executing an O(∞) search algorithm.
Indeed.
There are certainly cases where I can say "this is a critical path that I should spend some time optimizing more", or "this part is going to have to cope with a lot of different situations and I should think about it in advance", but in most cases "hey this works" prevails.
Sometimes a day, a week or a few months later I see "oh, didn't expect this to happen, now I guess it needs some refactoring", but that's a lot better than having delayed everything else I worked on by trying to predict the future and accomplishing nothing.