It's that time of the year again for us to resolve how this year will be different from last. So what should be at the top of the list for the modern IBM i professional?

OK, I know that traditionally we make our New Year's resolutions at the end of December so that we can jump right on them in the new year, so these are a bit belated. But that's OK because by now you've abandoned your resolutions to lose weight, get in shape, stop chewing smokeless tobacco, and a dozen other things that you pledged to three weeks ago.

Now it's time for some professionally oriented resolutions—a list of things that you should, and can, do over the next year. They're not things that you have to or even can do all at once, but if taken one at a time in slow careful bites, they're things you can seriously accomplish in the next 12 months.

Start Using /Free

This is an easy one—and one that you should already be doing. If not, now is the time to start.

I know you have a lot of positional code out there, probably gobs and gobs of it, but that doesn't mean you have to perpetuate it. There's nothing wrong with doing modifications and enhancements in /Free. We worry so much about screens looking modern. We should be just as concerned about replacing code that looks like something out of an Assembler handbook.

In many shops, management dismisses /Free, saying, "Not everyone knows it." That's sort of like saying no one should stop for red traffic lights because some people don't do it. If everyone doesn't know it, then everyone should learn it. This should be a departmental priority for every IT group—2016, the year everyone learned and began using /Free exclusively.

Pick up Jim Martin's book, invest a little time, and do it.

Embrace ILE

Here's another one—a technology that has been around for almost 20 years that's still not being embraced the way it should be.

And what am I talking about here? To start with, subprocedures instead of subroutines, prototyped calls, and service programs.

You can easily incorporate subprocedures into existing programs instead of subroutines. And you should definitely start to think about service programs and how you want to work them into your little bag of tricks. By the end of the year, you should have a strategy in place and have at least one service program doing some of your heavy lifting.

Learn it, live it, love it. My suggestion is Rafael Victoria-Pereira's new book, Evolving Your RPG Coding. Check out the RPG ILE sections (you can read the rest of it too; there's no law against it).

Learn a New i Skill

Every person's situation is different. Maybe you're learning tons of new stuff all the time. Maybe you just do pretty much the same thing over and over again. If you're in the latter group, set a goal of learning one new i skill over the coming year.

It doesn't have to be huge; it just has to be something that keeps you going in the i world.

Maybe you use a little SQL but don't do more-complex things, like various types of joins or fetch thingies.

Or maybe you use SQL but have never used the new SQL-based IBM i Services that Scott Forstie's group has developed.

Or maybe you'd like to learn how to use POI to create your own Excel-type outputs.

I admit this one could be optional. If you teach yourself /Free and ILE, then I guess this one is covered, but if you already know that stuff, then this resolution is fair game.

Learn a Web Skill

This one you can do regardless of anything above.

I know they say it causes hives and makes one liable to a serious case of the heebie jeebies, and that's probably correct, but you can't ignore the web anymore.

Besides, it makes you look cool, and no matter how old we RPGers get, looking cool is still important.

What should you start with? Well, if you're completely new to the web, you probably want to dig into HTML. HTML5 specifically. Nothing else is worth bothering with unless you're going to transition over to being a web designer who has to deal with older HTML versions. I like the introductory courses on Code School; it's video instruction with exercises that are completely self-contained. Another good option is Shay Howe's series on HTML (and CSS).

And, if you know HTML already, get into CSS3. Again, Code School has some excellent courses, but you can also just google "CSS3 tutorials" and get a ton of references.

If you're familiar with those basic client languages, then you might want to take your first steps into PHP or Ruby. Or you might want to go the JavaScript route. What's the difference? JavaScript is a client-side language, and it's used to change your web pages from being static to dynamic. That may sound dumb, but adding even a little bit of dynamic content to your business web portals goes a long way to making them seem more professional and modern. PHP and Ruby are server-side languages that also add dynamic elements to the web page by allowing you to access and display information held in a database.

There are tons of options out there; what's important is to get started. Don't fear the dark side. Embrace it, for you do not yet know its power.

Code Modular

Number one on the list, over and above everyone else, is to make this the year that you start to code modular. Of all the things you can do to modernize your systems, refactoring some existing code into a modular format is without a doubt the most important.

Yes, people look at screens when they consider whether a system is modern, but frankly a lot of i users don't see green-screens as the main problem, and many even appreciate the speed and simplicity of the green-screen versus the web.

And techies look at the database as one way of determining a system's age. Is the database DDL-based SQL? If not, then it's not modern. And I don't dispute that too much. Yes, SQL is technically superior to DDS-based files, but for many functions the difference is more academic than real.

What's critical is that when management makes a decision that your system is outdated, it does so based on how long it takes to add an enhancement, on the number of bugs or problems that are introduced in the process, and the fact that they feel like they're being held prisoner by older programmers who are likely to die or retire at any moment. Strangely enough, this fear they feel isn't great enough to cause them to pay those programmers more or give them the one thing they have always wanted (La-Z-Boy chairs in the conference room), but that's another issue for another day.

Most of us think of modularization as something that we can do only on new systems, where we're starting from scratch. But what we really need to do is pick a system that currently exists in a BOP (Big Ol' Program) state and then refactor that down into modules, hopefully starting you down the service program road.

Yes, you'll need management approval, and yes, it'll require some work, and yes, there's some risk, but I think modularization will very quickly show that your existing applications can be refactored, just as is done with web software, to make your code more efficient and easier to modify in the future. And frankly, if you can't convince management to do this, then the writing is on the wall. They're going to bring in some other language and package eventually.

Good Luck

New Year's Resolutions are almost impossible to keep, maybe because often they really aren't that important to us. But this is one set of resolutions that you should seriously try to keep alive.