How do you know what a program needs to do to complete a given task?

Question

I am a noob when it comes to programming. I just know some Ruby, that's really it when it comes to programming, but it's definitely an interest.

In learning to program, I give myself tasks to complete in order to better learn Ruby but I am finding that a lot of my problems in programming deal with how to execute a task.

For example: In writing a SERP checker (which is, sadly, half complete because I can't read PHP) I found a PHP script of what I was programming. I used it as sort of a template in order to write my checker. (I'm not actually going to use my checker, just a task for me to learn.) Anyway, when I was investigating the PHP I learned that the script does a lot of things I wouldn't expect it to do.

I knew NOTHING about how I was going to get the script to make a Google search, how it was going to collect the data, etc.

How do I learn these things? If I were to make this script from this guy's template, all I would learn is how to make a SERP script. But how did this guy learn how to make the script? What elements to put in/use?

Something a friend found in my script (a bug) that I never even considered was related to differences in Windows vs Linux (I unfortunately have to program in Windows until I partition my hd and slap a linux distro on there. The only reason I have Windows is because the whole Steam on Linux thing was a hoax.) It had to do with newlines, spaces, or something.. I don't remember off the top of my head.

How was I supposed to have the foresight to know about the bug? How would I have caught the bug if my friend who is uber savvy hadn't pointed it out? And really, the most important part of my question is the above part: How do I know what elements* (*if I use the word 'functions' here I worry it would be confused with methods...) I need to put in a program in order to complete a given task?

Answer 1

How do I know what elements I need to put in a program in order to complete a given task?

Someone wants the program to do something. This someone is either you, or someone else. At any rate, one typically needs to think through the expected functionality of the program. It helps to think in use cases: series of interactions between the program and the outside world to achieve a specific goal. (In agile lingo, these are also called user stories). (E.g. in order to login, the user has to type his userid and password, then the program must verify these credentials and either display an error message if they are invalid, or display the welcome screen if the login is successful.)

One needs to identify all the desired use cases, then analyse them one by one to figure out what concrete functionality each step requires, what are the possible outcomes and how to deal with each, etc. (E.g. in order for the user to enter her credentials, the app must display two edit boxes on the UI, and a "Login" button. When the button is pressed, the app must read the content of the edit boxes, then validate them. For the validation, the app needs to connect the user database and verify that the given userid exists, and the given password is correct for this user. Etc.)

How do I learn these things? If I were to make this script from this guy's template, all I would learn is how to make a SERP script. But how did this guy learn how to make the script? What elements to put in/use?

We all learn programming through solving problems. Many of the problems have been solved by others before, so we can find solutions to (identical, or similar) problems on the net. We try to understand what the script does by reading through the code, running it and watching the results, tweaking the input and the code in various ways, and - last but not least - asking help from friends, as you did.

The guy who wrote the script probably learned the same way, just he has been doing it longer than you :-)

How was I supposed to have the foresight to know about the bug? How would I have caught the bug if my friend who is uber savvy hadn't pointed it out?

You aren't supposed to foresee every possible problems - none of us do. Over the course of a programmer's life, one gets to encounter a great deal of bugs (either in his/her own, or in others' code), and gathers experience from all. So an experienced programmer may be able to spot a bug in the code because she recognises a pattern seen before, or by "running" the code in her head and analysing the outcome. These experiences and skills can be practiced and learnt. If you practice, you too will get better in time :-) However, even the most experienced programmers do oversee bugs, or find new kinds of bugs never encountered before. They just usually are aware of their own limitations, so they know the importance of proper testing.

Answer 2

How do you know what a program needs to do to complete a given task?

This question summarizes all of computing.

That's what "Programming" is

The answer is so long and so involved that it cannot be summarized here -- or anywhere.

Programming is not easy. Some argue that it's one of the hardest things mankind has invented for itself to do.

There's no "royal road" to programming. It's a lot of work.

Start now.

1. Find a "tutorial" on your favorite language. You already know some PHP and Ruby. Start there. You'll have to learn more languages before you're done.

2. After you've done the entire tutorial, do two more. Really.

   If you're struggling, go to a community college and take programming courses. That may be easier than trying to teach yourself. It's hard, remember?

3. After you've come to grips with the language, do a lot of projects. A lot.

4. Start reading up on "Requirements" and "Design" and other topics outside the programming language part of programming.

5. Read up on "Algorithms" and "Data Structures". You may even have to take some remedial "Logic" and "Math" classes somewhere (or find a good book.)

Plan to put in 10,000 hours to master this topic. That's the magical 5 years experience cited by Malcolm Gladwell.

The topic is Large and Difficult.

Answer 3

How was I supposed to have the foresight to know about the bug?

You weren't.

Read Teach Yourself Programming in Ten Years from Peter Norvig, it will set you on the right track.

Answer 4

Like how do you KNOW what steps are needed to make her idea come to life?

basically there 2 possible ways:

• apply some agile method. i.e. try to start from something small what she want and in iterrative and collaborative manner continue with next things which she wants

• try to understand big picture or the project talk to her. try some mockups simple data flow and workflow diagram (simple enough for her to understand). As soon as you have bigpicture try to build the product design from big blocks like: "GUI data entry", "database", "GUI reports" and so on...

the 1st one is probably preferable for you if you don't have enough experince.

regarding bugs:

• always expect that you will create bugs

• if you use new for you tools/technology expect some troubles with them

• always keep in mind that testing is part of development as well as bugs fixing

Answer 5

My answer is going to sound a bit like "To understand recursion, one must first understand recursion" but there's more to it really.

To understand what you need to do, you must have some essential knowledge about your domain. You can't google or SO everything - you have to know what your options are. If you're building a GUI, you need to know about event loops, the windowing toolkit and so on. If you're building a data driven application, you need to know how databases work.

If you're doing stuff for the web, you have to understand how browsers work, how webservers work, how the communication between them works, and you have to know this in quite some level of detail. Try writing down exactly what happens when you make a request in your browser to a server running PHP, in as much detail as possible, and you'll discover where the gaps in your knowledge are.

This has the additional advantage that you'll learn the terminology, and know what to google for.

As for your second point, that's an excellent question: how do you guard yourself against types of bugs you never even considered? Partly simply experience - you're going to make hundreds of mistakes, and learn from them, and if you're a good programmer, you won't make that mistake again. Forgetting that filenames may contain spaces? I've been there.

But if you're very careful, you can avoid bugs by very precisely stating your assumptions: "I assume that there is a file named foo in a folder named bar can always be read by open("bar/foo"). Wait, do I know for sure that that file exists? That I have permission to read it? That is isn't too big to read? That the notation bar/foo works in my programming language on all platforms?

Being very strict in what you assume will dramatically lower the number of errors in your code.