Tips to improve your programming skills

Good practices for the programmer


The purpose of this post is to get you thinking about how to improve your programming skill set with an overarching goal of increased efficiency.

We all have room for improvement. In my experience one of the biggest pitfalls in this profession is the lack of cooperation among programmers. All too often IT professionals are overly concerned about job security to the extent of not collaborating during key projects. Other programmers are not willing to take the initiative to learn new methods and cling to false beliefs that their kludgy methods are somehow sufficient, without regarding changes to programming languages, operating systems, productivity tools, GAAP, or just the business world in general.

Here is a list of ten items that will hopefully increase your programming proficiency.


1. Share your code and your ideas with other programmers and feel free to copy existing in-house code, but always give credit where due. Programmers rarely write complete programs without borrowing some code or using a shell program (or both). If you don't have in-house companions to work with consider joining some internet forums.

2. Document your changes. Most programmers already leave some sort of trail of their changes. Usually the method involves putting a cryptic comment that might include the date, a project or service request number for tracking, and a brief explanation of the changes. Think of this comment as all-important. Linking source comments with a work management, change control, or bug tracking system is a great idea. However, you will still need to understand the comments when you unpredictably are forced to debug the same program six months later. Other programmers should be able to quickly decipher what you meant by the comment. Let's bury the old saying "if it was hard to write it should be hard to read". That's just nonsense.

3. Work by standards but be open to new, better ideas. Standards are crucial but it is important to understand that they are a moving target. There needs to be a repository for standards and, by definition, everyone must be aware and accept these standards.

4. Have a goal of improving something every day. Even if it a small improvement if practiced consistently, over time, things will improve for you and your company. Be on the lookout for areas to improve and don't let these opportunities slip by unnoticed.

5. Have a goal of learning something new every day. Set aside some time each day to research other sources of information that increase your skill set. The fact that you are reading this post means you are searching which tells me you are on the path to successful programming. Learn to do higher quality queries over the internet and you can quickly improve your knowledge base. Don't copy web code though, unless you thoroughly understand its purpose. It is more important to get the concepts down and most websites, including this one, intend to provide examples, not production ready code. Organize your favorites or bookmarks and back them up regularly or use a tool like Delicious to save your links online and share them with others.

6. Debug, test, debug, test, debug, test, and debug and test some more. Rarely does a programmer overdo when testing her or his changes. Project budget and time constraints usually don't allow for fully testing changes. Programmers should not fall into a trap where they think compiling successfully means the code is "good enough". Have some reliable power users test with the intent of breaking your changes but keep in mind the responsibility rests with the person who makes the changes. Write a detailed test plan. Programmers should not be forced to think of projects as a race or gloat or brag about how quickly they code. In my experience the shorter the amount of time spent on a program the more inferior the end product.

7. Be prepared with a rollback option. The more work a programmer does the more likely they are to experience an occasional bug or even a crash. Don't take it personally. This even happens to the best programmers and ego is not what is prescribed. Try to foresee consequences during your testing phase. You can lessen the frequency of this situation by admitting that a particular glob of code is confusing and solicit help. If the same code continues to be problematic it is probably poorly written and/or poorly designed in the first place. It can be tempting to just add a band-aid when major surgery might be required. Try to permanently fix the problem at it's source. Your manager may not like the idea but some code is so porous that it probably should be redesigned, rewritten, retested, and implemented in a controlled environment.

8. Always initialize your variables. No one likes to have field data carried over when it should not be and, no, *inlr doesn't always guarantee new values (it used to, doesn't anymore). It is the programmer's responsibility, not the operating system's, to clear out values between running programs. For variables defined by the program a simply INZ(initial value) on the D specification should suffice. For example;

d wktype          s                   like(ctype) inz('STP')

9. Take advantage of updates in the operating system and programming language. Get to know the advantages in IBM i 6.1 (which you will be tempted to call V6R1 but it's now officially known as 6.1 okay?) Get familiar with DDL as it represents the future as DDS begins to fade into history. Check my article on using DDLComparing SQL DDL with DDS.

10. Don't omit H specs. Understand them and benefit from them. Options *srcstmt and *nodebugio make debugging easier. With the correct H spec in place the programmer doesn't need to change compiler options or debug parameters.

h dftactgrp(*no) actgrp(*caller) option(*srcstmt:*nodebugio)

Hope this helps and you have a happy and safe summer!