By Paul Spencer

As I looked over some changes that one of the better programmers on our team had submitted, I wondered what had gone wrong. The code was not up to his normal standards. There were blatant inefficiencies and basic errors; it seemed he had not thought things through as well as he normally does.

The next morning I asked him about it. "What was going on yesterday? Are you feeling okay?”

He looked at me hesitantly. "Why?" he asked.

“Well," I said, "the code you submitted last night wasn't up to your usual. It looked like you weren't thinking very clearly,” and I went on to give him my impression of what I had seen.

Eventually, it came out. "I wasn't in my usual state of mind yesterday. I was just kinda bored.”

The problems in his code were typical of someone struggling with boredom, but also from fear or limited thinking. These three obstacles are common among programmers. In over 20 years in software development I have learned to recognize their causes, and have identified a few ways to mitigate them.

Boredom

Programmers enjoy challenges and puzzles to solve; it’s what draws them to programming in the first place. As a project moves closer to production the challenges become more tedious and mundane. It is then that interest wanes and boredom can set in.

One way to deal with boredom is to redefine challenges. Early in a developer’s career, the main challenge may be to learn basic programming skills, and then maybe to begin to build some interesting components for an application. After the interesting components are built, it’s easy to get caught in the trap of thinking all the fun work is over. Instead, a developer should define the next challenge: working out how to build and ship a product. After all, a top-tier programmer must have what it takes to get the product out, and navigating the path from beginner to expert can itself be thought of as a challenge. Companies can sometimes incentivize their programmers to follow this path by rewarding them for the products they have shipped, not just their technical prowess.

Fear

A programmer might not think clearly if he or she is experiencing anxiety. Anxiety can be caused by many aspects of life including working on a doomed project (fear of failure), working for a doomed company (fear of the unknown), or just simply not fully understanding a technology thoroughly. The various pressures and conflicts people experience outside of work can cause lingering anxiety too.

A great way to mitigate anxiety is by journalling. When you write out your fears they can lose their sting and be looked at head-on. This provides confidence that makes it easier to see the steps necessary for success. As you think through the problems you are anxious about, you can put together a plan for saving your project, moving to another project, changing jobs, learning a new skill, debugging the program, etc. This plan will bring you a new focus and allow you to work with renewed energy.

Limited Thinking

A fellow I worked with many years ago did not have much experience developing software. He could pick up small coding tasks, but not do anything of significance. As he changed pieces of a program, it always seemed that he broke code in other places. Also, he would get a piece of code to work with only one path through the system, and call it complete. Upon review of his work, I kept finding holes in his code. Eventually, due to pressures of getting the product out the door, he was given small out-of-the-way coding assignments and testing tasks. Even his testing wasn't as thorough as it should have been.

He might have overcome his shortcomings but was missing one thing: Systems Thinking.

When you consider how all the parts relate to the whole, you can evaluate each change to the system in terms of the whole. A typical scenario may be when there is a bug in the system. The clues are there, but you can't seem to figure out what is going on. Without systems thinking, the clues may not be telling you what you need to hear. To one person, a clue points directly to the problem; to another person, the same clue communicates nothing at all.

Some programmers tend to jump to conclusions about a bug by trying to diagnose the problem too soon. Generally, their conclusion is not right, and they feel stuck. So they jump to another conclusion. A better way to troubleshoot is to consider the path a piece of information takes through a system, and then try to work backward from the end one step at a time to identify where the error is occurring. This requires you to make sure you know all the steps and the relationship between the steps. In so doing, you will think about the whole system.

When you think about the whole system as it is debugged, you will examine each fact, and will not throw out any fact that can't be explained with confidence. You might add failing tests and debug messages, or chase through the code with a debugger, until the insignificant facts become more interesting. Each new fact points you in the right direction until you can determine the source of the bug. When the bug is identified, you can fix it with confidence because the whole system has been examined and each step verified along the way.

* * *

No matter what the obstacle, we have to remember that we have what it takes to do our job. That’s why we have our jobs in the first place. The same was true of my teammate; he just needed a reminder, as we all do from time to time. A consistent way to remind ourselves of our capabilities is to just get started on what we need to do. The first task of a list of tasks has a first step, and we simply have to begin by taking it. When we do, we find it is not actually impossible, and we can proceed to the next one.

At the end of our conversation, I said to my disenchanted teammate, "Try to focus on getting these stories knocked out, and then we can move on to the fun stuff again and you won't be so bored. Ok?”

---