5 ms·

Ask HN: What am I doing wrong

3 points by letmeaskthis 11y ago

I often find myself sticking to a solution idea that I have for programming problems. Sticking to it so much that it seems to take me prisoner. I have the feeling that had I chosen another path or be willing to change to another path along the way, that the time to solve the problem would be much quicker. Does this problem make sense? What are some ways I can correct this?

letmeaskthis 11y ago
It could also be that the 'solutions' I have are also idealistic which is more demanding than other simpler solution possibilities. Maybe this is part of the problem?
- davismwfl 11y ago
  Yes, this can be a problem. Learning the difference between ideal and good enough to get the job done is important. Also, avoid the planning for every eventuality, work with what is known. A common issue is someone saying, well I want it to do "X" in the future. Well great, then in the future you can refactor it to do "X", in the meantime I have to make it work and get it out the door. I will try to not do anything that would make "X" harder, but I won't worry about making it happen either.
davismwfl 11y ago
You aren't alone in this, I think it is a relatively common problem. In general, experience is what makes this better. Knowing when to take another path is usually when you see that the problem is over complicated as is. Take a look at the overall goal of the solution, then break it down into stages, steps or simple issues within the larger context. That will usually help you prevent being taken hostage by the problem. Also, sometimes issues are just complicated. I recently worked on debugging an image processing algorithm I implemented for a client. I spent 4 days following one path just to figure out it wasn't the right path at all. In that case the hostage feeling came from the fact it was highly parallel and extremely complex and it just took a lot of time. Even with breaking the steps down to the simplest denominator.
- letmeaskthis 11y ago
  In that case, I guess the problem is, how do you see that a solution is overcomplicated as quickly as possible to recorrect and use another approach.
  - davismwfl 11y ago
    Overcomplicated to me is when I see one method/function etc trying to do too much work. For me that generally means a method/function over 1 screen or 100 lines of code (some exclusions for a switch statement or if/else) is generally trying to do too much. In my experience when you see large methods/functions generally it means the problem wasn't well understood when it was implemented so the coder/designer didn't know how to break it up. I also think many people may hack out a larger method at first to get the concept right then start refactoring, I know I have done this at times. As long as it gets refactored that is all good. Also, when you see an architecture that just doesn't fit the solution. For example, someone is building a distributed system to serve 20 users in a web application. That just doesn't usually make sense and is likely over complicated and is time to rethink. There are always the rare examples where it is necessary but I'd go with the 98% of the time when it isn't. Do you have an example of a problem that troubled you that may help others provide ideas for you?
halotrope 11y ago
I have experienced these things as well. Switching tasks and coming back to the problem the next morning sometimes works wonders. Also pari programming and reasoning together about design and implementation can give you a fresh perspective from my experience.
ruraljuror 11y ago
Not sure if you mean long term (as in design-level issues) or short term (trying to hack through a particular method), but in either case one of the best things you can do is turn off from actively thinking about the problem. If you're banging your head against the wall, give yourself permission to walk away and let your unconscious process and work through the information. You will often be surprised to see the mountain leveled when you return. One way of doing this is taking a long walk as a mid-day break.
pvaldes 11y ago
Too general situation. Can you elaborate your question? There is always a better way but you need to build your solution in small incremental steps. This means that you can not solve anything until you had failed to solve the problem previously and identify the wrong answers leading to death ends.

3 points by letmeaskthis 11y ago

letmeaskthis 11y ago

It could also be that the 'solutions' I have are also idealistic which is more demanding than other simpler solution possibilities. Maybe this is part of the problem?

davismwfl 11y ago
Yes, this can be a problem. Learning the difference between ideal and good enough to get the job done is important. Also, avoid the planning for every eventuality, work with what is known. A common issue is someone saying, well I want it to do "X" in the future. Well great, then in the future you can refactor it to do "X", in the meantime I have to make it work and get it out the door. I will try to not do anything that would make "X" harder, but I won't worry about making it happen either.

davismwfl 11y ago

You aren't alone in this, I think it is a relatively common problem. In general, experience is what makes this better. Knowing when to take another path is usually when you see that the problem is over complicated as is. Take a look at the overall goal of the solution, then break it down into stages, steps or simple issues within the larger context. That will usually help you prevent being taken hostage by the problem. Also, sometimes issues are just complicated. I recently worked on debugging an image processing algorithm I implemented for a client. I spent 4 days following one path just to figure out it wasn't the right path at all. In that case the hostage feeling came from the fact it was highly parallel and extremely complex and it just took a lot of time. Even with breaking the steps down to the simplest denominator.

letmeaskthis 11y ago
In that case, I guess the problem is, how do you see that a solution is overcomplicated as quickly as possible to recorrect and use another approach.
- davismwfl 11y ago
  Overcomplicated to me is when I see one method/function etc trying to do too much work. For me that generally means a method/function over 1 screen or 100 lines of code (some exclusions for a switch statement or if/else) is generally trying to do too much. In my experience when you see large methods/functions generally it means the problem wasn't well understood when it was implemented so the coder/designer didn't know how to break it up. I also think many people may hack out a larger method at first to get the concept right then start refactoring, I know I have done this at times. As long as it gets refactored that is all good. Also, when you see an architecture that just doesn't fit the solution. For example, someone is building a distributed system to serve 20 users in a web application. That just doesn't usually make sense and is likely over complicated and is time to rethink. There are always the rare examples where it is necessary but I'd go with the 98% of the time when it isn't. Do you have an example of a problem that troubled you that may help others provide ideas for you?

halotrope 11y ago

I have experienced these things as well. Switching tasks and coming back to the problem the next morning sometimes works wonders. Also pari programming and reasoning together about design and implementation can give you a fresh perspective from my experience.

ruraljuror 11y ago

Not sure if you mean long term (as in design-level issues) or short term (trying to hack through a particular method), but in either case one of the best things you can do is turn off from actively thinking about the problem. If you're banging your head against the wall, give yourself permission to walk away and let your unconscious process and work through the information. You will often be surprised to see the mountain leveled when you return. One way of doing this is taking a long walk as a mid-day break.

pvaldes 11y ago

Too general situation. Can you elaborate your question? There is always a better way but you need to build your solution in small incremental steps. This means that you can not solve anything until you had failed to solve the problem previously and identify the wrong answers leading to death ends.