What happens if you're unable to solve a problem? [closed]

Question

I'm a year away from graduating from university, and I'm really looking forward to solving practical problems. Especially non-trivial ones which require a bit of research and a lot of thinking.

But at the same time, that is also my greatest fear - being faced with a problem that I'm unable to solve, no matter how hard I try. And with pressure to deliver code on impending deadlines just around the corner, it does look a bit scary when viewing it from the safe playgrounds on uni (where the worst thing that can happen is that you have to redo a course or exam).

So for those who have been in industry for any longer length of time, what would happen if you were told to solve a problem that you couldn't? Has it happened, and if so, what did happen? Did they just drop it and said "Oh well, guess we can make do with something else"? Were there consequences? Were you reprimanded, or even fired?

Answer 1

First of all, your fear is very healthy, and normal. Here are my musings after about 15 years in the software industry.
Here are some questions to ask yourself:

1. Do you understand the problem?
2. Do you know that the problem is unsolvable (within your time/budget constraints)?
3. Do you just not know how to solve the problem?
4. Is your client/boss asking for the impossible.
5. Is it worth it? (ROI)
6. Is it a REAL problem?

1) First of all, make sure you understand the problem. There are no stupid questions. Do you understand what your client/boss is asking you versus what they need?

2) This will happen. "Build me a bridge by tomorrow". Make sure that you know for a fact that a problem is unsolvable within your constraints. Your client/boss might be flexible on the time/budget and these can be modified to give you more time/budget.

3) If the problem is understandable and the constraints are within reason, and there is technology that can solve the problem, but you just don't know enough...that's what StackOverflow and the Internet is for. Make sure you do your research first. Try to ask explicit questions that have quantifiable answers. Ask your peers. Have a design session.

4) This is a variant of answer number 2. It seems like your client/boss is asking the impossible. Do some research. Never say that the problem is unsolvable, unless you know exactly why and you can clarify.

5) ROI stands for Return On Investment. This refers to an investment in time. Your Time!. Is the problem important enough to solve to warrant the amount of time it will take you to research and solve the problem. Discuss this with your client/boss

6) Is it a real problem. Clients, often times, understand what they want, but don't necessarily understand what they need. Try to understand what your Client/Boss actually needs and discuss this with them.

Hope these guidelines help you.

Answer 2

Two things to remember if you're stuck with a seemingly unsolvable problem:

• Let other folks know you're stuck as soon as possible. It will help them to adjust the estimate in time before it's too late.

• If you see one way of solving a problem doesn't work - drop it before you've wasted too much time. Ask for help or try out a different approach. It's not about proving yourself hard and smart, it's about getting things done.

Answer 3

I go to StackOverflow ;)

But all joking aside, do not fear the unknown. Your whole career will be facing the unknown, because if you already solved it, it won't be a problem the next time.

Answer 4

I'm going to have to go with a simple answer: I ask for help. Just like others sometimes ask me for help when they're stuck trying to find a solution for something.

Edit: I should mention that I often find the solution just by describing the problem to a co-worker, or sometimes even when I start posting a question on sites like StackOverflow.

Answer 5

Look at from different angles

I've come across this many a times, usually what happens is:

• You have a problem, initially you have an idea in your head how you would solve it.
• When it comes to actually implementing your solution, it turns out that is doesn't work (probably due to the weak model of the actual problem).
• After struggling to solve the problem, be it more research or asking others. None of it works, the pure frustration!

Finally you opt for what you didn't want to do ->

"The Dirty Hack"

It works, but you feel dirty...

Answer 6

Usually, I get someone smarter than me to fix it. He does and he's my boss. I feel stupid. We move on.

Answer 7

It depends on the reason why you are unable...

• logically impossible: Discuss it with the one who wrote the requirements, maybe there is a misunderstanding. Example: at one point, the spec says that the application must look and feel native on all platforms (Windows/Linux/Mac), and in another place, it says that the program must look exactly identical on all platforms

• technically impossible: Reevaluate the tools you are working with, maybe they are not appropriate. Discuss the problem with your peers and the project manager. Example: hard realtime requirements in an environment where garbage collection can stop the execution for an indeterminate time

• insufficient performance: Maybe you are using the wrong algorithm, or maybe the problem is too hard (e.g. NP-hard) and the requirements doesn't take that into account. Reevaluate the algorithm you are using, maybe there is a faster way. Discuss the problem with your peers and the project manager. Consider switching to a good-enough heuristic instead of a perfect result. Example: path optimization with dozens or even hundreds of nodes

• you just don't know how to do it: Ask your peers, ask stackoverflow, search the internet. Contact the support of the tool/lib you are using. Discuss it with the project manager.

• it should work, but doesn't, and you have no clue why: Refactor the program to make it more testable. Consider race conditions, they are often the reason for hard-to-find bugs. Ask peers for help, four eyes see more than two. Check the internet for known bugs in the tools/libs you are using.

Answer 8

I think other people nicely point out how to deal with it in a professional manner. I would like to say how to deal with the personal feeling like frustration, fear.

Bottom line is you will be FINE even if you do not resolve issues in timely manner. Life goes on.

Sometimes, the schedule would be pushed. The project would be either successful of failed. You may be fired and then have great job. You just never know.

Don't get me wrong. It does't mean it is OK to let the problem be there. All we can do is doing my best and let it go.

Sometimes, I think the frustration, fear not solving problem is my life as a average developer.

Answer 9

I'm not sure I'd say that I couldn't solve a problem, but there have been cases where I did give up on trying to solve a problem. After pouring many hours into trying to fix a bug or implement some feature that I don't have an idea of how to do it, I may tell someone on my team, team leader or manager, "I'm stuck on this. What do you want me to do?" so that they know where I am. They could say, "Keep at it, we think you'll get it," or "Move on to something else that isn't that important," or a few other things and then I'll know what I should be doing.

I've had bugs that I didn't resolve and some features that didn't get done, sure. While I can try to get something done, not everything is within my power to solve in a reasonable time. A key point in this is to have communication so that your superiors know where you are.

That said, I did have a couple of times where I ran into some rather special circumstances:

1. While working at a large Canadian bank in Toronto, I would be asked to do all kinds of stuff that I didn't know how to do when I was given the task. For example, I was asked to test out this method for securing laptops where the "Esc" and "Enter" keys were swapped on boot-up and with the right key sequence the laptop would be usable again that just seemed bizarre to try to figure out, "Would this work? How do I know this would or wouldn't be OK with the users?" There were other tasks that I either just didn't have the hardware or other resources to get it done. At the same time it was rather educational as this gave me many things to note on any future employment situation to prevent trouble. Things like ensuring when I'm paid, how is my time tracked, and other communication issues were illustrated with great detail to me here that I haven't really forgotten.

2. While working at an Application Service Provider in Calgary, I was given this project of trying to create a copy of another website within our internal application that we sold as a service. A key point here is that I wasn't given a time line or suggestions on what part to do first, just general research and a month later I was asked for a demo just as I was having a bad reaction to some pain medication. That reaction lasted a week that I took off of work suddenly and then the following week, I went to a Microsoft event that was kind of the last straw as I was fired the next day. Something to note here is how I had a rather poor relationship with my boss as anytime he'd come near my area my immediate thought was, "Now what's wrong?" which tended to not be a rather healthy thing to have as a reaction to someone many times over.

Answer 10

As others have said, communication is critical - letting people know (who will be impacted) when you're stuck: your boss, team members, clients, etc.

A sharp co-worker once instilled upon me that success has roots in two things:

1. Relationships
2. Expectations

Having a good relationship, I suppose, is a function of good communication and setting expectations up front.

Answer 11

I follow the Polya princinple:

"If there is a problem you can't solve, then there is an easier problem you can't solve: find it."

George Polya

The beauty of the principle is that at some point there will be a problem that is small enough and that you will be able to solve which, hopefully if you did things right, will allow you to bootstrap a solution to the original problem. This principle has not failed me yet.

Answer 12

The "seek help" answers are definitely correct. It is highly unlikely that you are the first person to ever encounter a particular problem.

But as a though experiment, what if there is no help? What if you must solve the problem on your own? The most important problem solving ability is the ability to identify and challenge your own assumptions. If you can enumerate your assumptions about a problem one-by-one and eliminate each in turn, you will eventually come upon the errant assumption and new possibilities for a solution will open up as a result.

(By the way, this is also the best approach when you can't see an answer to a problem you get in a job interview. Verbally list out your assumptions, and determine which one is wrong and then re-attack the problem. Almost all "trick questions" are based upon natural yet faulty assumptions).

Answer 13

Asking for help is really the best answer, but here's a little more that may be useful.

So for those who have been in industry for any longer length of time, what would happen if you were told to solve a problem that you couldn't? Has it happened, and if so, what did happen? Did they just drop it and said "Oh well, guess we can make do with something else"? Were there consequences? Were you reprimanded, or even fired?

Yes, it's happened to me, and no, I never got reprimanded or fired for it, because...

In industry, it's all about whether you solve problems on time and within budget, and decent managers understand that's not always possible.

What really happens is your manager says, "I'd like you to do X, what do you think it will take?" And you can give lots of answers. Good ones include:

• I've done something really similar to this, so I think it will take three weeks and $3,000 worth of testing hardware.
• I've something generally similar to this. So let me think about it and get back to you this afternoon.
• I've never done anything like this. So let me research it and get back to you tomorrow.
• Nobody on the planet has ever done this. If you want to look into it, it will take me two weeks to do enough experimentation to make an estimate.

It's the manager's job to decide whether and how to proceed. If they do choose to proceed, it's your job to meet your estimates, or let the manager know if there's an impediment. As long as you do that, in a reasonable company there won't be negative consequences.

Of course, there are also unreasonable companies that don't give you the time or resources to get your job done. I've worked at some of those, and everybody was handed problems that couldn't be solved within the company's constraints. One of them laid off about 98% of the programming staff within eight months, and that certainly was a consequence, but it wasn't personally directed at me, and I still consider my boss and his boss from there to be good friends.

Answer 14

There are lots of different types of problems that you will be stumped on, and many have different ways to handle them.

One type of problem is implementing something you haven't seen before like a strange sound API or something. In this case I'd ask on SO, seriously.

Another is a very large problem to solve. This type of problem can be approached iteratively. They tell you "Implement Humongous". You look it over and write as many steps as you can figure out. Then you break down the complicated steps into smaller steps. As you are forced to think about smaller steps they become clearer. If you encounter a technical difficulty, try a test implementation and ask here if necessary.

One of the more annoying problems is poorly specified requests. They just want a thing that does "x" and don't tell you how it should be done. For these a good approach is prototype an interface (typically a GUI) and let someone play with it.

Then there are time constraints that can't be met. This often involves modifying expectations and delivering functional prototypes.

You will generally find your way through things one way or another. It's frightening but once you're in it you can pretty much always find some way through.

Your best bet may be to just paint the words "Don't Panic" on the outside of your laptop. And don't forget your towel.

Answer 15

My sequence of solving problems (every next spet is performed only if the previous did not work):

1. Try to google
2. Ask someone
3. Search SO directly (bypassing Google)
4. Think
5. Smoke (== clear head)
6. Ask a question on SO
7. Wait till morning (== clear head even more)
8. Use that dirty hack and feel bad about myself :(

Nasty problems are solved on steps 5-6.

Really-really bad problems usually need some time (step 7 is THE solution to most 'seems-that-i-cannot-do-anything' problems). And I mean it - switch to another task for the rest of the day and try to solve the problem first thing in the morning. That does wonders.

And only then comes step 8.

Answer 16

I haven't heard of anything happening like this. First of all you are never given a problem which can not be solved at all. The problem may be hard and may take time to solve. When given a problem, you will have to tell this is the time I will require. If in your research you think that this problem really can not be solved, you have to raise a flag and tell your manager that this problem will take some more time, or is really difficult to solve. It's all about the schedule. If you promise something and will not be able to deliver then it's problem. But if you keep telling your status and concerns, it is the responsibility of manager to take care of it. He should redirect you to proper person who can help, or adjust the schedule.

Answer 17

There's some great advice here! My two cents worth is; Don't be overwhelmed by the BIG problem, don't forget that the exciting and challenging part of solving a problem is breaking it down into series of manageable and more importantly comprehensible sub-problems, which in turn break down again and again into smaller sub-problems. Any good programmer will typically do this on a minute by minute basis while they are creating code (using functions, methods, sub-routines etc to help reduce the overall complexity of a section of code) and this methodology typically applies to any BIG problem you face in life (not just at work).

Answer 18

It depends on what the specific problem is, obviously. But the response can be any of :

1. Find a workaround/substitution
2. Buy a commercial solution that approximates what you want
3. Dont give up and keep working at it as long as you need to until you succeed.

Number 3 may require time off from the problem and revisiting it weeks or months later. That often helps.

Answer 19

In my experiece, sometimes there's problem that you can't solve, at least in time restriction. So seeking help as soon as possible, after some solving effort failed you.

Remember the rule of thumb: always look at the reason the boss hires you. Do whatever you think you can do for the best work result, and sometimes that's an early fail report (far better than a late one).

In short, if you think you may find the solution, feel free to try, but give your boss estimation about the risk and the time cost. It's their problem now.

Answer 20

If hundred-million dollar projects can fail even with experienced people, you shouldn't worry about you failing as you are still a student. I've had a problem to work on and I found that if it is something you get stuck on - you must record every attempt you made to solve it.

That helps:

1. Proof of attempts done to solve a problem.
2. Recording this type of failure is important so you learn from it and don't do it again a few days later thinking it will work.

Answer 21

My experience is that a fresh graduate is not thrown into the deep. Instead, you will likely be part of a team that also includes experienced developers.

My advice would be: make use of them. When you are unsure how to tackle a problem, or if you want to know if your solution is going in the right direction, discuss this with them. And if you feel you are stuck somewhere, grab one of the experienced guys and explain your problem and ask for help.

Most often, just explaining your problem will reveal a solution and explaining your solution may equally reveal flaws in it.

Answer 22

Often this happens because you haven't defined the problem properly and accurately. Perhaps you're trying to solve a preconceived solution instead of the actual problem itself.

The problem is only what you observe, not what you imagine.

"My bloody car won't start" is a problem. "The battery is flat." is a preconceived solution to the car-starting problem. Even testing the battery doesn't prove it is the only cause of the problem. Unless you have actually recharged or replaced the battery and successfully started the car then you have no proof that the battery is the cause of the problem problem.

Simplify and keep simplifying. Break it down into small parts. If you can't solve those parts, smash them. You'll feel better. Then break it down into different small parts. Each one of those parts must be observable phenomenon.