News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: How to solve problems using programming (thinking like a computer scientist)?  (Read 607 times)

seedhe

  • Newbie
  • *
  • Posts: 2
    • View Profile
Hi all,

I am currently doing Harvard's online programming unit CS50x through EDEX. I am currently up to the first problem set where you have to program mario.c and greedy.c. I am struggling with it. I understand all concepts so far mentioned in the lectures (iterations, conditionals etc...), but when it comes to programming something, or solving a particular problem, my brain just stalls. I make a good start, but when it comes to putting it all together (FOR loops especially) I fail miserably. I cheated, and had a look at someone else s mario.c program, and after reading it, I understood everything, and it all made sense. What do you guys recommend I do to develop my mind to think more like a programmer, and to be better at solving problems with programming? Algorithm study? Does this problem solving ability just come with experience and exposure to programming?

Thanks

Disch

  • Hero Member
  • *****
  • Posts: 2639
  • NES Junkie
    • View Profile
It comes with experience.  Like with most other skills, practice makes you better at it, and after doing it enough you just kind of understand it.

The trick is to break problems down into very, VERY small individual steps, and focus on one step at a time.  If you keep looking at the big picture it's easy to get overwhelmed and not know where to start.  So just stop, ask yourself "how would I do this manually?" and sketch out the basic steps you'd take, then tackle each of those steps as their own programming problem.

And rinse/repeat.  If an individual step is still not obvious -- break it down even further and make smaller steps out of that.

Pluvius

  • RHDN Patreon Supporter!
  • Jr. Member
  • *****
  • Posts: 43
    • View Profile
Though my acquaintance with programming is pretty much entirely at the hobbyist level and I don't do anything remotely related as a job, I think most programmers would agree that another useful tip is just to write whatever comes to your mind that might solve the problem and try it.  If it doesn't work, then figure out why, make the appropriate changes, and try again.  Doing something and failing is a far better way of learning and solving problems than staring at the screen because you want to make something perfect the first time.  The computer is generally far quicker and more accurate at pointing out your mistakes than your own brain is.

Disch

  • Hero Member
  • *****
  • Posts: 2639
  • NES Junkie
    • View Profile
The caveat to that approach is that you should always understand what the code you're writing is doing.

A common mistake newbies make is they write some code that they THINK should work, but it doesn't -- and rather than trying to figure out why it doesn't work they just try to make random tweaks in hopes that they'll stumble into a solution.  Never do that.  Debuggers are your friend -- step through your code, watch what each line is doing and ask yourself "is this what it should be doing".  If you understand why it's doing what it does, you'll understand why it doesn't work, and you'll understand how to fix it.

Mario Bros.

  • Jr. Member
  • **
  • Posts: 25
    • View Profile
use scratch software to familiarize yourself with programming

if you can not make a simple algorithm, stop the programming, learn the algorithmic and then in last start learning the "programming"
PS: A bad request's reader is a bad helper

Trax

  • Sr. Member
  • ****
  • Posts: 479
    • View Profile
    • Trax ROM Hacking
Disch pretty much stated one of the most fundamental aspects of programming. Computers talk in very simple commands, so it makes sense to go step by step with small commands yourself.

Another thing that many programmers forget to do too often : take notes on paper. Write down, in normal sentences, what you need to do. Like pseudocode, but even more "pseudo". Sketch some graphs or flowcharts if needed. From there, you can get an abstract idea of what you try to accomplish, and it can help translating it into code.

FAST6191

  • Hero Member
  • *****
  • Posts: 2422
    • View Profile
"I cheated, and had a look at someone else s mario.c program, and after reading it, I understood everything, and it all made sense."

Is it cheating if you are learning for yourself on your own time, and moreover it saw you understand the problem you faced?

Anyway while I have a few things I could contemplate as far as philosophy of coding and ways to structure thoughts and approach problems, or the nature of maths*, I will actually go with "I'm still learning".

I watch a random video from someone like https://www.youtube.com/channel/UClcE-kVhqyiHCcjYwcpfj9w and while I can predict some steps and know to take certain approaches I still learn things, same for https://www.youtube.com/user/ChRiStIaAn008 (and newer defcon, ccc, black hat... talks) and frankly I also pick things up when watching the likes of https://www.youtube.com/watch?v=CINVwWHlzTY&list=PL96C35uN7xGLLeET0dOWaKHkAlPsrkcha and https://www.youtube.com/watch?v=zp4BMR88260&list=PL96C35uN7xGIJfSACtrXjxKcatdThkuJh despite them being aimed at rookie coders.

*an example I quite like is Seven Bridges of Königsberg. If you did the thing Disch said of break it down and you would probably end up with a nice brute force algorithm or something. If you know the maths you will know it is an example of an unsolvable problem.

Gyroballer

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
The "rubber ducky method" can help a lot. If you try to explain in detail to a friend, or just to yourself out loud, you may notice in the middle of talking or right after you're done explaining that something you said didn't really make sense.