By Thad Anderson, acting General Manager and SVP of Solutions and Services, Presidio Federal

My first job out of college was Programmer/Analyst I. An entry-level position coding RGP II on the IBM System 34/36/38 midrange line. I graduated to COBOL programming on the mainframe and eventually moved on to design and code on the “new” X86 PCs invading the workplace. Now you know how old I am. If I’m honest, I wasn’t a great programmer and that’s probably good, since in those days, the pay and prospects for career growth weren’t great either. Looking back, however, I realize the experience has shaped and influenced how I’ve managed people and business throughout my career. Here the key leadership lessons I took away from software programming.

Only change one variable at a time. This is a simple, but powerful concept and you’d be surprised how often this axiom is ignored under pressure to correct an error quickly. When you’re debugging code or troubleshooting an issue, it’s always advisable to look at multiple potential causes. You want to cast a wide net in your thought process to find the problem. As you work to identify mistakes in your code, iteratively making changes, recompiling, and testing, it’s critical to only change one portion of the code at a time to isolate the root cause. If you change more that one thing at a time, you won’t know which change affected the outcome in what manner.

It’s the same when confronted with a business issue. Your mind will immediately go to all the things you could potentially change to correct a problem or improve results and there are many. For example, you could make an organizational change or perhaps a process modification. The important thing is to only do one of these at a time so you can measure and assess the impact of that single change.

Be consistent. In software development there are rules, guidelines, and best practices, but even within that framework, there’s a wide lane to operate and be creative. In other words, there are a lot of ways to skin a cat and no two coders will do it the same way. Naming variables is one way you can express yourself in most programming languages. There may be some limitations and conventions, but for the most part, you can do what makes you happy. It doesn’t matter what naming scheme you choose, but you need to pick a system and stick with it. You’ll save yourself, and the maintenance programmers that follow, a tremendous amount of time and mental energy if you maintain uniformity over time.

Your team cannot read your mind, but they really want to. People in the organization yearn to know what’s going on or what’s next. That’s why informal communication (i.e., gossip) is so prevalent. The next best thing to ESP for your team is a degree of predictability from you. Nothing creates more angst within an organization than not knowing what they’re going to get from you as a leader from one day to the next. It’s not about always being right, it’s about consistency in your thought process and approach to challenges.

Modularize and reuse. To vastly oversimplify, modular programming allows development to be divided by splitting down a program into smaller programs to execute a variety of tasks. This enables developers to work simultaneously and minimizes development time. Similar functions are grouped in the same unit of code and separate functions are developed as separate units of code so the code can be reused by other applications.

There are two takeaways from the concept of modular programming I think pertain to good leadership. First, break a big problem down into pieces. Issues within a business can seem overwhelming at times. They can feel too large to tackle and we tend to put-off dealing with them for that reason. Procrastination will not help, but one way to get your arms around it is to divide it into parts. An entire business process may be broken, but you don’t have to fix it all at once. Analyze it one component at a time and you’ll usually find either the biggest problem, the quickest fix or both and then you can decide which you want to handle first. The second takeaway is simple; never reinvent the wheel. If you’ve got a solid piece of code that performs a function, leverage it as many times as you can. The same is true for a leader. Experience is the greatest teacher, trust what you’ve learned and reuse it.

Always add comments. In BASIC, they’re ‘REM’ statements and in COBOL, they begin with an asterisk, but whatever the method, comments within the program are crucial. You won’t appreciate them until you leave your code for a couple of days and return to try and make sense of it. As a responsible coder, you should always write meaningful comments for vague lines and tricky logic blocks. Useful comments make life easier for you and those who maintain your code after you’ve gone.

The leadership lesson here is, while documentation is never fun, it’s always your friend. More importantly, always explain the ‘why’ behind the ‘what.’ Your team doesn’t just want to be told what to do. They want and need to understand the logic behind what you’re asking of them. How does what they’re doing fit into the larger picture. They may not even realize it, but it will help them buy into the task or process and take ownership.

Be patient. Debugging can be one of the most frustrating processes when you’re programming. It can take hours to find a bug, and you can easily lose your sense of time. I once worked on a program for two solid days looking for an error in a couple thousand lines of code that was preventing it from compiling. A colleague walked into my cube, peered over my shoulder, pointed, and said, “you’re missing a comma right there.” I was grateful, but highly irritated.

Always take advantage of a fresh perspective. Learn when to step away from the problem and take a break. Doing so will allow you to clear your mind enough to go back to the issue with a renewed sense of focus.