- Learning to Program—The stages of programming
- Learning to Program – Some Terms You Should Understand
- Learning to Program – IPO Charts (Stage 1)
- Learn to Program- Flowcharting (Stage 2)
- Learning to Program – Flowcharting (Stage 2). — Decisions and Loops
- Learning to Program—Flowcharting (Stage 2) – Case Statements
- Learning to Program (Stage 2)—Flowcharting – Methods and Classes
- Learning to Program – Structure and Spaghetti Code
- Learning to Program – Pseudocode (Stage 3) an overview
- Learning to Program – Stage 3 Pseudocode commands and reserved words
- Learning to Program—Stage 3 Pseudocode examples Part 1
- Learning to Program – Stage 3 Psuedocode (Arrays)
- Learning to Program – Stage 3: Pseudocode—Methods
- Learning To Program—Stage 3.5 (UML Diagrams)
- Learning to Program – (Stage 4) Coding
- Learning To Program—Stage 5 Testing
- Learning to Program—Stage 6 (Documentation)
- Learning to Program – Stage 7 (Maintenance)
- Learning to Program—Random Thoughts with a Theme
- Learning to Program- Two Main Types of Errors
- Learning to Program – Integrated Development Environments (IDE’s)
- Learning to Program
This is probably the easiest stage—or should be. You should be creating documentation as you go through the previous stages (from your IPO and PAC charts to the flowcharts to pseudocode and UML diagrams and finally the code itself and results of testing). Stage 6 is writing up the final documentation explaining what you were trying to accomplish and how you did it. It should organize the documents from the other stages.
This is also the stage that most people hate to do. The thing is when someone else has to do Stage 7 (Maintenance) or someone wants to upgrade your programs to solve a new problem, this documentation will make their (or your) lives a million times easier. Documentation includes the comments inside of your code—but should not be limited to that.
You should also include any problems that you had and how you overcame them (or the workarounds that you put in place until you can overcome the problems). It should include features that you started, but could not implement—along with information on how far into the feature you were able to delve. Included in the problems are other experiences that you had. Even if they aren’t problems, if they are something that another coder may find useful (or you may find useful down the road), document them.
If you’ve been keeping accurate documents along the way, this should be the easiest step for you. If you haven’t been keeping accurate documentation, then you have just entered Dante’s fifth plane of Hell. Either way, this will ease the transition into Stage 7.
And with that, we will cover Stage 7 (Maintenance).
Have a great day:)