What is the art of coding?

I think people in my industry would hesitate to call coding art. It’s very black and white in many ways, but there is a certain elegance to programming. It's about taking structure and ideas and expressing patterns in a way that is both efficient and easy to understand.

There's room for art, but at the end of the day we are building things that are useful to other people, so it's more of a craft. In the same way that a carpenter creates things from wood; there's an art to carpentry, but they’re making a chair or a desk or a house.

Do you have to envision the whole project before you can start?

That's one of the challenges. You need to balance seeing the forest for the trees while also being able to dive into detail on the things that you're building. On the team that I work with there are people at the higher end that are thinking about the direction the product is going. They're thinking about not just how to build a thing, but whether we should we build a thing. A lot of the elegance I mentioned is in managing the complexity; building a complex thing that can be managed in smaller pieces -- being able to look at part of a piece of software without having to think about how everything else works, being able to express just that piece in abstraction compared to the rest. It can be very difficult. There are sacrifices made in the interest of time, in the interest of shipping a product, in the interest of delivering new features on the things that make companies money. Focusing on the underpinnings and really building a product in a healthy way is important. It's like an live organism - you can't push things too far.

Have you ever thought that you're building a life form that needs to be nourished and cared for?

I have to think of it that way. The reality of it is I'm building something in a particular technological context for a certain platform for a specific audience. The best software succeeds in its time and disappears after it's done being useful. There is a lifespan for a piece of software - 5, 10, 20 years. There is a birth and a death; especially the way software moves these days. When you set out to build a piece of software you have to ask how long it’s going to be viable. The company using software has to ask themselves when to shift away from maintaining a legacy piece of software after 10 - 20 years, and begin embracing the new technology and the new platform and build the next thing. That cycle is real. There are a lot of companies that cling to their old thing.

It’s tough for a company to build new while still trying to operate.

There are companies that have different approaches. Apple is very much ‘Out with the Old, In with the New.’ They push envelopes other companies hesitate to push, such as removing headphone jacks from their products. Headphone jacks have been around for decades. There's a value to pushing the envelope and there's risk attached to it. Ultimately, those who risk cutting into new technology that’s not fully formed and being the first to that playing field and building something real and useful and engaging -- they're the ones who continue to win the game.

You're a musician and a visual artist -- do you feel that what you do with coding uses the same parts of your brain as music and art?

Not with music. With music there's a level of abstraction and more of an emotional expression. There's less cognitive thought, less logic. Music is open-ended and free, it’s emotional. Code is intuitive and logical and there’s the excitement of putting a pen to paper, of embracing a craft. People on the outside won't fully appreciate what's under the hood that you've built. Other programmers, your peers, will. Again, similar to a carpenter who can truly appreciate the edges of another carpenter’s work.

Do you ever get emotionally tied up in a piece of software you’re building?

I get very invested and attached to the way something is built. There is a sense of ownership, a sense of creation and pride. I find myself often going through cycles, probably similar to the way an artist might look back on old work and see their growth. Months go by and you look back at old things and see the flaws.

How does perfectionism work in the coding world?

There's always an impulse to be constantly polishing that stone. There is a level of perfectionism and the feeling that a project is never quite done. I want to keep buffing the edges, to keep making it better. I think it's an important driving force as long as I know when to let it go. Often, I have no choice; I have a certain amount of time to do a thing and to make it as good as I can. It's that balance between my capacity to produce and the product itself. At a certain point, the product has to ship. Perfectionism, when balanced right is a positive force.

You spend a large part of your time behind a computer, how do you find balance in your life?

It’s a strong need and often I ignore it for too long -- the need to get out of the city, to get away from fluorescent lights and computers and being inside. I enjoy the work profusely but at the end of the day, I'm fried. I balance it with something like rock climbing which is very intuitive and somewhat structured but is also a freeing thing. I can lose myself that way.

When you're climbing are you coding in your mind?

It's interesting to me how many people in the climbing community work in tech. I think there's an affinity to kind of a physical chess or physical problem-solving. Funny, in bouldering the climbs are called ‘problems.’ They're a physical puzzle to solve. That's a lot of where the appeal is.

And coding is a physical puzzle to solve?

Computers only work because of the principles of physics. Arguably, all computers are physical things. And yes, if I were to try to describe what I do for a living to a layman it would go something like: Imagine that you go into work and you play a game of chess or a game of Sudoku. The rules of this game always change and the game is always slightly different. Every time you win the game you are one step closer to the product or the feature that you're building. At the end of a series of puzzles, you have built the thing and achieved your goal.

The software, Assembit, that you created for our Company was arguably your first major creation.

Building Assembit was very exciting but it was also a risk - like jumping into the unknown. A whole new world opened up with the software we envisioned together. I knew that there would be a lot of responsibility to deliver things that I had confidence I could create but wasn't sure how. It was very exploratory and there was something very powerful in that scenario We needed to put a brand new idea into the field. Often I would have only a week to build, test and take it live. The opportunity to be able to do it and constantly refine -- that kind of a cycle is amazing. And there were panic moments where nothing was working. It was stressful, exciting, engaging and fun. And ultimately it turned me into what I am today.

Your route wasn't exactly direct. If you could go back to 10-year-old Panzer and whisper in his ear, what would you say?

I would tell a younger me to relax, to stop stressing and enjoy the ride. Stop worrying about what's next or what you have to do or whatever thing you're stressing out about. Be more present. Embrace what's happening. And also to make time for fun.