Rediscovering the State of Flow

Thoughts on Programming

A specific combination of three events all came together to rekindle my interest in the flow of programming.

The first was binge watching Halt and Catch Fire on Netflix. A show about programming some of the earliest PCs, many episodes showed small teams of engineers working on breakthrough projects to enable the advent of personal computing. The second was reading Cal Newport’s book Deep Work that encourages people to remove distractions to create intense focus and solve their toughest problems. The third took place at work. I am a VP of Engineering at Capital One and am leading a team to migrate part of our analytical environment to the cloud. This infrastructure has been in place for over a decade and evolved throughout the years, resulting in thousands of tables supporting the business.

So, I had these three elements going on: watching Halt and Catch Fire had rekindled in me the desire to program again, reading Deep Work inspired me to deeply focus on a task, and the spreadsheet disposition problem was something I needed to solve. So how did this desire, this inspiration, and this problem coalesce into flow?

To answer this, I want to focus a little more on that third event — The thousands of tables we had to migrate were sent to me in a spreadsheet to review and disposition. We were operating within a tight timeframe and I needed to migrate the tables within that constraint. I thought to myself, “If I could reduce the number of tables it would jump start our data transformation efforts and give us a window to success.”

When I first opened the spreadsheet, I had immediate cognitive overload. It looked like random bytes on a computer screen. As I looked closer, I started to see patterns in the data. It was not actually random, the records followed a strict naming convention with each word being separated by an underscore.

I decided the best way to solve the problem was to automate categorizing the spreadsheet using Python. I would split the words into smaller pieces every time I came across an underscore. Using the split words, I could then categorize subsets of the words into buckets. It had been awhile since I’d tackled this type of problem. The first day I spent stumbling through how to install Python and watching instructional videos on how data structures and control structures work in Python. The second day was consumed by building small apps to read files and loop through the records. On the third day I sat down around 10 AM with a cup of coffee and started on my program again. By this stage I had relearned how Python works and had built the basic structure, allowing me to turn my attention to the business of categorizing records.

Then it happened. I “woke up” at around 2:30PM and remembered I was sitting in my living room programming. I was so focused on the tasks that I had entered a state of timelessness while creating the categorization algorithm. It was like being in a trance — I was deeply drawn into the work and had lost all sense of time.

I had entered a state of “flow.”

Then it happened. I “woke up” at around 2:30PM and remembered I was sitting in my living room programming. I was so focused on the tasks that I had entered a state of timelessness while creating the categorization algorithm. It was like being in a trance — I was deeply drawn into the work and had lost all sense of time. I had entered a state of “flow.”

Flow only exists in the now, and you only know you were in it once it’s gone. Flow is the combination of a challenge, your skill, and intense focus. Flow is not exclusive to programming, and there are many opportunities to enter into a state of flow. Playing sports, cooking, painting, and playing music are all good examples of flow. The result of having achieved flow was reducing the number of tables that had to be migrated in my organization by 75%.

As I reflect on my experience, I am so thankful that I could rediscover flow and remember that engineers have the privilege of experiencing this as a regular part of their job. As an engineering leader at Capital One, I think about the responsibility I have to provide opportunities for engineers to experience flow by giving them challenging tasks that push their limits while providing the space they need to be successful.

This is why I love building software. I hope it’s part of why you love it too.

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2018 Capital One.