When building an application, and specially when building FIRST application, most beginners make a lot of mistakes, primarily due to two reasons: lack of experience and carelessness towards any established standards and conduits, based on the “I don’t care how, but it works!” impulse. This, if combined with no guidance from some more experienced mentor, can develop a lot of bad habits in the career of the future programmer, that are very hard to uproot and correct, and most of the times lead to the horrible code you see all over the internet. I won’t give names, but there are whole countries where this has sadly become a phenomenon, and the software engineering world is suffering terribly because of this plague that roams more and more the ranks of new programmer generations.
Because the industry got us all used to releasing software faster and faster, with shorter and shorter deadlines to keep in front of competition and to bring more revenue, the novice programmers believe that the primary goal of building a program is to see it finished as soon as possible, and this urge is nevertheless reinforced by the anxiousness of finally putting together months or even years of theoretical study into a thing that finally does something.
It is bad when programmers write bad code because they don’t know any better. It’s even worse when they know that and they don’t care. It should be a very alarming topic for you if you find yourself doing any of these things:
- thinking that efficiency and performance are unimportant, because computers are super fast nowadays, and they can deal with poorly efficient code. Thinking that the primary target is to see it working, regardless of how it works.
- thinking that you’ll fix things later. Not only you’ll soon get tangled into things that semi-work, but the more you advance, the more interconnected the spaghetti code becomes, and the harder to fix stuff without breaking many other pieces of the code, or having to re-write parts of code.
- not taking the time to plan things up. Your goal is to code directly the next Warcraft game, you have no idea what the required steps are, but you jump straight into codes, believing that you’ll figure things up as you go.
- taking too big of a challenge projects. You know you don’t have the theoretical skills to code such things, but you’re sure you’ll read some minimum articles when required, and even worse, use codes that you have no idea what they are and how they work, yet you keep thinking you’ll learn by picking here and there, in time.
- becoming a copy – paste script kiddie. In most cases, you are worse than those in the above section. You know nothing about programming, you don’t care at all about learning theoretical stuff, all you care about is code that works, to impress your class mates. You are expert in copying and pasting code found on Google, ultimately resulting in spread pieces of code poorly glued together in some form of patch over patch monstrosity that somehow manages to perform a task.
- believing comments are a waste of time and space. The kind of programmer that remembers anything and doesn’t need stupid reminders all over the code. What importance does it make if no one else understands the code or wastes hours and hours to decipher something that would have taken 15 minutes of reading comments? Later on bangs his/her own head against the walls, when few months pass and he/she realizes that he/she forgot what the code suppose to mean or perform.
- insisting on one-line solutions. The exact opposite of programmers in first paragraph. You believe performance is the only important thing, and you try to squeeze 30 lines of code in a single, unreadable (albeit, efficient) line. You also name your variables x and y, because you don’t need stupid long, descriptive names, that eat up space.
- completely ignoring design. After all, you’re a programmer, not a graphic designer. You throw buttons in your window with a catapult, and they remain where they land for the rest of their natural lives.
- hiding the mess under the rug. You don’t really care about errors and exceptions, and you never log anything that your program does.
- re-inventing the wheel over and over again. Just as only copying and pasting code from Google, avoiding Google altogether is a very bad idea. Don’t struggle for days trying to do something that has already been done, and much better, most likely. More brains are almost every time better than a single brain.
- being too arrogant to learn new things or admit you are wrong. Your code is the best in the world and everyone else is wrong.
- not asking for help when you get stuck. There is a reason why the internet swarms with programming related forums where people ask for help.
- always asking for help, even when you’re not stuck. You don’t afford to waste your precious time googling, so why not ask others to write the code for you?
- you never indent or format your code, or you use annoying, weird formatting that no one else uses.
- your programs are a huge single function. Your program starts and ends in the Main() method, and you’ve never heard of code modularization.
- your code is the shuttered remains of a nuclear explosion. You split your codes into infinite, tiny pieces.
- hardcoding stuff in the code. You never think of portability or versatility, and you never care about flexible code.
I know that it sounds ridiculous, but the right way of coding may seem like a bad joke, at first. Many programmers read the “rules” for writing good codes, and they laugh, thinking, “what a waste of time!”, without even realizing the joke is on them. Sadly, they realize it with experience, in years of countless wasted hours and days, which could have been saved, had they not laughed and tried these tips.
So, what makes up building an application the right way? First and foremost, reading the damn theory! Don’t jump into making artificial neural networks when you just finished your “Hello World!” program. Take your time to read the topics required to learn the fundamental principles of programming. Struggle to write apparently stupid, small programs, written for each lesson. They are there for a reason, to make you familiar with the concepts explained, to make you accustomed to writing codes, to give you a starting experience in coding. It is known fact that reading alone is not enough to become a programmer, just as practice alone is not enough without theory. Don’t take shortcuts, don’t jump over chapters that look “uninteresting” at first sight. I already said it many times: there is no miraculous solution, there is no “learn programming in 30 days” magic trick. It takes months or years of really hard struggle to master the really fundamental parts of this job. There is a reason why it is called software ENGINEERING. Otherwise, everyone would be a programmer.
When you are confident about the fundamental core principles of programming, then and only then you can start thinking about writing your first serious, complex, features rich program. And the next step is PLANING! Don’t jump straight on the keyboard, writing as much code as possible in the very first day. Don’t be the one that thinks features and problems can be added or corrected on the fly. Take a pencil and paper and really start thinking about what you want to do. What main features should your program have? How should they work? What would be the best solution for implementing them? What errors could be encountered? How can you improve security? What modules of code should it have? How are they connected and how do they interact with each other? What and how you need to do in order to make your code flexible, easy to be maintained, extended, improved, reusable? What data structures will be best suited for our needs? What is your GUI’s going to look like? Remember, humans are mostly visual creatures! Your application will greatly suffer if it has a bad visual style, even if it performs outstanding. How many great performing games, but with terrible graphics have you played..? So, think! What is the visual style of your program? How should your graphical user interface take into account responsiveness (re-sizing and re-arranging the user interface components on different screen sizes and resolutions, to take advantage of the available screen space in best possible way)? What is the application’s UI flow? How different places of your UI interact and how is the user going to use your UI from start to end? Think of all possible scenarios – if, for instance, your application requires your users to login, what happens if the user forgets his or her password? How are users creating new accounts? What happens when they successfuly login? And so on.
If your program uses a database, what kind of data do you need to store? What distinct categories your data can be grouped in? How are these categories interacting with each other? Design an ERM (Entity-Relationship Model) diagram to map out the data relationship.
At the same time, don’t over-complicate things. Don’t go into really minute details. Don’t add features that you don’t really need. Take a look at your plans after you write them down. Is it a huge list? Do you have features that are not that critical to the core functionality? Do you really need Facebook login for your program? Does it really need to upload the data to a cloud based service? No application is ever complete. There will always be new features to be added, removed, replaced, repaired, etc. Start by designing the really important, core functionality alone. Additional features will come in the future, when the main functionality is done. If you really want to plan these things too, make a separate list of “to do” features that might be added in the future, when everything else is done.
Sadly, most junior and medium level programmers skip these steps altogether. Even more sadly, few universities bother to teach these steps. Yet, I cannot stress enough how important is to have a well structured plan, when you spend few hours planning ahead, and have the confident feeling of knowing what and how you want to do for the rest of your development work.
When planning your application, don’t plan an all-in-one kind of program. Don’t go there, even if the feeling of doing this is strong! It is version 1 of your program, after all. The point is to have fun while learning new things, not building the next Facebook from scratch.
The next stage after the planning is done should be….? Coding? No! Wrong again! I know you’ve becoming impatient, but this step is just as important as planning. Do some research! Google around until you break your fingers in the keyboard! See if someone else has already done stuff that you are about to code. Try to read and understand that code, document what problems and bugs have their developers encountered, and how they solved them. Compare multiple sources, try to make a list of pro’s and con’s for each solution, ask for advice. Don’t confuse this stage with making a list of web links from where you can copy-paste pieces of code for your program! True, I did say that re-inventing wheels is not a good thing to do in programming, and you shouldn’t write codes that have already been written by others (and probably better), but this is only the case for rather advanced or at least comfortable programming users. If you don’t understand what the code you are copying does, you shouldn’t be using it in the first place. Yes, the goal of making stuff work is important, but just as important is the goal of learning something from the experience, to gain knowledge and practical experience. If you need some code that reads and writes to a text file, but you have no idea how that is done, maybe it would be a better idea to research and document yourself and build your own module that does just that, even if there are tons of already available solutions on the web. You might lose some hours, but you will gain knowledge and experience that will develop your programming side of the brain, not to mention that you will probably be prepared the next time you will need this kind of functionality again. Most importantly, you’ll develop your googling skills, the ability to quickly filter and find things specifically related to your future problems.
Finally, the time to start coding!
The most surprising part to new users at this stage is that they will notice the easiness in writing code. It almost comes naturally, even if they never coded such an application. True, there are still things that you can’t possibly know or anticipate, but the goal of the previous steps has been achieved: the programmer knows what he/she is doing, and doing the right way. Still, at this stage, there are few things to be careful about:
- don’t start building multiple modules of your application at the same time. If your application has a login interface displayed first, code the login functionality until it is done. Don’t jump to the main window displayed after login or the window that lets users customize options! This will not only make you stay focused on a single task at a time, but it will also help you design modular code that is self-sufficient, loosely coupled to other sections, and easily inter-changeable. Code your program one function at a time.
- use tons of unit tests. Try to break your own program in any imaginably way. Believe me, there is a never ending ability of your program’s users to find new and more clever ways of breaking the functionality. Try to test and anticipate any outcome. Experienced programmers call this Test-Driven Development (TDD).
- use Git! I know I haven’t taught you about versioning and source control, but there is nothing worse than working days and weeks at your program and lose it because you accidentally deleted the folder, the project file got corrupt, or Windows crashed. If you don’t know what Git is and you don’t have the time to learn it (although, I strongly urge you to do so, there are tons of YouTube tutorials about it), at least make constant archive backups of your program, so you can revert to them in case something catastrophic happens. I learned this the hard way, losing A LOT of work before, and trust me, you don’t want to experience the feeling!
- when you get stuck, don’t jump directly on forums, asking for help. Try different ways of doing the task. Google about the subject. When you go on a forum to ask for help, you should be ready to show the work that you have tried for yourself. There is nothing that programmers despise more than laziness and lack of desire to solve your own problems. If you do, don’t feel offended if they will start mocking you and bluntly tell you that they are not homework writing machines.
- Finally, even when you get stuck or you have errors, or the program is not working the way you want, don’t get discouraged! Don’t get frustrated, ready to throw the computer off the window. Perhaps it is a good idea and step away from the computer. Maybe it would be better to have a good night sleep and leave the problem on the next day, when your brain is rested.
In the next lesson, we will start with the first phase of writing our first complex program, the planning. Stay tuned!
Tags: best programming practices, worst programming practices, writing first program
