Proactive vs Reactive

As a consultant, I have the opportunity to work with many different kinds of people in many different settings. The people I help have all different levels of experience and skill sets. There are some stumbling blocks that I see a lot of people tripping over on a regular basis. One of the most common ones in junior level developers is being reactive instead of proactive in their tasks.

Determining if someone is a reactive or proactive programmer is simple and normally takes me less than a day. After completing all their tasks, a reactive programmer waits to be assigned their next task while a proactive programmer finds their supervisor to get their next task. It is a seemingly subtle difference, but it is a difference that separates a good from a great developer.

Reactiveness manifests itself in many different forms. When a developer does not ask any questions, then submits code that is short sighted or breaks other parts of an application, they tend to be reactive. When a developer gets something to work but does not go the extra mile to make sure their code is clean and maintainable, they tend to be reactive.

Determining if someone is a reactive or proactive programmer is one of the first things I do when I meet someone. I’ve found that everything from expectations to code quality to how I explain techniques and algorithms varies greatly between a reactive and proactive developer. Proactive developers, even if they are introverted, tend to ask questions that are direct, clear, and answerable. A reactive programmer, even the extroverted ones, tend to nod their head, then ask me questions when they hit stumbling blocks.

Reactive programmers tend to be large sources of entropy in a project. They never seem to get ahead in their work, and never seem to produce as much as their proactive counterparts.

Breaking someone of their reactiveness is a tough thing to do. This, like many other deep changes, requires the developer to be committed to getting better. If they do not see their reactivity as a problem, they will never be able to break through that threshold. Getting someone to buy-in is extremely difficult, but there are a few ways to start nudging them in the right direction.

Be committed to constructive criticism in code reviews. For new developers, code reviews are rough. Really rough. It is easy to feel like someone is attacking you personally when they say your code is not as good as it should be. Before starting a code review with a reactive programmer, let them know you have their best interest at heart. Let them know the review is not personal or negative in any way.

If you manage a reactive programmer, ask them every day what they’ll be working on next. My least favorite part of managing a reactive programmer is when they would have nothing to work on and not tell me. To get them in the habit of communicating when they’re ready, I would ask them every day what they’ll be working on after the thing they’re currently working on is finished. It took a few weeks, but they finally caught on. Other improvements came once knowing their next move changed from an annoyance to a habit.

Call someone out when they make a big mistake. No one likes to make a mistake. The worst is making a mistake and knowing you let down someone you look up to. The only way to make sure you don’t feel that way again is to take ownership and make a habit of not repeating the same mistake again. After I let someone know they made the mistake, I will wait a few seconds to see their reaction. If they are apologetic and sincere, then I tell them that it’s ok and don’t let it it happen again. if they are defensive, then I know that this will probably happen again.

I strive every day to be a proactive developer. The ability to constantly think ahead is not yet natural for me, but it is something I’m committed to. The best developers I know are ones that are proactive, and I want to be the best that I can.

The post Proactive vs Reactive appeared first on Zach Gardner's Blog.