The Art of Coding

All roads lead to solving problems, does that mean it's art?

Mar 04, 2021

Did you know that the seminal cookbook “Joy of Cooking” is 90 years old? First self-published in 1931, it went on to become the most published cookbook in the US, selling more than 18 million copies. And as long as I can remember, there was always a copy something in any house I was in growing up.

The influence of Joy of Cooking is evident in the numerous cooking blogs which reflect the folksy, narrative style of the author Irma Rombauer. It reflected the belief that good food is not just about the ingredients and the steps. Behind every recipe is a story that brings each dish to life.

Cooking for me is both an escape and an adventure. It’s an escape because it clears my mind and I just focus on the task at hand. It’s an adventure because rarely does my cooking follow the strict sequencing or ingredient lists of recipes. Recipes are merely guides along a journey that can have many novel and surprising outcomes.

I never used to be so carefree with cooking. I looked at it as a science. Each ingredient had to be measured to the exact amount, all temperatures monitored, and cooking times followed religiously. Then I realized over time that results were better when I tweaked ingredients and preparations. I would mix and match the best ideas from many recipes to find a combination that I preferred, or scrapped the recipes altogether and went with intuition.

My journey learning to code and becoming proficient followed a similar path. In grade school, I would type programs I found in computer magazines into my Commodore 64 and see what happened. I would do the same with the class assignments from school. Rarely did I modify any of the programs though because I never knew what I wanted to change or where to take them.

The desire to code faded during high school and college. I had other interests that mostly gravitated towards reverse engineering hardware or hacking the university’s Unix system. It was not till I started my first job in tech that I experienced the joy of coding.

What changed? I had a direction that tapped into my motivation to solve problems for customers. The first customer was internal, building a system for my company’s sales team to track accounts and deals. Then I moved to helping customers with problems building high transaction systems for trading apps, multi-channel retail ordering, and court management for state judicial systems. The puzzle excited me and I would spend an unhealthy amount of time in front of a computer churning out code.

A career shift took me away from coding for a good decade until I launched my own startup. Getting into the startup scene and back into coding led me to the writings of Paul Graham, the co-founder of Y Combinator. Before launching the world’s leading startup accelerator, he was well known for his numerous essays, which culminated in the book “Hackers & Painters”.

The title comes from talk he gave, which later become his most widely read post about the strong similarities between coders and painters. The frame he hinges his essay on is the idea of the “maker”.

Rather than equate hacking to programming or computer science, he saw what he was doing as a very different discipline:

“You should figure out programs as you're writing them, just as writers and painters and architects do…If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching.”

Coding as taught in colleges and written in big companies is far from his vision of sketching. He saw it as trying to force fit the craft of hacking into artificial constraints and imaginary timelines dictated by people far away from code:

“Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.”

Hackers are free to follow their vision. This is what enables startups to create products that users and customers love. Conversely, the programmers stuck in the software warehouses of corporate enterprises are relegated to making mediocre products:

“Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters…they don't win by making great products. Big companies win by sucking less than other big companies.”

I thought this was a curious stance since I wrote plenty of software in my career and nearly all of it for big companies. All of these products were launched successfully and received excellent user feedback. Under no circumstances did I ever feel like I was a technician disconnected from the creation process. Rather, all stakeholders and teams collaborated to make products that were of critical business importance.

It is worth noting that I have been highly vocal of ugly enterprise software. Working at Siebel, Oracle, and other enterprise software companies over my career, I was well aware of how maddeningly convoluted software can be. There was nothing to love about the software when looking at the out-of-the-box experience.

When the software clicks with users however, the impact is immediate. One bank customer I worked with was able to take a 30 day reporting cycle down to 1 hour using Siebel’s analytics product. The downside is that project took over six months of effort to complete and a small army of consultants to deliver.

Now in the era of cloud computing, the time it takes to build high impact solutions can be counted in days. Going from idea to live users does not have to take months. As an example, UC San Diego Health was able to develop and deploy an AI-based algorithm in less than 10 days on AWS to detect COVID using faster methods in the early days of the pandemic. COVID also hit banking, and one Indian startup was able to take KYC from days to seconds using a video KYC process built on a serverless architecture and Amazon Rekognition.

Great software does not just emerge from hackers sketching logic into the blank canvas of an IDE. The true art of code is what emerges when great teams gather around a mission. That means designers, product experts, engineers, operations, and business stakeholders coming together to solve big challenges or deliver something groundbreaking.

Team size matters though. What Paul observes about the software in big companies is true. It’s a problem of any company that scales to an appreciable size, including startups. Too many cooks in the kitchen spoils the soup because everyone wants to add their seasoning. This is the insight that led to the two-pizza teams at Amazon.

Smaller teams deliver more focused products and features faster than large teams. A team that can be fed by two pizzas is usually ideal, about 6 to 8 people. This minimizes communications overhead and cross-functional friction because you bring talent with the requisite skills needed into a single team to fulfill the mission.

Paul is right that the best source of ideas are not necessarily from the field of computing. Ideas and the software that drives those ideas are enriched when they bring many different disciplines and a diversity of experiences together, all driven by the needs of the customer. Collaboration gives you more colors to paint with.

Purely creative coding has its value. Startup hackers will continue to push the bounds of what is possible in their “fanatical devotion to beauty”. Solving problems for customers though is its own beautiful and worthy process of creativity.

Do you feel coding is a purely creative effort? What are projects that you are working on now or in the past that felt highly creative and rewarding, and why?

Mark Birch, Editor & Founder of DEV.BIZ.OPS

DEVBIZOPS

Discussion about this post