What can an IT director do to increase programmers’ productivity? A lot. From providing a quiet workspace and state-of-the-art equipment to establishing commenting standards, here’s how to make good programmers even better.

In my 38-year career as a corporate programmer/analyst, I have seen thousands of programmers in action and worked with hundreds of IT directors. I’ve done my programming in marble-floored, wood-paneled headquarters and in grimy factories. I’ve used state-of-the-art equipment, and I’ve used “old iron.” I’ve been given a plush, private office, but I’ve also found myself crammed into a cubicle with another programmer in a room filled with yet dozens of other programmers. I’ve even found myself stationed by the copy machine. In all of these environments, one factor never varies: The speed and quality of my output always depends on the insight of the director of the IT department.

These 38 years of corporate programming have fostered some firm ideas about the kind of office environment that really works. I have found that some shops encourage programmers’ productivity while others seem bent on sabotaging it. With this in mind, I’ve created some guidelines that every IT manager should follow in order to create an environment in which employees can do their best work. Although most of these proposals may sound like common sense, heed them carefully. A shop that is managed too lightly may cripple good programmers while letting poor programming go undetected.

Demand the Best

Good equipment is the most important productivity enhancer an IT director can employ. That means fast hardware. This dictum may seem obvious, but in most of the IT departments I’ve seen, programmers must write their code using computers that make them wait far too long. What are they waiting for? Compiles! A programmer working on a slow AS/400 might be able to get 10 compiles a day—and have to wait half an hour to see the results of the compile. But with a state-of-the-art machine, a programmer might get 100 compiles a day and wait less than two minutes to see results. Insisting on state-of-the-art equipment will greatly affect your programmers’ productivity and the company’s bottom line.

Top-of-the-line equipment has another benefit as well. In today’s marketplace—in which disaffected programmers know they’ll get two or three job offers the day they leave a company — keeping your good staff members in a constant state of frustration hardly seems like a smart move. And compilation delays are infuriating for a serious programmer doing high-level work. So what can you do? I suggest that you devote more energy to persuading top management that your staff needs equipment with a response time of (effectively) 0.0 seconds. The elapsed time of source program compile, even for large programs, should be less than two minutes after the compile is submitted. Every source program compile should become active immediately and not languish on a job queue behind any other batch job.

All you really need to know about queuing theory is this: Your mission is to eliminate, or at least greatly reduce, all queues. Fast, current computer hardware can do this and can make you look like a productivity genius in the process. Providing state-of-the-art equipment will improve the productivity and the output quality of every programmer, at every level, by fundamentally changing the way your programmers approach, write, test, implement, and maintain programs and projects.

And a word of advice: Never give a programmer some old PC pulled out of a closet. Trust me, it will cost you dearly. At one of my client companies, for instance, I was given a PC that must have come out of the “to be repaired” closet. Although the company had called me in to do complex work and was paying me more than twice as much as it paid the IT department’s top programmer, I had to work with a computer that froze several times a day and was not fixed for weeks, costing my client thousands of dollars in lost programming t i m e . T h i s k i n d o f p e n n y - p i n c h i n g i s counterproductive—and commonplace. Need another example? Some of my clients (billion-dollar enterprises) still expect their programmers to work on 14-inch monitors. But focusing on a small screen is eyestraining, to say the least. Also, when a programmer with a 14-inch screen asks me to look over his shoulder and help untangle a coding knot, my response has to be, “Sorry, I can’t read your screen.”

All Quiet on the Work Front

If you can, provide each programmer with a 10-by-12 foot office. Think an office is not vital to your programmers’ productivity? Try swapping your office for a cubicle in the programmers’ bullpen for a month, and then watch your productivity plummet while the lucky programmer’s productivity soars. Although you can’t provide everyone with a plush corner office, you can establish a quiet environment in which your staffers can concentrate. All you need to do is lay down some rules.

In most of the offices where I’ve worked, no attention is paid to the noise level. Some programmers play radios in their cubicles. Some talk on speakerphones. Some banter with cubicle mates. Some wear headphones and code to the beat of the music pouring into their ears and into mine. And the rest of the programming staff, the serious workers, lose their concentration because they can’t get away from the noise.

Programming requires fierce focus. I find office noise so distracting that I routinely use a double wad of wax earplugs. Even so, programmers who are not working as hard or as quietly as they should be sabotage my concentration. IT directors need to pay attention to this serious, but solvable, problem.

Set up your department so that the workplace of every programmer is quiet. If staffers must be jammed together in cubicles, the office ground rules must be that they cannot play radios, use speakerphones, or talk with their colleagues in that cramped space. I find it best to have only one programmer in a cubicle and only one chair per programmer. That way discussion must be held in a private office. This may be against current custom, but it is hardly Draconian. It is simply the way a programming department should be set up.

Keep Your Eyes on the Prize

Hire the right people. Even in this tight employment market, you must hold out for programmers who, in their interviews, exhibit the traditional programming virtues: perseverance, flexibility, an interest in learning new languages or applications, and, most

important, a determination to understand the company’s business functions. Never hire a programmer who thinks that his job is just to be a coder.

Devise a Training Plan

Believe it or not, few of the programmers I’ve worked with over the years have had any sort of continuing professional coaching or training. That is why it is up to you, the IT director, to develop programming standards based on your experience with good programmers and consultants you have employed.

The most important thing to do is to set goals. Give all your programmers real direction. Provide a set of programming standards and techniques, guidelines on project documentation, and guidelines on how your IT department operates. Expect the procedures you set up to be followed from day one and have a project leader review every programmer’s work.

Here are some tips to help with this training: Have a “welcome to the department” package ready for every new consultant or new employee. Newcomers shouldn’t have to ask where the printer is or what their password is, but in the programming world, they routinely have to ask these kinds of questions. (See the sidebar “They’ve Gotta Have It: What Every Newly Hired Programmer Needs.”)

On the first day, have your new employee review the production source programs written by your best programmer and tell the new hire to use these programs as models. This shows your new employees that your company has standards and you expect them to write code that is heavily commented with explanations. I always use this technique when I mentor a programmer.

Establish a universal commenting style. As the IT manager, you have the responsibility to set a departmental “commenting style” that every programmer will use when writing source code. In many shops, each programmer writes in his own idiosyncratic way. The unfortunate consequence? When a programmer goes on to other projects, the code left behind is often a mystery to the programmers who come after.

Educate your programmers on your company’s business. You should provide a comprehensive facility or plant tour and have the new programmer observe other company personnel in the various divisions, such as accounts payable, warehousing, manufacturing, and distribution. Taking your new recruit on tour is important because these departments have business applications that the programmer will have to work on. Your programmers may know how to code, but they often don’t know much about business functions. Making sure your programmers learn these business applications is one of the most important things you can do.

The techniques you come up with should be the “basic training” you give your new recruit. Back in the early sixties when I became a programmer, IBM gave every systems engineer this kind of training. It works!

Real Results Real Soon

Hire programmers at full pay for a six-month trial period and give them your formal development plan. Gradually increase the difficulty of their projects. Then have a thorough and objective performance evaluation. If your new programmer meets your objectives, hire that programmer at a salary significantly above market pay.

Require every programmer to give you a one-page project activity summary every week and schedule a five-minute meeting to review it and set goals. Ask these questions every week: How are you doing? What can you or I do to make you more productive and happy? What are your concerns, your suggestions, and your ideas? Give direction and performance feedback and prioritize projects.

Also, you should provide separate test and production environments, and set up a formal change management system to relieve the programmer from operational responsibilities. Before a new or modified program goes into production, put it into “pilot production” by letting a single user (say, a packer in a distribution center) implement it in production under the watchful eye of the programmer who wrote or modified the code. If there’s a glitch in the program, it will crash for the pilot user, not for the entire company. And if it does crash, the pilot user in the production environment can give your programmer valuable feedback.

Provide to your programmers extensive and continuing technical and business application education. Require that all of your programmers take advantage of it. Some corporations refuse to give ongoing training because they really don’t want their employees to grow. Why? Because these very employees might go out and get better jobs! This attitude is both wrongheaded and expensive. Companies today must make a programmer’s job so attractive — through salary, bonuses, and opportunities to learn new techniques — that the programmer will want to stay. Simply put, good programmers are not interested in taking jobs at firms that do not give them a chance to grow. Besides, it is futile to hope that talented programmers will not eventually leave to become consultants. The best way to get extra work out of your programmers is to foster their growth. If you do so, your programmers will enrich your company’s code while they increase their skills.

You Say Goodbye, I Say Hello

Despite your best efforts, there will inevitably come a time when you lose your best programmers. Why? Because the best will always grow out of the environments that created them. However, by acquiring the best hardware and by training new recruits intelligently, you can minimize the pain of a good programmer’s departure. Meanwhile, if you, as an IT director, are wise enough to give your people the hardware and the guidance they need to succeed, they will steadily become the best programmers they can be. And you and your company will reap the rewards of better systems, higher quality applications, increased productivity, and happy, productive users.

They’ve Gotta Have It: What Every Newly Hired Programmer Needs

1. Private 10-by-12 foot office

2. Fully furnished office with one comfortable swivel chair

3. New PC with 17-inch monitor and loaded with all necessary software that also has a password and Internet access

4. Telephone with voicemail (no speakerphone)

5. Valid QPGMR user profile and sign-on for the AS/400 test environment

6. Office manuals including IT department mission statement, orientation information, office procedures, and programming standards documents

7. Key production source programs as a model for all programming

8. Tour of IT department and company facilities

9. Programmer orientation and training plan
10. Scheduled projects, coordinated with education and training and performance reviews
11. Introductory lunch with the programming manager and senior programmer mentor