[size=small]If you're having trouble fixing a bug,[/size]
[size=small]1. Check to see if the bug is already fixed or somebody else has made progress on the bug.[/size]
[size=small]2. If the problem isn't solved, manually create an environment that reproduces the bug with minimal human interaction or at least a set of easily reproducible steps. Then, use a debugger to narrow down where the bug occurs.[/size]
[size=small]3. If the problem isn't solved, identify something in the program that always occurs when the bug occurs, log intermediate states, and look for patterns existing in the buggy logs that don't exist in the non-buggy logs. Then, use a debugger to narrow down what causes that pattern to occur. Repeat until you find the bug.[/size]
[size=small]4. If the problem isn't solved, choose to either mark as WontFix or do something that is going to suck (e.g., procuring hardware you don't currently own or asking for access that you probably won't receive).[/size]
[size=small]If you're having trouble building a program,[/size]
[size=small]1. Ask Google and StackOveflow.[/size]
[size=small]2. If the problem isn't solved, read the build source code and debug it if necessary.[/size]
[size=small]3. If the problem isn't solved, reach out to the author and tell them what you tried in 1 and 2.[/size]
[size=small]4. If the problem isn't solved, just give up. You have better things to do with your life than work with software written by somebody who doesn't want to support it.[/size]
[size=small]If you're having trouble designing a program,[/size]
[size=small]1. Look for similar programs and copy their architecture. Don't tell anyone you did this since it is probably illegal.[/size]
[size=small]2. If the problem isn't solved, you're probably working in a highly specialized or secretive field and need to read some books. Go find books on your topic, read the relevant sections, and apply the theory.[/size]
[size=small]3. If the problem isn't solved, you're probably working at the cutting edge of a highly specialized or secretive field and need to read some journal articles. Drum up some keywords for your program, search Google Scholar, and procure the articles from your favorite source. Write a small demo program to see if the article is even correct. Then, apply the theory to your program.[/size]
[size=small]4. If the problem isn't solved, you're really on the cutting edge. It might be years before you come up with a solution. Either give up, or go learn how to do CS research.[/size]
[size=small]In all of these cases, you can probably avoid talking to anyone if it's your own code. If you're a team member working on a large project, especially one you couldn't give two shits about, you can also do one of the following.[/size]
[size=small]1. Give up immediately. Tell your manager, coworker, or any other stakeholder that this bug isn't worth fixing. This works surprisingly well very often.[/size]
[size=small][font=Roboto, sans-serif]2. If the problem isn't solved, try to delegate it to a team member by saying that he is a "subject matter expert" and would be better at solving this problem.[/font][/size]
[size=small]3. If the problem isn't solved, find a "band-aid" fix that solves the problem with a hack (e.g. making a button "disabled", preventing problematic accounts from accessing buggy code, etc.).[/size]
[size=small]However, the most important method for solving a problem is designing a method in the first place. Once you start looking back at the mistakes or successes of your most recent bug, build, or design problem, you can begin to create your own checklist like I did above. This process of process refinement is like saving for retirement; if you start sooner, you will reap greater rewards.[/size]