5 ms·

Picked up a few books, wrote basic programs, etc. When it got harder, found ways to ask people questions. I usually get frustrated when it comes to solving pu

Picked up a few books, wrote basic programs, etc. When it got harder, found ways to ask people questions. I usually get frustrated when it comes to solving puzzles that aren't linear programs.

spooneybarger 16y ago
What is causing the frustration?
- amorphid 16y ago
  I can see the solution in my head as a picture, not words. Maybe I need to practice framing problems more.
  - spooneybarger 16y ago
    I dont ever see words. Sounds like you might need practice figuring out how your pictures relate to code.
  - po 16y ago
    If you are a visual learner, you should make sure you can draw statecharts (not decision/flow-charts), process diagrams, UML-style diagrams by hand. Learn the conventions. Then learn the design-patterns in the gof book and make sure you can draw a singleton, delegate, etc... Next bust out a notebook and start trying to draw your solution (by hand) before you sit at a keyboard. IMHO all of the UML diagramming software are a bunch of crap but being able to understand a bunch of code as a picture should help allow your brain to see the forest for the trees.
  - chriseidhof 16y ago
    I was amazed when I saw some of the smartest programmers I know drawing pictures of their problems. I always thought that you had to do everything in your head, but that's definitely not the case. So draw pictures, figure out how they translate to code.
  - 10ren 16y ago
    I can see how that mismatch would feel frustrating - more so than if you couldn't see the solution and had to muddle about in exploratory code to discover it. re "practice framing": I find that asking the question is very helpful for clarity - and then defining the key nouns in it.
  - KevinMS 16y ago
    This is actually good, its how I do it, and I have success. You see programming as an abstract mechanical thing rather than abstract descriptive thing. Take a look at http://users.evtek.fi/~jaanah/IntroC/DBeech/3gl_flow.htm http://users.evtek.fi/~jaanah/IntroC/DBeech/3gl_flow.htm and get the gist of the symbols, then chart out things like if, if/than, while, for, etc. Don't forget do/while, since this is also a fundamental, but its not always represented in your language of choice, and is sometimes simulated with things like an infinite loop with a break. Move up to some simple programs. These symbols don't represent data structures (arrays, objects) so you can fudge that part. When it clicks then stop using it. But keep in mind, when you run across something where the logic is confusing, or especially if you can't figure out a clean way to represent the flow, come back to your old friends, and you'll be amazed at how they will guide you. I still fall back on flow charts, they aren't a crutch, they are a tool.
  - Chris_Newton 16y ago
    That's interesting, and actually quite encouraging: it suggests that you do think in terms of abstractions of the problem you're trying to solve, which is arguably the most fundamental skill in programming. If your difficulty is that you haven't got the mechanical process of turning your thoughts into code down yet, that's a much easier thing to overcome. Could you share with us what books and programming languages/tools you've been using? While there are certainly common ideas, different types of language take a different approaches to describing a program. Maybe whatever you've chosen doesn't suit your way of thinking particularly well, and you would find another tool more intuitive at this stage.
    - amorphid 16y ago
      The book I've had the most luck with is Learning To Program by Chris Pine. There's a question in the book about counting the sections of land on a standard X,Y grid map. That would be a good example of a problem that blows up my brain.
      - Chris_Newton 16y ago
        Which of these would you say is closest to your difficulty? a) You don't understand what the problem means. b) You can't describe an algorithm that would solve the problem in plain English or "pseudocode". c) You could describe the algorithm informally, but don't know how to code it.

Picked up a few books, wrote basic programs, etc. When it got harder, found ways to ask people questions. I usually get frustrated when it comes to solving puzzles that aren't linear programs.

spooneybarger 16y ago

What is causing the frustration?

amorphid 16y ago
I can see the solution in my head as a picture, not words. Maybe I need to practice framing problems more.
- spooneybarger 16y ago
  I dont ever see words. Sounds like you might need practice figuring out how your pictures relate to code.
- po 16y ago
  If you are a visual learner, you should make sure you can draw statecharts (not decision/flow-charts), process diagrams, UML-style diagrams by hand. Learn the conventions. Then learn the design-patterns in the gof book and make sure you can draw a singleton, delegate, etc... Next bust out a notebook and start trying to draw your solution (by hand) before you sit at a keyboard. IMHO all of the UML diagramming software are a bunch of crap but being able to understand a bunch of code as a picture should help allow your brain to see the forest for the trees.
- chriseidhof 16y ago
  I was amazed when I saw some of the smartest programmers I know drawing pictures of their problems. I always thought that you had to do everything in your head, but that's definitely not the case. So draw pictures, figure out how they translate to code.
- 10ren 16y ago
  I can see how that mismatch would feel frustrating - more so than if you couldn't see the solution and had to muddle about in exploratory code to discover it. re "practice framing": I find that asking the question is very helpful for clarity - and then defining the key nouns in it.
- KevinMS 16y ago
  This is actually good, its how I do it, and I have success. You see programming as an abstract mechanical thing rather than abstract descriptive thing. Take a look at http://users.evtek.fi/~jaanah/IntroC/DBeech/3gl_flow.htm http://users.evtek.fi/~jaanah/IntroC/DBeech/3gl_flow.htm and get the gist of the symbols, then chart out things like if, if/than, while, for, etc. Don't forget do/while, since this is also a fundamental, but its not always represented in your language of choice, and is sometimes simulated with things like an infinite loop with a break. Move up to some simple programs. These symbols don't represent data structures (arrays, objects) so you can fudge that part. When it clicks then stop using it. But keep in mind, when you run across something where the logic is confusing, or especially if you can't figure out a clean way to represent the flow, come back to your old friends, and you'll be amazed at how they will guide you. I still fall back on flow charts, they aren't a crutch, they are a tool.
- Chris_Newton 16y ago
  That's interesting, and actually quite encouraging: it suggests that you do think in terms of abstractions of the problem you're trying to solve, which is arguably the most fundamental skill in programming. If your difficulty is that you haven't got the mechanical process of turning your thoughts into code down yet, that's a much easier thing to overcome. Could you share with us what books and programming languages/tools you've been using? While there are certainly common ideas, different types of language take a different approaches to describing a program. Maybe whatever you've chosen doesn't suit your way of thinking particularly well, and you would find another tool more intuitive at this stage.
  - amorphid 16y ago
    The book I've had the most luck with is Learning To Program by Chris Pine. There's a question in the book about counting the sections of land on a standard X,Y grid map. That would be a good example of a problem that blows up my brain.
    - Chris_Newton 16y ago
      Which of these would you say is closest to your difficulty? a) You don't understand what the problem means. b) You can't describe an algorithm that would solve the problem in plain English or "pseudocode". c) You could describe the algorithm informally, but don't know how to code it.