This seems like a common question all over the internet, and advice like what I got in university seems to be extremely rare. So I am going to do a series describing the method I learned from a guy who used to be a partner at a big fancy firm and worked on some extremely important things like airplane and air traffic control systems, military equipment and banking/financial systems.
When most people start out trying to learn how to program, they begin by trying to learn a language, this is counter productive and seems to put a set of blinders on a lot of folks as far as how other languages work, how programs can work and how to produce something you could actually call professional work.
We are going to start out with a few other things that should be done before you even write one line of code, all programming languages translate into something called machine language, this is a set of instructions that microprocessors are set up to follow mindlessly regardless of what you actually want them to do, there is an easier to understand version of this language called assembly (x86 is the most common example, 64 bit x86 is basically the same, it just has bigger memory addresses so it can work with more RAM). When you write a program and compile it, your code is translated into assembly, and then translated again into machine language. If you ever played the telephone game in preschool then you can probably see why it is important to keep this in mind when designing a program.
Just as all programming languages translate into a very low level language, they also all translate into a very high level language called pseudocode. Pseudocode is at such a high level, you can't even bother giving it to a computer because it will not know WTF it is supposed to do with it. But there is also an advantage to writing your program out like this first, and that is that pseudocode is the easiest programming language for people to understand. You want to write your program out in a way that is specific, but also easily understandable, so that before you begin actually programming it you have an exact idea of what it is you are working on and what it has to do in order to fulfill its purpose.
Another useful description you will want, before you actually start writing code, is a UML diagram. Pseudocode defines the function of a program, UML defines the structure. You need to define this structure before you create a program for the same reason you need to hire an architect before you build a house. You know you need a house, you know what you need that house to do for you, but you also need to know how that house has to be put together before you call the contractors and start working on it. Another reason you need UML is that for really big software projects that require teams of people to complete, you need to create a critical path diagram of some sort, and you need to have the structure of your program laid out first in order to do so, but that is beyond the scope of this tutorial.
So, how do we write out the pseudocode and UML? Well, if your program is simple enough, you can just jump right in, but if it is complicated and you are not sure what to write, you need to take another preliminary step, and that is to basically describe your program in plain English and draw up some kind of corresponding diagram. The description is self explanatory, it could be a paragraph or 100 pages, the diagram can be anything from a simple flow chart to an FSA, PDA or Turing Machine. The last three tend to twist most peoples minds into pretzels, so for the purposes of this tutorial we will start with a simple short description and flow chart.
For our tutorial example, I will show you how to program a simple calendar and daytimer application.
Description:
The program will allow users to input events into a calendar, it will also have a corresponding agenda page for each day of the calendar, a checklist of completed tasks and a to-do task list.
The user will be able to input events into the calendar and tasks into the to-do list, as well as place items on the to-do list into the agenda pages. The to-do list will indicate if something has been placed in the agenda or not, as well as show task deadline dates. Tasks that have been put into the to-do list and marked as completed will then be placed on the completed checklist.
Flow chart:
(this is a multi step process and I am at the library and do not have a mouse at the moment, I will draw it all up and add it sometime later today, feel free to begin asking questions and stuff though)
When most people start out trying to learn how to program, they begin by trying to learn a language, this is counter productive and seems to put a set of blinders on a lot of folks as far as how other languages work, how programs can work and how to produce something you could actually call professional work.
We are going to start out with a few other things that should be done before you even write one line of code, all programming languages translate into something called machine language, this is a set of instructions that microprocessors are set up to follow mindlessly regardless of what you actually want them to do, there is an easier to understand version of this language called assembly (x86 is the most common example, 64 bit x86 is basically the same, it just has bigger memory addresses so it can work with more RAM). When you write a program and compile it, your code is translated into assembly, and then translated again into machine language. If you ever played the telephone game in preschool then you can probably see why it is important to keep this in mind when designing a program.
Just as all programming languages translate into a very low level language, they also all translate into a very high level language called pseudocode. Pseudocode is at such a high level, you can't even bother giving it to a computer because it will not know WTF it is supposed to do with it. But there is also an advantage to writing your program out like this first, and that is that pseudocode is the easiest programming language for people to understand. You want to write your program out in a way that is specific, but also easily understandable, so that before you begin actually programming it you have an exact idea of what it is you are working on and what it has to do in order to fulfill its purpose.
Another useful description you will want, before you actually start writing code, is a UML diagram. Pseudocode defines the function of a program, UML defines the structure. You need to define this structure before you create a program for the same reason you need to hire an architect before you build a house. You know you need a house, you know what you need that house to do for you, but you also need to know how that house has to be put together before you call the contractors and start working on it. Another reason you need UML is that for really big software projects that require teams of people to complete, you need to create a critical path diagram of some sort, and you need to have the structure of your program laid out first in order to do so, but that is beyond the scope of this tutorial.
So, how do we write out the pseudocode and UML? Well, if your program is simple enough, you can just jump right in, but if it is complicated and you are not sure what to write, you need to take another preliminary step, and that is to basically describe your program in plain English and draw up some kind of corresponding diagram. The description is self explanatory, it could be a paragraph or 100 pages, the diagram can be anything from a simple flow chart to an FSA, PDA or Turing Machine. The last three tend to twist most peoples minds into pretzels, so for the purposes of this tutorial we will start with a simple short description and flow chart.
For our tutorial example, I will show you how to program a simple calendar and daytimer application.
Description:
The program will allow users to input events into a calendar, it will also have a corresponding agenda page for each day of the calendar, a checklist of completed tasks and a to-do task list.
The user will be able to input events into the calendar and tasks into the to-do list, as well as place items on the to-do list into the agenda pages. The to-do list will indicate if something has been placed in the agenda or not, as well as show task deadline dates. Tasks that have been put into the to-do list and marked as completed will then be placed on the completed checklist.
Flow chart:
(this is a multi step process and I am at the library and do not have a mouse at the moment, I will draw it all up and add it sometime later today, feel free to begin asking questions and stuff though)
