Problem Solving - Strategies?

Professional
1

Hello Everyone

I am struggling with the speed in which I am able to solve problems. I lack a system and am looking into developing some good habits that will help me solve problems a little faster. Currently I am spending a lot of time just staring at the screen wondering how to get the neurons in my brain to fire.

Is there something that you find is helpful when attempting (in a very general sense) when tackling a problem?

Or is there just an improvement in my skill set needed when I stare at the screen?

I’m looking for anything from little things you do every time you approach a problem to full blown methodologies, everything helps.

Thanks.

2

Personally the biggest way that I approach most problems involves me physically writing something out, be it on a whiteboard, sticky-notes, notebooks and even on windows from time to time (I’d be a bit cautious about that last one).

I find that writing helps to jump start some processes even though what might be written is extremely literal and redundant and helps lay out a plan of action that you can visualize. Just looking over at my white board now, I was stuck on an interface problem, so I drew it out and listed what it needed to do. Then from the literal lines, I have bits of real code written under it that I thought I should try or thought might work. Things such as:

[ul]
[li]Get User Info
[/li][li]Choose Directory
[/li][li]Choose Section listed in directory
[/li][li]Create New project in chosen section
[/li][/ul]
ect.

I have a few other methods that are used but most of them start off with simple pseudo-code like this and go from there. I hope this might help in some way though.

3

Like Thomas, I also typically tend to write and doodle stuff out, whether in a notebook, or in an art package like Photoshop. Other times I’ll just type out a general outline of what needs to be done. Either way, I don’t get hung up on specific implementation or bugs, and just focus on the general flow and structure.

Another thing that I find helps, is vocalising. There’ve been many a time where I’ve been hung up on something for a while, banging my head against the keyboard; then I have a chat with the lead, and as I’m talking through the problem, I end up talking myself through the solution.

4

Whiteboards, sketches, lists, talking it through with anyone that will listen. Also organization is key, keep track of the issues and your ideas on how to resolve them. I also spend a lot of time researching, scouring documentation, or even just fiddling around to see if Maya may already have a built-in tool that I can use for a different purpose.

Sketches are huge for me, especially with some of the pattern recognition tasks I’ve faced. Been stumped for weeks on what are essentially puzzles, but continued for far to long to treat them as coding challenges. You can save yourself a lot of headache by recognizing the difference and picking up a pencil to work it out first.

5

Binary search.

Halve the problem and at some point you will have something useful. This works both for debugging and figuring out stuff.

SamiV.

6

Flow diagrams help me trememndously. I can’t solve many problems without drawing one out on my pad.

7

[QUOTE=samivRMD;13948]Binary search.

Halve the problem and at some point you will have something useful. This works both for debugging and figuring out stuff.

SamiV.[/QUOTE]

Agreed. For me, I don’t write or sketch, but I do chat with other people a lot. Get all the information you can. You can’t solve a problem you don’t have the information about. It not uncommon for me to go running through the studio asking people questions.

8

Depending on the problem, but usually first I doodle it down talk to some people that might give me some good feedback and then back to it.

Sometimes to take a break and focus on other stuff to take a new approach later.

9

I talk things through, I usually keep a personal recorder on me (so as to not waste phone battery). If i’m really stuck, I have some go-to absurdist writing that I’ll read for 15 minutes while having a beer.

A lot of times being stuck is because you have too many arbitrary connections from trying to get things mentally connected and make them work. Absurdist (or Taoist or Zen) writing is frequently very good for clearing away a lot of the mental cruft that you’ve been focusing on for hours.

10

If you are interested in full-blown methodologies, here are two books I’ve enjoyed.

Back of the Napkin: Solving Problems and Selling Ideas with Pictures - I love this book. Insightful examples, fun pictures and case studies that are useful at an individual or group/company level.

Think Better - This one is a bit of a heavier read with lots of fancy acronyms to remember and I’ve found little chance to actually implement anything from it. This is a system that large organizations could follow to solve very big problems.

11

Thanks Clesage i must consult these books. Thanks for sharing.

12

failing makes you stronger and smarter the next time around :slight_smile:
i tend to create quick prototypes, which then lead to edge cases and deficiencies which i roll into future attempts.

13

Wow! Thanks for all the feedback everyone. Looks like I need to get a notebook, talk to myself more, and bounce ideas off other people.

[QUOTE=clesage;13958]If you are interested in full-blown methodologies, here are two books I’ve enjoyed.

Back of the Napkin: Solving Problems and Selling Ideas with Pictures - I love this book. Insightful examples, fun pictures and case studies that are useful at an individual or group/company level.

Think Better - This one is a bit of a heavier read with lots of fancy acronyms to remember and I’ve found little chance to actually implement anything from it. This is a system that large organizations could follow to solve very big problems.[/QUOTE]

Also, thanks Chris for the book references, I will definitely check them out.

Feel free to keep posting ways that you solve problems - the more the merrier.

14

[QUOTE=samivRMD;13948]Binary search.

Halve the problem and at some point you will have something useful. This works both for debugging and figuring out stuff.

SamiV.[/QUOTE]

Could you maybe give a specific example of this? I don’t quite understand.

15

[QUOTE=Erkmuss;13944]Hello Everyone

I am struggling with the speed in which I am able to solve problems. I lack a system and am looking into developing some good habits that will help me solve problems a little faster. Currently I am spending a lot of time just staring at the screen wondering how to get the neurons in my brain to fire.

Is there something that you find is helpful when attempting (in a very general sense) when tackling a problem?

Or is there just an improvement in my skill set needed when I stare at the screen?

I’m looking for anything from little things you do every time you approach a problem to full blown methodologies, everything helps.

Thanks.[/QUOTE]

When you say problem solving, do you mean support requests, designing pipelines, or figuring out implementation details? Personally, I have different solutions for all three.

Solving a support request is simply a matter of deductive logic. If you don’t know what the answer is, find out all the things that it isn’t. For example…

“Scott, my model looks different in Maya than it does in the game!”

  • Re-export the model from Maya yourself (eliminating user error)
  • Load the exported data in a viewer (eliminating exporter error)
  • Rebuild the game on another platform (eliminating any platform-specific issues)
  • Export another model (eliminating any generic build errors)

From there, the solution could only be a small number of things.

For designing pipelines, I find the best approach is to talk to others. Find out from the artists what they want, find out from the coders what they need.

From there, it’s just a case of breaking down the problem. If you can’t solve the whole thing yet, just write the parts you can, in small, self-contained modules of code. After doing this, solving the problem becomes a case of putting your code fragments together in the right order.*

When it comes to implementation details, I find the best starting point is to research. Find others who have implemented something similar to your problem, draw inspiration from the best bits of their solutions, then improve them by adding your ideas (even if you are inventing the wheel, chances are someone else has already invented the box).

*PS: Bonus points for those who noticed I answered my opening question using this methodology! :slight_smile:

16

[QUOTE=Erkmuss;13962]Could you maybe give a specific example of this? I don’t quite understand.[/QUOTE]

I believe what he means is to break the problem into bits by testing half the potential problem at a time. I do this a lot with bugs or errors.
It’s similar to what Scott just described. Start big and close in.

Let’s say I get a crash whenever a certain object appears in the game. First I’ll try removing the object. Does the crash go away? Yes. Ok, so it’s the objects fault. After this I’ll try removing/replacing parts of the object. Try a different shader, try a different mesh, and so on until you find out where the problem lies.
It’s useful to write down what you have tested, and what gave positive results. I use tables for stuff like this.

Tip: Google “Half-splitting”

17

Sometimes I just tend to talk to myself or go grab a coffee and talk through the problem with other classmates.

18

[QUOTE=ScottHarber;13969]When you say problem solving, do you mean support requests, designing pipelines, or figuring out implementation details? Personally, I have different solutions for all three.

Solving a support request is simply a matter of deductive logic. If you don’t know what the answer is, find out all the things that it isn’t. For example…

“Scott, my model looks different in Maya than it does in the game!”

  • Re-export the model from Maya yourself (eliminating user error)
  • Load the exported data in a viewer (eliminating exporter error)
  • Rebuild the game on another platform (eliminating any platform-specific issues)
  • Export another model (eliminating any generic build errors)

From there, the solution could only be a small number of things.

For designing pipelines, I find the best approach is to talk to others. Find out from the artists what they want, find out from the coders what they need.

From there, it’s just a case of breaking down the problem. If you can’t solve the whole thing yet, just write the parts you can, in small, self-contained modules of code. After doing this, solving the problem becomes a case of putting your code fragments together in the right order.*

When it comes to implementation details, I find the best starting point is to research. Find others who have implemented something similar to your problem, draw inspiration from the best bits of their solutions, then improve them by adding your ideas (even if you are inventing the wheel, chances are someone else has already invented the box).

*PS: Bonus points for those who noticed I answered my opening question using this methodology! :)[/QUOTE]

Thanks for the step by step Scott! I will definitely keep that in mind when I’m talking to potential employers for ways I would figure out problems.

I believe what he means is to break the problem into bits by testing half the potential problem at a time. I do this a lot with bugs or errors.
It’s similar to what Scott just described. Start big and close in.

Let’s say I get a crash whenever a certain object appears in the game. First I’ll try removing the object. Does the crash go away? Yes. Ok, so it’s the objects fault. After this I’ll try removing/replacing parts of the object. Try a different shader, try a different mesh, and so on until you find out where the problem lies.
It’s useful to write down what you have tested, and what gave positive results. I use tables for stuff like this.

Tip: Google “Half-splitting”

And thanks Andreas for clarifying that, it makes a lot more sense now.

19

Thanks for sharing problem solving strategies.

20

Excellent, taking some mental notes here.

I think this is implicitly understand… but I was taught to always invest some initial time looking for small, stupid errors. Thats been quite good for shot fixing, where some probing can reveal that the problem is simpler than it first looked.