Sure, you're good. But you could be better.

1. Understand the requirements. Users and business decision-makers don't talk (or think) the same way that programmers do. Before you start a new programming project, make sure you have defined, in a quantitative way, the hallmarks of success for the project—as determined by the users and decision-makers. What you're after here are solid metrics that can later be used to show that the program does what the users want it to do and provide the proof that the project is complete. In enterprise environments, they call these hallmarks a "statement of work." I'm not suggesting that for your internal, in-house work you craft a highly formal statement of work, but do get things written down and formally agreed upon. This saves a lot of downstream grief!

2. Review frequently. Back in the old days, we used to collect user requirements, disappear into a dark tunnel, and emerge when the program was done. We've since learned that this practice leads to incorrect or incomplete deliverables and unhappy users. At the very least, have regularly scheduled (short!) meetings where you show your progress and make sure that everything is on track. These meetings prove to all that you are on the right track—or, if you aren't, provide the chance to correct things before you've spent many weeks continuing to do the wrong thing. These meetings are also your chance to update delivery schedules and reset expectations. This transparency keeps everyone updated and happy. If your project is large enough, consider not only reviewing frequently, but also delivering frequently. The earlier you can get fingers pounding data into your app, the earlier you can get truly meaningful feedback.

3. Keep it truly simple. Writing code is easy. Reading code is hard. Think very carefully about your algorithms, your abstractions, your program composition, and even your naming conventions. The simpler you keep things, especially early in the project, the easier it's going to be to maintain and enhance later. In the effort to keep things simple, don't make the mistake of thinking that using tons of comments to explain obtuse code makes that code easy to understand. Tons of comments are a clear indication that the code isn't simple enough! Maybe your naming conventions aren't working; maybe you haven't decomposed the problem appropriately, or maybe your approach is just wrong! Don't try to comment your way to simplicity—rewrite and refactor convoluted code!

4. Code consistently. I think a strong argument can be made that while any one business needs many programs, perhaps hundreds or even thousands of them, that business only needs a fraction of that number in types of programs. Don't break new ground with every program you write. Categorize the types of programs you write and keep programs within any one category very consistent. Use the same routine and field naming—don't make the next coder need to start all over again each time he or she needs to read your code. Consistent naming and a similar approach to solving each type of problem substantially reduces the energy required to understand the program. The CL naming scheme of i5/OS (nee OS/400) is a superb example of great consistently. With about 80 verbs, IBM covers pretty much all the action any one programming task needs to do (and I'd bet you that of those 80 or so commands, 25% of them covers most tasks). Once you learn the CL naming scheme, you have to go out of your way to not be able to guess what a given command is doing. Don't reinvent verbs, nouns, and other naming conventions. Give something a name once and reuse it again and again!

5. Learn a new language. I recently acquired a hand-me-down Mac PowerBook Pro. It has rapidly become my latest hobby programming passion. I am learning PHP and UNIX—which is a pretty strange land for a long-time user of statically compiled Windows or IBM i-based languages. Over the years, I've learned, and used, many languages. Each time I learn a new language, the use of my core languages improved. Virtually every language has at least one core little piece (and sometimes major chunks!) that provides a new and better way to do something. Applying those new concepts and approaches in my everyday languages has made me a better programmer.

6. Get a second opinion. Did you ever write a chunk of code that you thought was the most amazing, greatest code ever? Then have other programmers glance at it and wince? And, even worse than that, when you look at the code through their eyes, you instantly see exactly what they are wincing at? That beautiful code just became, without changing a line, what-was-I-thinking code! In the old days, it was hard for one-person shops to share code. With today's social Internet, you can put your code in a blog entry or post it to a centralized code repository (https://github.com or https://bitbucket.org, for example) and ask others for critiques. The Internet has plenty of coders willing to do that!

7. Improve your fingertips. Having spent tons of classroom time with lots of students for the last 14 years or so, one of my general observations is that many programmers aren't as good at typing as they should be. I have had a surprising number of two-fingered hunt-and-peckers in my classes. If your typing skills aren't very good, there are tons of online typing tutor sites available (http://play.typeracer.com/ is especially addictive). Along with improving your typing skills, learn all that you can about your editor—and learn how to use it without a mouse! For many of us, that means learning the editor in Visual Studio. Take the time to learn its keyboard shortcuts and some of its easy-to-miss features. I've read about coding teams who have mouse-free Fridays. Everyone puts their mouse away all day on Friday—for the expressed purpose of learning how to navigate their tools with just their fingertips. I don't know that I could go mouseless for an entire day, but I often do make a conscious effort to minimize my mouse use. I'll get arguments here, but for my money, better typists make better programmers!

Roger Pence is ASNA's Product Evangelist. Roger has been in the IBM i midrange community for so long that Elvis was alive when he started. He has been with ASNA since 2000. Prior to joining ASNA, Roger was a technical editor for NEWS/400 and the author of the 400/Group's AS/400 and Windows newsletter.

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails