

Ask HN: What am I doing wrong - letmeaskthis

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?
======
davismwfl
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
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
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?

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

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

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

