Happy New Year! I resolved to take out the garbage for pickup on January 2. Mission accomplished. Now that you have quit smoking and lost weight, it’s time to work on some real challenges for professional self-improvement.

Here are 13 Peoplesoft professional resolutions for 2013. Pick a few and get started now, or save them for your next performance review when your manager wants to set goals for the coming year. (I have done all of these over the course of my PeopleSoft career, so I’m setting my sights for the January 9 garbage pickup.)

1. Start a journal

Engineers and scientists often keep journals in which they record their ideas, experiments, and results. We can do the same in our medium of choice:

  • On paper, to simply diagramming but without easy editing
  • In a text file, to control positioning
  • In a word processing document, to use color, fonts, or other visual clues but to be bothered by spell checking of variables and Peopletools objects
  • In a spreadsheet, to have a four dimensional table structure (worksheet, rows, columns, and lines within cells using Alt-Enter) with flexibility somewhere between a text editor and a word processor

We can record our trouble shooting efforts: the symptoms, our theories, the SQL we write to investigate the data, the results we find. I like to email my notes to my coworkers (if they are working on the same problem), my manager (so he or she has something to tell our customers if they ask), and even my customers (so they understand that I am not neglecting their problems).

We can record our design ideas. Database tables don’t have metadata features for comments, and even if they did, it’s inefficient to create a table until it’s completely designed. Most PeopleTools objects can include comments, but only with a very limited text editor. Also, many of the things we want to record concern multiple objects or relationships between objects.

In a journal, we can record business requirements and policies, and the reasons for them. We can record assumptions and preferences, and the circumstances and timing that could change them.

2. Read a book

Great programmers always want to be greater. There are many sources of knowledge:

  • Experience from iterating through cycles of trial and error, and eventually solving problems. This may be the hardest source but it is most readily available, even unavoidably available. However, the learning from experience may be hard to generalize.
  • Discussion with co-workers or in online forums is also readily available and wonderfully interactive, but is often reactive. People may answer your question too narrowly, giving you the information you think you need rather than the information you really need.
  • Internet search of past discussions sometimes yields answers that used to be true, or insights into other programmers’ confused and inarticulate states of mind.
  • Books (usually) are well-organized, comprehensive, accurate studies of some subject. They teach facts and skills we might never have thought to ask about.
  • Courses are like watching a play rather than reading a script. More time and cost. Some people like them, but I’m dissatisfied that I cannot keep the instructor on my office book shelf afterwards.

Look for SQL optimization techniques, user interface design, programming techniques, software quality assurance, or algorithms. Or learn your customers’ professions: human resources, accounting, or supply chain. Or learn your boss’s profession: project management, planning, leadership, interviewing, or budgeting.

3. Visit your teammates

Every organization has a procedure for PeopleSoft users to report problems to, or make requests of, the PeopleSoft technical support team. I would never say that those procedures are unwieldy, frustrating, inefficient, and counterproductive because I try to be polite.

Don’t have users. Don’t have customers. Have teammates who use PeopleSoft. Remember we were hired – our job were created – to help them.

Visit them without an agenda. Learn how they are feeling about PeopleSoft at that moment. Learn how they use it. Learn what functions of it they gave up using, and why. Learn how PeopleSoft fits into their job.

There may be a way to help them that they never would request because they wouldn’t have thought it possible. There may be a way to enhance a report: another column; a different sort; totals or subtotals; highlighting exceptions; omitting clutter. There may be a way to improve the quality of their online work: a default value, lookup, or FieldEdit PeopleCode to assist data entry; an inquiry page to assist their research; a view they can use in PS Query

4. Join an internet discussion group

An internet discussion group, like the SQR Users Group (www.sqrug.org) or IT Toolbox (www.ittoolbox.com), will have thought provoking questions, colleagues that will try to help you when you’re stumped, and the opportunity to show off your own expertise to a global audience. It’s a good place to learn what really works, rather than the 99% (or whatever percent seems right to you) accuracy and completeness of Oracle documentation. Also, it is interactive. If an answer isn’t clear or doesn’t quite meet your needs, you can ask (politely) for elaboration.

5. Document something really well

I spent seven years at one employer writing three generations of a payroll to general ledger labor distribution system. (It wasn’t the only thing I was doing.) It was a masterpiece of accounting complexity, technical challenges met with innovative algorithms and data structures, and performance optimization (10 times faster than the simpler programs it replaced).

When I gave notice, I softened the blow with a forty page document that provided a functional design, technical design, guide to supporting database tables and PeopleSoft pages, and guide to anticipated future enhancements. My successor loves my system and loves me.

In our profession, we talk about people who made themselves indispensable with poor coding, lack of documentation, poor communication, and information hoarding. Do we admire them? Would we praise a doctor who kept us a little sick all the time to ensure return visits? Or didn’t tell our next doctor about our pre-cancerous growth? Let’s be the opposite of those people.

6. Create a subroutine library

Application Engine has the “call” action that executes a section of any Application Engine program, which means it can execute an entire program as a subroutine.

PeopleCode has functions and methods within the same PeopleCode program, in the FieldFunction of any record, or in Application Packages. PeopleCode can also call the Process Scheduler to run any batch program.

SQR has procedure calls and include files. The SQR preprocessor inserts the include files into the source code, which can make procedures available to any program.

Subroutines fit into three categories.

  • Some of them are like chapters of a book; blocks of code that belong together and make one major contribution to the completion of the task.
  • Some are task-specific functions that need to be exactly the same in multiple programs, like finding the Social Security number of an employee’s spouse.
  • Some are widely used generic tasks like formatting a person’s name (last name first, then comma, then first name, then middle initial, then suffix like Jr. or Sr., then converting to proper case – first letter upper, other letters lower, except for roman numerals in the suffix).

Begin to build a subroutine library. You may share this task with colleagues, but be careful about source control. Start with some routines for string and date manipulation. (Does everybody know the century rule for leap years? Do they all agree about February 29, 2100?) Continue with initialization routines like reading run control rows and performing load-lookups. Create a standard list of substitution (pre-processor) variables like {true} and {false}.

7. Create a SQL Views library

Give your organization’s power users their own subroutine library. If they are writing SQL in PS Query, they could use some views. Database views are like SQL subroutines. Give them views that aggregate data; that can be a challenge in PS Query. Give them views that join data from prompt tables with the main tables that have foreign keys. Give them views that separate, concatenate, combine, or transform columns. For example, hire date minus birthdate equals hire age. Sysdate minus job entry date equals tenure.

8. Start a knowledge exchange seminar

Set up a regular meeting, reserve a room, schedule it on Microsoft Outlook, or whatever your organization uses for real meetings. Invite colleagues. Everyone has different strengths. Someone in your department is the best debugger. Someone knows Component Interface best. Someone understands object oriented PeopleCode. Someone writes the trickiest, fastest SQL. Take turns making presentations.

Hearing a talk on Component Interface won’t make you an expert in it, but it’s a beginning. Learn what it can do and what problems it might have. Find out what your colleague knows. Part of the synergy of teamwork is to know what help is available when trying to solve a problem.

9. Buy better tools

It amazes and saddens me that so many excellent programmers use Notepad or a simple shareware text editor. Also, some shareware users proudly don’t pay for the efforts of their fellow programmers while collecting their own salaries for programming. Would your boss write memos in Microsoft Works or WordPad? Does your automobile mechanic secure your engine with $5 pliers from Home Depot? There are excellent programmers’ editors that improve your productivity and your code quality.

I bought SlickEdit 14 years ago with my own money. It cost $300 plus $60 per year, and I am not a sucker paying for something that is no better than what I could get for nothing. I will praise SlickEdit extensively in a future blog entry. I know people have rationalizations for loving their own editor, but let’s be honest with ourselves (another resolution). If Notepad or UltraEdit is as good as SlickEdit, then QuickBooks is as good as PeopleSoft Finance, and some brand new junior programmer is as good as us.

Another great tool is a database browser. Oracle bundles SQL-Plus with its database. I greatly prefer TOAD by Quest Software, which is now owned by Dell Inc., the PC manufacturer. TOAD originally stood for Tools for Oracle Application Developers, but now there are versions like TOAD for SQL Server and TOAD for DB2, which contradict the original acronym.

I bought TOAD 14 years ago with my own money, but its current price requires you to nag your boss, sometimes through two budget cycles, to get it. Fortunately, Quest offers a freeware version of TOAD that you can download from its website. Many features are disabled, but it’s still more powerful and easier to use than a fully functional SQL-Plus.

10. Treat consultants better

You may not be able to do this yourself, but you can advocate for it. I’ve been a consultant and I’ve been an employee of an organization that hired consultants.

Your organization pays a salary to professional IT employees. It pays by the hour for freelancers, temporary employees, contractors, and employees of contractors. It pays by the hour.

It’s not just mean to hobble hourly workers. It’s wasting money.

  • One client gave me the slowest PC in the office. Ironically, they were in the consulting business themselves. Every morning, I collected $8.33 to watch my PC take 5 minutes to boot and another $8.33 to watch PeopleTools take 5 minutes to load.
  • Another client had twenty consultants wait five days for their PCs to be installed. At the end of the week, we consultants got one PC for all of us to share.
  • When I was an employee, and we hired a consulting firm for a PeopleSoft upgrade, we had brand new PCs and telephones installed before they arrived. We had their network accounts, database logins, PeopleSoft accounts, email accounts, and voice mail accounts ready before they started.

There is often some tension between regular staff and consultants. The regulars think the consultants are very highly paid and have glamorous lives. They don’t understand that:

  • The high hourly rates are shared by the sales and administrative staffs of the consulting firm or job shop.
  • The high hourly rates cover medical insurance, vacation, and idle time between projects.
  • The consultants are often far from home and family, paying for two sets of lodging, shuttling claustrophobically from hotel to office to restaurant to hotel day after day.
  • The weekly routine may include long night-time flights, long days at work, and demands from the consultant’s company as well as from the client’s company.

It is petty when an IT department orders pizza for everybody working late, except the consultants. Or everybody takes the afternoon off with pay to see the new Spiderman movie, except the consultants. Management recognizes that investing in good morale pays off in loyalty, dedication, and productivity. Sometimes, the boss thinks “my staff is jealous of the highly paid contractors, I need to do something special just for employees.” What is the opposite of “team building?”

There is always a time near the end of a project where heroic efforts are needed from the entire workforce. That’s when the consultants, who were second class citizens before, rise above the slights and display their professionalism. Don’t wait until afterwards to be grateful.

11. Rewrite an old program

Pick an old, important program that has been patched and reconfigured over and over through the years. If it’s reached the point where it can’t meet the users’ latest needs, all the better. Rewrite it from scratch. Take your time; this is a resolution for all of 2013. Talk to the stakeholders: What don’t they need anymore? What should be preserved? What don’t they like? What would they miss? What new features do they need?

This may be the hardest resolution to pursue. People will challenge it, first objecting that they have other things they prefer you to do, then that they want to form a task force to spend three months choosing what to rewrite, finally that they want weekly status reports and strict milestones. Do this in your spare time; it will be more satisfying than surfing the web. Be low key; don’t get harnessed with bureaucratic overhead or turf jealousies. Good luck.

One warning: it’s best to pick a program for which you are responsible or has no obvious technical “owner.” I’ve made the mistake of rewriting a colleague’s program when they thought I was just going to patch it. That hurt their feelings.

12. Analyze batch performance and pick one to improve

The PeopleSoft process scheduler maintains a table of all the SQR and Application Engine programs it runs. Study that table and learn:

  • How often each program runs
  • How long each program takes
  • What is the total time per month or per year spent on each program
  • What programs are getting slower

A slow program can deform a business process. One of my clients’ payroll department got employee requests for information that took 30 minutes to research on the computer. They couldn’t answer the employees immediately and had to do the work when they weren’t otherwise busy.

I developed a program that could investigate a list of employees, but it took an hour. The payroll staff scheduled it to run each day during their lunch break. Finally, I invented a new way to query hash-coded tables, and the query ran for one employee in a minute. The payroll staff could generate the report while the employee waited.

What processes “must” be run overnight? That may not be viable in the long term. What if the tables grow and the processes start to take longer? Does somebody need the results first thing in the morning? What if the processes fail? Do you want to fix them at 2:00 AM? Is there enough time to run them twice?

13. Challenge your organization

It is a virtue to be customer-centric and team-oriented. It is a virtue to meet or exceed goals. It is sometimes a virtue to object and argue. The difference between greatness and failure is to know when to object and argue.

At one client, I had a reputation for performance tuning after I sped up an SQR program by a factor of 700. Initially, it took two years to produce an annual report and I rewrote it to finish in one day.

My client asked me to help with a report that audited the payroll. I studied it for an hour. It summed each employee’s earning code amounts, deduction code amounts, tax amounts, and net pay amounts for a calendar year. It compared those totals to the earnings, deductions, tax, and check YTD (year to date) tables.

I told my client:

“This program is checking whether PeopleSoft’s pay confirmation program accurately calculates year to date totals. Thousands of organizations have been using that program for up to ten years. It is probably debugged by now. In fact, any audit program we write would probably be buggier than the delivered pay confirmation program; we would be using PeopleSoft’s program to debug ours.”

The client held a meeting and abandoned their audit program.

The moral of the story is clear. It is better to reduce run time by 100% than by 95% if the program isn’t really needed. Speak up when functional experts try to impose a suboptimal technical solution – they’re trying to help, but you can help them more. Speak up when a process has become inefficient, obsolete, or redundant.