Improving Performance through Self-Reflection

Software developers like improvements. Uptime, low request duration, automation, and optimization are standard in programming vernacular. However, when it comes to improving programmer performance, many of us fail to grab the low-hanging fruit. We have the opportunity to improve our performance significantly, regardless of background or skill level, without touching a keyboard. How? Through intentional self-reflection.

John Dewey, a famous psychologist and educational reformer, said, "We do not learn from experience. . .we learn from reflecting on experience." Contemporary research confirms this. One Harvard Business Review article cites findings demonstrating that "employees who spent 15 minutes at the end of the day reflecting about lessons learned performed 23% better after ten days than those who did not reflect." So why don't more developers make time for self-reflection in practice, and how can we build that habit?

Two often-cited reasons for neglecting deliberate self-reflection include time constraints and not knowing where to begin. Fortunately, encouraging self-reflection regularly can develop recognition of its value and the desire to build a routine to foster productive self-improvement.

So, where to begin?

In Enabling Good Habits in Software Developers through Reflective Goal Setting, research out of the University of Zurich identifies five stages of the reflective goal-setting process:

1. Increasing self-awareness through reflection
2. Selecting suitable growth goals
3. Visualizing future growth goal behavior and techniques
4. Identifying tools and techniques to apply to the goal
5. Putting growth goals into practice with ongoing reflection

In a recent one-on-one with a teammate, I asked my colleague to describe how he generally approaches a workday. After actively listening to his response, I invited him to tell me how he typically ends a workday. The look on his face was one of intrigue. My teammate shared that he likes to end each day with an unfinished task so he has something to gain momentum with the following day. There are no right or wrong answers to either of these questions. My objective was to promote self-generated, actionable insights in my colleague that could support his goal identification and motivate behavior change. The University of Zurich research cited above identifies having a "growth orientation" as a critical trait of successful developers. This means that successful developers are constantly learning and striving to change their behavior to increase efficiency at work.

I asked my colleague if he felt his approach worked for him in that same one-on-one conversation. It generally did, though there are times when the momentum of the following morning is short-lived as the unfinished task is completed. Identifying an inefficiency in his workflow led my teammate to reflect on his work habits. He might benefit from keeping a personal task list, which he could use to validate his experiences at work while mentally preparing how to proceed with the most important things he intends to accomplish the next day.

I asked my colleague what method of keeping a task list would be most effective for him. There are several apps designed to facilitate this process. He could also use the notes feature on his laptop to jot down tasks and statuses throughout the day. Physically writing things down with an analog pencil and paper is a valid option too! The objective isn't to figure out which method is the best system. It is to figure out which method is the best system for him.

This naturally led to a specific discussion of what to do with his task list. Should he work sequentially from top to bottom as a new workday starts, or would it be more valuable to first review priorities and accomplish essential tasks? Should he review his progress at the end of the day and plan for tomorrow, or would it be more effective to save his planning for the beginning of the following day as a catalyst for action? Again, there are no right or wrong answers here. There is only an attempt to synthesize and articulate strategies for growth.

This is just one example of contextualized self-reflection focused on one specific work habit among many good topics.

In addition to improving time management, other potential areas of self-reflection could include avoiding self-induced deviation from planned work, improving your impact on your team, maintaining work-life balance, or developing a meaningful embedded learning routine.

The purpose of deliberate self-reflection isn't to identify goals for achievement. It is to chart new courses to make progress towards growth. Notice that the second stage of deliberate self-reflection isn't identifying suitable goals. It's identifying suitable growth goals. James Clear, author of Atomic Habits, writes, "Naturally, we are outcome-focused because we want our new behaviors to deliver results. New goals don't deliver new results. New lifestyles do. And a lifestyle is not an outcome. It's a process. For this reason, all of your energy should go into building better rituals, not chasing better results."

Whether you are just starting a self-directed path of learning how to program or are a senior engineer with a knack for architectural software design, the research doesn't lie. Successful software developers share similar attributes, including striving for productivity and efficiency, being self-aware, constantly learning and self-improving, and setting challenging growth goals.

Building new habits can be difficult. Newton's First Law of Motion is a law for a reason. But as we consciously choose to prioritize as little as 10 minutes of our day to take a self-inventory of our experiences and key lessons learned, we will become more productive, engaged, and experience higher levels of well-being. We'll also become more self-efficacious, a potent antidote to imposter syndrome and feelings of inadequacy. Fortunately for us, we can achieve this by reaching for low-hanging fruit. What developer wouldn't jump on a simple refactor that promised optimization by a double-digit percentage? Perhaps it is time we add "self-reflect" to our programming vernacular and then regularly take time to do it.