Becoming a better programmer

ONCE regarded as an arcane science familiar to only a few well-trained intellectuals, writing a computer program is no longer as daunting a task as it used to be.

With abundant resources in the form of books, website and courses, programming is fast becoming a cinch.

However, good programmers are hard to come by. Anyone can learn the semantics of a programming language and churn out lines of fanciful code, but much lack the foresight, diligence and initiative required to build a program that is practical, dependable and robust – yet easy to maintain.

It takes years of experience and hard work to become a competent programmer. If you are fairly new to programming, here are a few pointers and guidelines that should help you advance, if not excelling, in the field.
Many programmers shrug off commenting on their code as being a waste of time. A few lines of comment to describe your code takes a mere fraction of your time, but goes a long way in helping jog your memory when you revisit that piece of code months or years later.

Commenting on your code is especially vital if you are working in a team if your teammates need to understand your code, comments save them the hassle of interpreting the syntax of your code.

Every time you stumble upon a complex problem, you will need to spend significant time and effort in extensive research and writing experimental code to produce a solution.

In the long run, the possibility of encountering a problem of a similar nature is quite high. Unless you have a reasonably fantastic memory, changes are you would have forgotten the solution by them.

To save yourself invaluable time spent on construction the solution again, you should build your own database or catalogue of bugs and their respective solution. Every time you need to fix an identical buy, all you have to do is to look for the code in your database and reuse it.

Keeping track of your bugs and errors can also be used as a troubleshooting guide. Should any of your programs fail, you can also be used as a troubleshooting guide. Should any of your programs fail, you can do a quick search on your bug’s database to find a similar problem fail, you can do a quick search on your bug’s database to find a similar problem and modify its solution to caret to the current solution, again saving you precious time and effort.

Errors are part and parcel of a program. No matter how robust your program is, there is always a chance of errors occurring beyond your control, like invalid data entry from the user or a broken connection to an integrated component.

Thought should be given to the handling of unrecoverable system critical errors. A good practice is to never display the original message that was returned by the error. Sensitive information like a database name and SQL queries displayed in error messages provide malicious users with useful information that can be manipulated to hack your system.

Even if security is not a cause for concern, a more descriptive message in layman’s term is more meaningful to a non-technical user. Besides giving a more professional impression of your work, doing so also provides them with a clearer indication of what went wrong.

Not all errors need to terminate the flow of your program. Certain errors like improper user input can be handled graciously with an informative message to advise the user on what user-input the system is expecting.

Intensive and structured testing should be an integral part of all programming exercises. Not only does testing help reveal flaws and bugs in the program, it also provides an indication of how well received the program will be.

The best testers for your program are the potential users of the program, not the programmer. At best, testing your own programs will not determine whether the program works if you do everything your way. When others test your program, it reveals what can go wrong when different people try different things on your program.

A program that work wonders in the programmer’s eyes may not be practical to the user. Most programmers overlook ease-of-use and accessibility as they toil to build operational functionalities.

A program that can perform phenomenal tasks is ineffective if the users do not find it convenient enough to be used on a regular basis.

The testing exercise is the user’s preview of what to expect. It provides them with an opportunity to comment on the areas where the program falls short of their expectations. The testing process is the best ground to gather feedback from potential users on ways to improve the user experience.

There is no shame in asking for help from your peers. There are simply too many things to learn in the field of programming, even in only one language.
Even if you are proficient in the language, there are numerous concepts and workarounds to achieve different objectives that can only be learnt through experience.
Programmers are a helpful lot. Most of them are very eager to share their knowledge. Many enthusiastic programmers savour a good challenge. Pose them a fairly though problem and they will be very keen to explore different solutions with you.

Other good sources of information are online newsgroups or forums. The number of fresh ideas to be tapped from this pool of nameless gurus is overwhelming.
Seminars and talks are also very helpful in keeping you updated on the latest developments in the programming industry. Tips and pointers from knowledgeable speakers can provide you with guidelines and best practices to advance you own programming skills.

With so many programmers competing for a piece of the pie in today’s IT industry, it is even more crucial to distinguish yourself as the cream of the crop.

A programmer delivers a program that works.
A good programmer delivers a program that works and is popularly used.
A great programmer delivers a program that is the foundation of more superior programs to come – a program that performs, is widely used and can be effortlessly enhanced and maintained.