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?

22 Answers
22

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:

Do you understand the problem?

Do you know that the problem is unsolvable (within your time/budget constraints)?

Do you just not know how to solve the problem?

Is your client/boss asking for the impossible.

Is it worth it? (ROI)

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.

Not a bad answer. I just wanted to add that the most successful hackers maintain a certain level of practical arrogance: i.e., assume you can beat any challenge. Most of the time you'll be right, and you'll solve more problems than someone who doesn't operate under than assumption. That said, not solving a problem isn't the end of the world -- just don't leave it to the last minute. Managing up means making sure your boss has reasonable expectations. If you aren't sure how to do something, let the boss know you need time to research and come back with recommendations.
–
HedgeMageDec 7 '10 at 16:47

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.

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

Try to google

Ask someone

Search SO directly (bypassing Google)

Think

Smoke (== clear head)

Ask a question on SO

Wait till morning (== clear head even more)

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.

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.

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.

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:

Proof of attempts done to solve a problem.

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.

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.

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

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.

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.

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

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

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:

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.

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.

Sometimes talking to a co-worker who understand the work can help, even if they don't offer any suggestions, just talking it out can help you sort it out in your own head
–
funkymushroomDec 7 '10 at 16:00

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.

-1, it is definitely possible to be given a problem which is impossible to solve. "Design a brute force password solver which can crack 30 character passwords in under a minute, which needs to run on a Pentium 2 with 256 megs of ram."
–
AttackingHoboDec 7 '10 at 18:47

1

There are plenty of unsolvable problems. The trick is to know that they are unsolvable very quickly. Preferably before the marketing guy asking you to solve it has finished telling you the problem.
–
OrblingDec 7 '10 at 20:20

That's not a joke for me, its normally my first port of call. In-fact the process of formulating a question often provides the impetus for discovering a solution myself.
–
NimChimpskyDec 7 '10 at 15:07

10

Last time I just couldn't figure out a problem with some software, asking on SO got me an almost immediate correct answer.
–
David ThornleyDec 7 '10 at 19:06

+1 for dirty hack, sometimes the unavailability of a proper solution looks like no solution at all... sure, nobody likes global variables, but if this is the only available way to get a piece of information from A to B... better than not delivering at all.
–
user281377Dec 7 '10 at 21:38

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.

+1 for "ask for help". Another pair of eyes on the problem can be extremely useful.
–
Michael KDec 7 '10 at 15:15

5

+1 for your second point... beware of the 95% solution. That is, the solution that gets you 95% of the way there very quickly, but is nearly impossible to make work 100%. I find it's easy to throw a lot of extra time trying to get the last 5% because you're "almost there".
–
Scott WhitlockDec 7 '10 at 15:25

4

"Mr Corleone is a man who insists on hearing bad news at once."
–
JeffODec 7 '10 at 15:54

3

Being able to ask for help is very important. So many times I've seen new developers come back after 2 weeks with nothing to show for it because they got stuck on the first day. Of course, your mentor/boss should be asking you how you're going, etc, but don't lie and say "everything's going OK" when it's clearly not!
–
Dean HardingDec 8 '10 at 0:10

4

Even the simple act of explaining the problem to somebody else can allow you to find a solution.
–
alexanderpasDec 8 '10 at 2:15