How to get rid of fear of not able to solve complex program? [closed]

Question

Whenever I start to solve some complex problem and try to solve it by program. I feel demotivated. Instead of feeling excited about it I feel like I wont be able to solve this program its very difficult. I know I can solve it but because of these feelings its takes long time to solve it.

Whenever I get a change to solve some tough problem this fear will come to my mind and it will stop me from thinking or will tell me you wont be able to do this etc. This fear has taken over me since long time.

I know this is psychological fear but it disturbs me a lot. It stops me from becoming the best programmer I always wanted to be.

Please help.

Answer 1

The recipe is:

1. Slice the big problem into smaller chunks.
2. Solve each small chunk separately.
3. Link the chunks together to get the final result.

It's logical to feel fear when being in front of a large monolithic problem that you cannot solve quickly. You can easily start to think this way:

1. Where to start?
2. OMG, I don't even know where to start, how would I ever be able to solve all this?
3. No, really, it's not solvable at all!

When you separate the large problem into multiple small problems, you easily see that each small problem it's not so difficult. Some were already solved by you before. Some are solved by somebody else and you just have to search. Finally, others must be solved, but it will not take too much time to solve them.

Remains the hard part: how to link everything together? That's difficult, but much easier when all separate parts are already solved, and since you have the feeling that the most of the work is already done, you'll be more encouraged to finish the task.

Answer 2

This is actually quite a good question. Here are some things that work for me:

First thing, break down the problem into manageable segments. Or at least break down the first part of the problem into small starting points.

Second: solve the small stuff. This is some of the idea behind TDD and similar buzzcronyms. There is a psychological reason for doing this as well: when you complete a small task, you get a little shot of endorphins, and you feel good about yourself and your abilities. Then you go on to the next small step, get a little endorphin buzz going, and so on.

Before you know it, the project is done, and you've become a man, my son.

Answer 3

I did a Ph.D. in Artificial Intelligence. It took me a long time and I was constantly bothered by this exact fear. The problems seem so large and poorly defined that it's hard to know where to start. Sometimes you get an idea, write up a program to try it, realize it's going nowhere, and throw it away. This happened over and over.

Here is what I learned, both by myself and from my fellow travelers.

1. Math background is good. Learn to think like a mathematician. That is, learn to think about problems symbolically in the simplest possible terms. That way, when you're conceptualizing a problem, you don't waste brainpower on engineering details like what language or data structure you should use, or how to get fast execution. Engineering can come later.
2. Be willing to try things and throw them away, because the purpose is not to build something, but to learn something. You're not really good at something until you've done it a few times.
3. Work with small programs that teach you the most for the least programming effort. When you are lucky enough to hit on an approach that carries you along, inviting you to add more to it, then do so. Myself, I typically go through four to six iterations first.
4. Bounce ideas off your colleagues. They are smart, and often you can understand your problem better just by explaining it to others. Don't worry about trying to be different from what they are doing. Everyone gets off on their own tangent eventually, and if you can collaborate, all the better.

I hope that helps.

Answer 4

Agreeing with MainMa and Dmitri, I guess many programmers share your experience - maybe mostly in a weaker way, but some in even stronger ways.

If you can't get rid of your fear, you can get used to it, and think of the other programmers, who have the same feelings, and solve their problems, and of your earlier experiences, where you solved the problems in the end.

Maybe this can help you to relativate your fears.

Try to say "Hello fear" to your fear "I don't have time for you now - I will spend some time for you later!" and schedule your fear. Maybe first draw your UML-Diagrams, set up the build-environment, create the git-repository, and write the main classes and then the most challenging algorithms and tests, and a little bit of documentation, of course, and some installation routines, and the first bugfixes and servicepacks, and then, with some substantial knowledge of your failures, meat the fear again. :)

Trying to get rid of the fear can else get your next fear, being without fear the hard to reach target. Don't estimate to be perfect.

Answer 5

Just remember that you are human and that is perfectly natural. Have self-confidence and then tackle the project head on.

And just remember, you won't know 110% of it off the top of your head. It is better to be good at referencing documentation and resources than it is to be able to memorize facts or snippets.

Answer 6

You never really get rid of the fear, you just get used to pressing on despite it. Find some small task that contributes to the goal and do that, because the best way to put fear out of your mind is to concentrate on something else. Getting over the initial energy barrier is often the hardest part of the project.

Answer 7

I think you have two separate problems: the fact that you don't know if you can solve a given problem, and the fear this fact causes. Those should really be treated separately.

The fact that you don't know if you can solve a problem or not is a good thing. It means you're working on challenging, interesting problems and you're gaining valuable experience. If you only ever solved the same old problems you can do in your sleep, you'd be bored before breakfast. And you'd never learn anything, because you have to leave your comfort zone for that. Think about it this way: Do you like games? Would you like games more if you knew you'd always win?

The second problem is fear of not being able to do what you're paid for. This can be terribly annoying and (even worse) it can kill the very creativity you need to solve complex problems. But it will get better after a while. Once you get some confidence in your own abilities, you'll be able to say: "Ok, I have no idea how to solve this problem, I'm not even sure it has a solution, but I've solved dozens of problems that looked as hard as this one when I started. I know I can do this. Now let's find out how".

Until you have that confidence, I'd suggest to get a safety net: e.g. tell yourself you'll try to figure this out for a week, then ask your superior for help (or some other backup plan). The important part is: The world won't end if you can't solve this problem. So don't worry about the world ending and start solving that problem instead.

Last but not least, some general tips for complex problems:

• As others have said, divide and conquer is always a good idea to break problems down
• Make sure you're solving the right problem. Often enough, if you're trying to do something impossible, your users actually need something slightly different. That's far easier to do.
• Be creative. Brainstorm (with others or by yourself) to find as many possible ways to solve this problem as possible. Don't stop before you have at least three ideas. Not only will one of them probably work, you also won't have to worry so much that it might not work, because you still have a few other ideas you could try in that case.
• Good artists copy, great artists steal: When you're out of ideas, find programs that do something similar to your problem and study them. Find literature on the problem domain and study it. You won't find a 1:1 recipie that solves your problem, but you will find lots of new ideas and new ways of looking at things.

Answer 8

Do some easier problems to gain confidence, it'll help you in thinking that you are indeed an excellent programmer and get you into the right mind set.

With greater confidence gained from these easier projects your fear of more complex ones should become less. Having confidence in your abilities CAN make all the difference!

Apart from that the aforementioned divide and conquer/break it down approach for big/hard problems works really well too.

Answer 9

A small problem could look insurmountable if you get too close to it without the tools to solve it.

But before you get that close, try stepping away from it. Toss it, turn it, twist it, tear it apart into pieces and stitch the pieces back into the original problem, look at it from a larger distance, look at it with a different mind set altogether. Get an understanding of the problem from all sizes, distances and angles. Also, get an understanding of it from a non-programmer perspective. One example is, an OS kernel is like a human taking orders for executing processes and, submitting them to the machine for execution and, returning the results back to the users. Use better imagination if you can.

This should give you some hints about which tools will best solve the problem. Begin with those tools. No matter how good those tools are and how good you are with them, they will fail you. Improvise. You will be solving the most indomitable of the problems thus, one step at a time.

Answer 10

"You can because you think you can." A quote I've seen attributed to the Roman poet Virgil. Have also seen it translated as 'You are able because you think you are able.'

It's a great quote and I've used it to get programmers, skaters, climbers etc to do things they thought they couldn't do or hadn't learned yet.

Answer 11

When tackling a complex problem with programming, it's often disheartening and counterproductive to just plop yourself in front of an empty screen and start writing code. you'll almost immediately end up eye-deep in some almost completely unrelated task that you've discovered needs to be done first, and 4 hours later, you'll have written a lot of code but will appear no closer to your goal than when you've started.

Instead, start by drawing up your proposed solution on a paper or whiteboard, starting with general concepts first, and slowly filling in the details until you've drafted out your entire program. You can solve the high-level problems at this point, before doing any coding, while the design is still flexible. By the time you've finished, all you'll be missing is the code.

Then, when you start programming, you won't get discouraged because the programming work is just a matter of filling in the implementation. You've got a map and you know exactly how much work remains to be done. You've created the solution already, now you're just translating it into your programming language.

Answer 12

First, some calibration is needed - we need to know whether your problems are really that complex, and whether your feeling is justified. Try ask the people around you if they can solve the same problem, and if possible, ask a few people to show you how to do it. This will give you an estimate of the problem's depth.

---

(The rest of my post is just random collections of suggestions.)

If you don't know the solution to a problem because it is too large or too vague, try ask yourself questions. If you can identify the right sub-questions, you can then break the large/vague problem into smaller / more concrete sub-problems which allows you to make progress.

Occasionally, take a break (by not thinking about the problem) and come back later.

On the psychological side of the problem. Please reflect on your fear to see whether your fear is caused by a feeling of competition. Sometimes a person can frame oneself into a sense of competition, e.g. in school or at work. In particular, try to find out whether you are creating negative feedbacks by interpreting any negative signals as an indication of inferiority (e.g. took longer than others to solve a problem, or didn't do well on something, or criticisms). These will compound with the sense of fear.

I recommend http://www.amazon.com/Pragmatic-Thinking-Learning-Refactor-Programmers/dp/1934356050

Answer 13

Now you are young and stupid. But when you grow old and stupid, you must be smart:
1. Do not deal with problems you can not deal with. Delegate them/make them anyone else's problems.
2. Find trivial but not-yet-addressed issues. Convert them into problems for the Big Management and solve them.
3. Bash the wannabies addressing tough problems as risk-takers.
4. Advice them (see points 1-3) in order to create an impression for a team leader.
5. Rinse and repeat.