Mathematical
Silver Coder
Hey there.
Over the past few weeks, I have been writing advice-pieces for newer programmers, who don't know where to start, what to do, all of that. This is the third one out of three, so far. You can read the other two, here:
Now today's topic is all about building and maintaining your project. Something that takes time to improve on. When you first start out in programming, your projects won't be perfect. They'll be small. They may be very buggy or poorly-written. They may even be very slow and take up a lot of space on your disk. But as I said, you'll improve over-time to stop these issues from happening.
When you're going to be starting a new project, you should first plan-out the project. What will it be capable of doing? How and on what platforms will it run on? What are it's dependencies(Other programs and libraries that your program will rely on to work)? You'll need to ask these questions to yourself first. Once done, you can move onto how the flow of the program will work. Will it first boot-up and instantly go into an infinite-loop and then ask for input? Will it boot-up, present the user with a start-screen that can let them create a new file, and then let the user do whatever? Working out the flow of your program is also important, as then you can follow one design, to solve nearly all problems.
Once you're done planning your project, you can then move onto the actual development. When you start development though, it is recommended that you create a prototype of your program - An early version of your actual program to develop, showcase, and test the bare-bones features at first. If you create a prototype that you like, you can then work off of this prototype by further building more on top of it or you can choose to restart from scratch, while inheriting some of the code that was written in the prototype. Both will work. From that point on, development will involve numerous writing of the code, testing, and of course, de-bugging.
Many struggle with de-bugging early on in their journeys, which is normal. But unfortunately, many don't take the time to actually figure out what went wrong. Instead, they spend hours trying to track down a misspelled keyword or variable, or even a missing semi-colon. Not only that, they also immediately turn to the web for help, and go to sites like StackOverflow, find their answer, and then copy and paste in the solution that supposedly works(I say "supposedly", as when a programmer steals a solution from sites like SO, it will probably conflict with all of code that was written by themselves). Now there is nothing wrong with using the web for answers(Hell, you're on one of these sites right now). But as I said, solutions may be of low-quality, conflict with the rest of the code(Which will lead to more errors), and will even stand-out from the rest of the code written by the programmer.
To de-bug, one should only use the web as a last resort. Not only that, I recommend that you abstain from taking the solutions that were only devised and delivered to the person who asked for help, not you, and abstain from copying these solutions and putting it in your own code. If you're going to de-bug, read your error messages, even if they are vague(Which is the case with pretty much all compilers and interpreters). First of all, to de-bug, look at what line it says the error is on. Go to that line. Once you're at the line, read the full line to check if anything is misspelled, missing, has a red-underline beneath it(If you're using an IDE. Older text-editors like EMACS and Vim won't have this, but programs VSCode do), check that you have supplied arguments(If the issue lies within a function being called), or check to see if you wrote something that actually relies on something else(Such as a library. For example, if you're writing an OpenGL program, you'll need to include the GL libraries to actually write the program without catching any dependency errors). There are multiple reasons for catching errors on a single line. As I said, read over it to see what went wrong. Then experiment with solutions to fix the issue. If you have a *piece of paper, notepad/notebook, or a whiteboard, use that to write down possible solutions. If one solution doesn't work, scribble or rub-out your first solution and then move onto the next. Keep on doing that until you find a solution that solves your problem. If you cannot find a solution, then look up the error-message online - Of course, abstaining from copying solutions. Simply looking up the error will grant results and so you're free to look through what solutions others have came up with, but again, abstaining from copying these solutions.
*Note that writing code on a piece of paper or a whiteboard, will actually come in really handy for when you go to an interview, and are actually working in an office with others. During an interview, you will be expected to code on a whiteboard, and explain your solution and how it will work. Not only that, using a piece of paper or whiteboard for coding, can also improve your communication-skills, and it may also improve your problem-solving a bit.
Well, that wraps it up for today's advice. If there are any other pieces of advice that you'd like, I will be happy to take them into consideration and write them at a later date.
Thank you for reading.
Over the past few weeks, I have been writing advice-pieces for newer programmers, who don't know where to start, what to do, all of that. This is the third one out of three, so far. You can read the other two, here:
- https://www.codeforum.org/threads/my-advice-to-newer-programmers.871/
- https://www.codeforum.org/threads/my-advice-to-newer-programmers-part-2.905/
Now today's topic is all about building and maintaining your project. Something that takes time to improve on. When you first start out in programming, your projects won't be perfect. They'll be small. They may be very buggy or poorly-written. They may even be very slow and take up a lot of space on your disk. But as I said, you'll improve over-time to stop these issues from happening.
When you're going to be starting a new project, you should first plan-out the project. What will it be capable of doing? How and on what platforms will it run on? What are it's dependencies(Other programs and libraries that your program will rely on to work)? You'll need to ask these questions to yourself first. Once done, you can move onto how the flow of the program will work. Will it first boot-up and instantly go into an infinite-loop and then ask for input? Will it boot-up, present the user with a start-screen that can let them create a new file, and then let the user do whatever? Working out the flow of your program is also important, as then you can follow one design, to solve nearly all problems.
Once you're done planning your project, you can then move onto the actual development. When you start development though, it is recommended that you create a prototype of your program - An early version of your actual program to develop, showcase, and test the bare-bones features at first. If you create a prototype that you like, you can then work off of this prototype by further building more on top of it or you can choose to restart from scratch, while inheriting some of the code that was written in the prototype. Both will work. From that point on, development will involve numerous writing of the code, testing, and of course, de-bugging.
Many struggle with de-bugging early on in their journeys, which is normal. But unfortunately, many don't take the time to actually figure out what went wrong. Instead, they spend hours trying to track down a misspelled keyword or variable, or even a missing semi-colon. Not only that, they also immediately turn to the web for help, and go to sites like StackOverflow, find their answer, and then copy and paste in the solution that supposedly works(I say "supposedly", as when a programmer steals a solution from sites like SO, it will probably conflict with all of code that was written by themselves). Now there is nothing wrong with using the web for answers(Hell, you're on one of these sites right now). But as I said, solutions may be of low-quality, conflict with the rest of the code(Which will lead to more errors), and will even stand-out from the rest of the code written by the programmer.
To de-bug, one should only use the web as a last resort. Not only that, I recommend that you abstain from taking the solutions that were only devised and delivered to the person who asked for help, not you, and abstain from copying these solutions and putting it in your own code. If you're going to de-bug, read your error messages, even if they are vague(Which is the case with pretty much all compilers and interpreters). First of all, to de-bug, look at what line it says the error is on. Go to that line. Once you're at the line, read the full line to check if anything is misspelled, missing, has a red-underline beneath it(If you're using an IDE. Older text-editors like EMACS and Vim won't have this, but programs VSCode do), check that you have supplied arguments(If the issue lies within a function being called), or check to see if you wrote something that actually relies on something else(Such as a library. For example, if you're writing an OpenGL program, you'll need to include the GL libraries to actually write the program without catching any dependency errors). There are multiple reasons for catching errors on a single line. As I said, read over it to see what went wrong. Then experiment with solutions to fix the issue. If you have a *piece of paper, notepad/notebook, or a whiteboard, use that to write down possible solutions. If one solution doesn't work, scribble or rub-out your first solution and then move onto the next. Keep on doing that until you find a solution that solves your problem. If you cannot find a solution, then look up the error-message online - Of course, abstaining from copying solutions. Simply looking up the error will grant results and so you're free to look through what solutions others have came up with, but again, abstaining from copying these solutions.
*Note that writing code on a piece of paper or a whiteboard, will actually come in really handy for when you go to an interview, and are actually working in an office with others. During an interview, you will be expected to code on a whiteboard, and explain your solution and how it will work. Not only that, using a piece of paper or whiteboard for coding, can also improve your communication-skills, and it may also improve your problem-solving a bit.
Well, that wraps it up for today's advice. If there are any other pieces of advice that you'd like, I will be happy to take them into consideration and write them at a later date.
Thank you for reading.
