It's the holiday season, and everyone is in the gift-giving mood. Be sure you don't forget to invest in your company and career.
It is a special time of the year. Family gatherings for the holidays, football season, and time in the woods all make this one of my favorite seasons. The month of December also is unique for IT departments. December is certainly not business as usual for most of us.
It's time for budgets. That may mean requesting budget items for next year or spending surplus budget before the end of the year. It's often when project work slows down a bit as end users and IT staff take time away from the office. It's a time when stress is often at its lowest, so it's just easier to get some things done.
My holiday article last year was centered around "gifts" from our friends at IBM over the course of 2015. Of course, I could recap the additions to the IBM i world for 2016 in the same manner, but instead, I want to concentrate on the gifts that you and your company can give to yourself this holiday season. These are the things that this season is the perfect time to address.
As mentioned earlier, project work and business emergencies seem to dial back a few notches at the end of the year. This makes it the perfect time to handle some internal business. Here are some things I recommend you spend some time on in order to make next year better for you.
Share What You've Learned
If you are in a healthy development shop, your developers are constantly learning new things. The lull at the end of the year is the perfect time for team members to share some of the things they have learned with the rest of the staff. I do recommend doing this regularly throughout the year, but if you failed to do so, or just couldn't cover it all, now is the time to catch up. The most successful teams have skill overlap. You never want to have only one staff member understand a certain technology. It's just bad for business. Sharing knowledge is the best way to combat this problem.
This is also where younger staff can really shine. You do have younger staff, right? If not, we will discuss that in a minute. Young developers bring in new ideas and perspectives. Tap into that resource. You will be amazed at where it can lead you.
Review Coding Standards and Operating Procedures
Too many companies create coding standards and procedures for developers to follow and then think the work is done. The IBM i development ecosphere, like any other platform, changes. Your developers' skill sets change. At least they should be changing. The demands placed on your developers from the business change. Everything changes. Shouldn't your coding standards and procedures adapt with these changes?
The downtime at the end of the year I s the perfect time to get the development and operations staff together and discuss the shop rules. Standards and procedures are there to improve your IT operations. They are not there to hinder development or place unnecessary burden on your staff. Have an open dialogue about what is working and what is not. Allow everyone to give their opinions.
Discuss the new functionality added to IBM i over the current year. Incorporate the use of that functionality into your standards. All too often, I have developers tell me they can't use some feature of the RPG language because their coding standards don't allow it. In some cases, they are talking about features available for over a decade! Your coding standards should guide your developers. They should never limit them.
Spend some time reviewing your internal operating procedures. How long does it take to have a software change moved into production? Does it really need to require five different signoff forms and a three-week review period? Do your procedures add value to your operations, or do you do them because some consultant or auditor recommended it in the past? When a developer needs to evaluate a new tool, either on the local PC or on IBM i, how long does it take to get that approval? Is that process stifling innovation? Take the time to have real, constructive conversations about this. This shouldn't be a developers-versus-administrators showdown. Developers should come prepared to give a logical and justifiable case for changes. Operations staffers should present concrete reasons for procedures that are in place. This type of dialogue not only helps each side understand the needs of the other, it also can lead to consensus on changes that are acceptable to the entire staff.
Plan for the Future
So far, we have discussed reflecting on the past year. That is time well spent. Year end is also a time for looking ahead. It is time to set goals for the coming year. It is time to finalize budgets. It is time to solve staffing and skill problems.
Other than meeting the needs of your business, are you setting goals for your IT department? They don't have to be lofty goals or even very specific. Just make a conscious decision about the direction in which you would like your staff to grow.
Is your code base terribly out of date? Are you still developing RPG III code, even if it is RPG III-style code in RPGLE source members? Are you using ILE? Are you using DDL to define new tables? If you don't like the answers to these questions, then it is likely time to modernize your skill set. That is a goal that should be on most IBM i shops' radar. Even shops that have relatively modern skills should always be striving to learn new skills. There are different ways to approach this goal.
The obvious method is to invest in training. Whether you send staffers to conferences, pay trainers to come onsite, buy books, or just pay for online courses, companies must invest in their developers. They are an asset that should not be neglected. As for developers, you should also be investing in your career. If the company cannot or will not invest in training, you should find ways to invest in yourself. Many of the most useful skills I have added to my repertoire, I learned on my own time and my own dime.
Next, invest in tooling. Yes, developers can write applications in SEU. After an adjustment period, they can write applications more efficiently in RDi. Just like I could write my upcoming book with a pen and paper, it is much more efficient to use a word processing program on my computer. Giving developers the tools needed to do their job makes for happier and more productive developers. Tooling also refers to third-party tools to accomplish your goals. If your goal is to modernize your code base or your user interfaces, there are many different third-party solutions to assist you in reaching those goals.
Of course, tooling is not free. It's time to get out the pocketbook and invest in the staff in the literal sense. Do you have room left in this year's budget to invest in tooling? If so, do it! If not, start working it in to next year's budget.
Finally, you can augment your staff. Injecting new blood into the department can be a quick way to fill gaps in your staff's skillset. This brings us to our final topic.
Staffing for the Future
It is time to take a hard look at your staff. How many developers are due for retirement in the next five years? Do your developers seem happy? Do you have any junior or entry-level developers on your team? Do you have a development staff of one? These can be scary questions if you are not growing your staff for the future.
I have stated this in other articles, but it bears repeating. If you don't have younger or entry-level developers on staff, you are doing it wrong. You should have a junior-level developer on staff for every senior-level developer you expect to lose within five years. If you don't, you will fall into the same trap that many IBM i shops find themselves in. One of your best developers retires or moves to greener pastures, and now your company is scrambling to find a developer who already has all the skills you lost with the staffer that is departing. In most cases, the developer that can immediately fill that void either does not exist or will cost significantly more than you want to pay.
So, while preparing budgets for the upcoming year, request budget for new talent. Bring in a developer and teach that person IBM i while teaching your business. It is simple risk management. Often, that is how you can sell it to management. The cost of a junior developer is a small price to pay to mitigate the risk of the loss of a senior staffer. If you get resistance for a new developer position, push for a development intern. Find a student at a local college and pay them an hourly rate to work part-time learning IBM i. The cost of an intern is ridiculously low once you factor in the savings on benefits in addition to lower pay. I have found it easier to get approval for a new full-time position for an intern who has excelled for a couple of years when they graduate. You have a proven team member that the company has invested in and does not want to lose. Even if you don't keep that intern on staff after graduation, that is one more developer in the world with knowledge of IBM i. Isn't that a good thing for all of us?
The holiday season is certainly time for fun and fellowship both in and away from the office. It is also the best time to reinvest in the staff that makes your business successful. A small investment of time and money in the coming weeks can lead to big dividends in the coming year. Don't miss out!
I hope the time and effort spent this year to share my knowledge and opinions with you has in some way helped you this year. To all of you that have read my articles and shared your comments, I truly appreciate it. Happy Holidays to all of you, and may 2018 be prosperous to you both personally and professionally.