-1

i ve just tried to do coding bat exercise. There are posted solutions to the problem i tried to solve. However, I was stubborn, i ignored them and tried to code it up my own way(basically reinventing my own wheel - square,bad working wheel). After 4 hours it looks nasty and fails some tests.

Now i realize that my logic was totally wrong and wasteful. So the question :

  • When do you start to give up solving problem your own way(reinventing the wheel) and start to look around to see other solution?
  • How long should a developer be 'stubborn' in trying to find his 'unique' or complicated solution?
  • When do you give up and begin to search for another logic?
0

4 Answers 4

1

I usually follow below methodology when it comes to scenarios that you are facing:

  1. Get the root cause of problem for the solution that you are developing, it is not necessary that all your code logic is waste if the solution is not achieved. If you properly get the root cause then you are able to think on the new logic that can be plugged in to overcome root cause else at this position you can search online for help on that particular root cause. This way you will narrow down your searching & it will be manageable.

  2. Time to struggle for the solution really depends on two factors - deadlines if any And if no deadlines then till you get saturated. Usually time of around one day for a genuine issue is good enough to start re-thinking on some other approach. There are some instances where even after searching a lot on some particular problem there is no suitable solution found at that time the problem resolution may take up to a week also wherein you have to spend time on thinking out of the box solutions which have been never faced by anyone else till now. For example solving the issue of memory leakage from a Java 3D applet hosted on tomcat using web start.

I guess above points covers answers to your 3 questions to some extends.

1
  • till u get saturated! - 100%!
    – ERJAN
    May 22, 2013 at 23:42
2

You don't reinvent the wheel, unless you have valid reasons to do it.

If you are aware of the actual implementation, but believe you can do better (the second reason from the list), than you start by explaining to yourself what exactly you're imagining improve over the existent solution. Then,

  • Either you solve the problem,
  • Or you find yourself unable to solve it,
  • Or, which is, I imagine, your actual case, you discover that you can't clone the existent solution in the first place, before even trying to add your unique features or do things better.

In the last two cases, you simply check constantly your goals and your actual state.

  • Don't code just for the purpose of coding. Code with a goal in mind.
  • Don't spend hours writing untested and untestable code. Start by writing tests, then code itself.
  • Don't blindly try achieving an imprecise goal. Write, if need, the precise functional and non-functional requirements. Having the last ones is especially important. If you're reimplementing something, make sure you have enough non-functional requirements which control the performance of your solution compared to the one you clone, how well is it documented, how extensible is it, etc.

    Gathering and writing those requirements, by the way, may push you into a deeper exploration of the solution you're cloning, which finally may lead you to the conclusion that your actual need is already solved by it, or that instead of reinventing everything, you may just extend the existent solution. Here's an example of both finding unknown features and extending the solution.

Finally, how long will you persist trying until you understand you're on a wrong way depends on your personality. I myself wasted four hours this Sunday trying to implement something in Python (while I never used Python before), to finally understand that I completely failed, and that the only reasonable way to do my job is to discard everything I've done for hours, and solve the business problem in a language I use daily for the last six years. Other people would have spent maybe a day. Others would have abandoned after an hour.

It also depends on the context. I really wanted to try something "real" in Python. If it was a language I don't have a good opinion, I would have abandoned after the first issue, blaming the language.

1

For me the school of thought is often "This is an obvious problem therefore someone must have encountered it before and given a solution or steps towards it" be it a plugin or a snippet class or whatever.

There is merit in trying to tackle it yourself and think through the problem but, if time is a factor why not take advantage of collective wisdom.

I would add that if using a code snippet or class it is always worth reading the associated tutorial and the code so that you understand the solution.

One of the benefits of that first step of thought time is to help focus you on what the problem actually is, what the requirements really are and therefore what you need in the solution.

-1

Frankly, I always look for an existing solution first, preferably more than one. Don't waste your time reinventing things that exist, unless none of the existing solutions meet your requirements (in which case, they aren't really solutions, are they?).

1
  • this is not how you learn, esp. if you are beginner programmer, no pain - no gain. in coding - same thing. otherwise you develop bad habit of jumping to google always. my question is for when "it is not workplace" , when you have free time
    – ERJAN
    May 22, 2013 at 23:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.