I learned my first real language, C, with infrequent access to the internet and very few books. Getting stuck was invariably a part of my learning process, perhaps the most important part at times. Sometimes, it's good to struggle. This was before the web as we know it came to be known in mass consumption.

When I got stuck, I'd go do the most menial things I could possibly do, because I found it stimulated my creativity. I was also fortunate enough to have a neighbor that was also learning C, so I'd print my code or save it to a floppy and head over to his house to look at it together. When I got really stuck I'd just have to wait until I could get to school and get access to Bitnet. I spent a lot of time at the library.

You do the things you'd do with Internet, you just spend a lot more time and money on doing them. The Stack Overflow of my generation was the computer lab on campus, which was also a wildly successful extortion ring. People paid dearly to figure out they were solving the wrong problem to begin with.

Believe it or not, programmers have been getting stuck and unstuck without the assistance of the Internet for years. You just have to work a little harder at it, and bring extra firecrackers to bribe the ninja in the computer lab.

Binary search the problem ... that is, break the code halfway through. Is the issue happening before or after this point? Go to half with the problem, break that in half, repeat until you've narrowed it down. Issue found in maximum log_2(lines of code) tries, ie a stupid small number.

Binary search also works for finding a code revision where a new issue started popping up.

It slices, it dices, it makes julienne fries! Binary search today!

Before there was stackoverflow etc., what helped us most was the ability to call a friend who happens to be an expert in the area. Therefore, networking (making friends with other programmers, not installing cables) was invaluable back then - and it still is, though more in business matters than in technical questions.

You always have your life lines. Ask the audeince, phone a friend, etc. And of course the good ole library, whether you own a book or not.

The internet is a great tool, but man made it to the moon without it!!!

take out a piece of paper and draw your code.

for each routine, create a picture that represents the input and output of each method.

now go back and look at your code. debug/trace your way through the code. ensure that every single piece of data is exactly as it is in your picture.

once you inspect it, you may see that the code/data does not match your picture. then the answer is obvious.

(i presume that you can trace/debug your code and inspect variables - aside from compiling/executing your code, it is the second most important tool to a programmer)

In some cases this problem can arise in the workplace. If this is the case for you, talk to your employer and explain that to get the best productivity out of you, it will be necessary to grant you at least limited internet access. Many internet filtering tools are available if the employer is concerned about time-wasting, including cloud-based ones that require no software installation or maintenance.

If this problem arises at an educational establishment, on the other hand... as a student, you should see yourself as a customer. Demand to know why the best source of knowledge the world has yet produced is not available to you on the premises!

In case when something doesn't work for me I try to make it work in a different language/paradigm.

I normally do a scientific work in python. Sometimes I can't figure out why a bit of code gives me wrong results or does not give them at all. As in python I often use classes, I try to perform the same task in a language which does not use classes as the first choice (Matlab/Octave or R in my case). Also I breaking down the problem to small pieces. So in my second language I don't rewrite whale hundreds of code but only a bit making it a simplest possible.

I have to admit, in most cases it does not finish in full code. After starting to think in different paradigm I often start to tweak my original solution and it turns up to be correct.

If I can't figure out why it does not work it means that my way of thinking is wrong in the first place. I have to take a break from the problem to catch some sort of distance. I try something different enough to get rest.

Obviously there are some other ways. Sometimes I going to my friend from my office and ask him (often on phone or skype) if I can explain him what I am doing only to check if I am clear. I don't expect his advise, only understanding. Often he ask questions like: "why you doing this, this way" and often I find I can't answer this question and this is the problem to fix. Sometimes after paraphrasing a whole story I have my solution seen from a different angle at it helps me to solve the problem.

There are also methods to do it by your self, taken from NLP etc. but the basic idea is to paraphrase, work in different paradigm and communicate out your ideas.

This is what I do, grab a pen, paper then analyze the problem. Jot down some points of your approach. If it's a programming problem, rewrite algorithm, and try to implement it in the language you know. You can find a solution.

The answer to this question, varies according to the environment you live-in, and it's debatable. If you have descent network of people around you, you can probably get ideas, by asking them. What if there's no Internet or stack-exchange ? However, first source of solution provider is your approach to the problem and your effort.

Lots of answers point to a very traditional approach for general code problems, debugging whether with a formal debugger or a with a manual strategy that mimics debugging.

Another well known way to approach a code problem is to write an automatable testbefore you even look at the code in question. Maybe write two. Maybe three. Design your tests to isolate the aspects that contribute something to the problem function. Then write a few for that particular function, with varying values for the contributions (use some variation in the contribution: known or expected 'good' values, and known or expected 'bad' values. Exercise the function in a manner that you would if it was being used for real, but substitute or fake parts that are extraneous.

Other problems, perhaps with tooling or runtimes, are often configuration issues. Perhaps certain environment variables are needed and normally set, but something about the environment setup changed and those values are no longer defined. Perhaps a single security patch or security policy change did the damage (eg host/port restrictions, permissions, ownership). The important thing is to take note of whether or not that if until now, everything normally worked, and if so, what changed, even if it may on the surface appear unrelated, it still may have indirect but significant consequences.

One time while working on a COBOL project, the C tooling was upgraded. Shouldn't be an issue for me? But it was. A particular version of a library from the C package was necessary for certain aspects of the COBOL runtime process. This dependancy was only one of many of the C package files that were updated, but it was still important, and not part of the 'stated' requirements for our COBOL package. And while the issue was relatively easy to address in our development environment, the same solution wouldn't work on the client/user machines, so we had to change how our software was linked and distributed.

If it worked before, and anything changed, and it doesnt work now, the anything should often be the first culprit.

If something was changed, but the effect wasn't apparent in the outcome, it might be a stale intermediate build file, a stale cache, any other locked file, or stuck process.

If it worked before, and absolutely nothing changed, I often move to looking at hardware. Cables securely and properly plugged, free of significant knicks or abrasion that might result in short-circuiting or interference or worse. Ram test, drive checks, etc. Parts age and fail. Dust and heat are mortal enemies of electronics. Is the machine of concern in a mostly ideal environment for the computer and is proper dust preventing and removal performed.

Ask help from others. As programmers, we have a certain pride in our abilities and in solving our problems ourselves. However if you're going nowhere, and your schedule is suffering, then it's time to ask help. A fresh pair of eyes may have the answer or may point you in another direction.

Also, step back a bit and give yourself a break. I've solved some of my design and programming dilemmas thinking about the problem during my bus ride to work. The stress-free, relaxed, and unrelated work-setting has enabled me to think more creatively.

On the C# side of things, I use tools like ILSpy to check out what's going on or even how a feature may have been built out it.

I agree with "take a break".

If I want to continue doing something mentally challenging I pull out my tablet and read some articles from my reading list (using the pocket app with offline sync).

There are so many ways to solve a problem.

1. taking a break
2. talking to a duck or writing the issue
3. searching the solution on internet.
4. backtracking
5. split the code to find which code execution is creating a problem.
6. understand the issue, the big why?
7. get the domain knowledge of the language or third party library as much as you can.
8. write your options related to the different tools of the language, one thing can be solved with different ways.
9. use a debugger
10. discuss the problem with peers.

I had the same situation , try to finish what you can do , assume that you did the hard parts 'by making a fake data or result that you are expecting' , then when you be able to access internet find a solution to the hard parts then apply it and test your code.