Why I Program

Or, maybe more accurately, why I am a programmer.

People program for many reasons. If your reason differs from my or others' reasons, that's totally cool! We need diversity in this industry, and having differing reasons will broaden our holistic approach to not only problem solving, but to the underlying philosophies that our tools, frameworks, languages, and companies are built on. I'm hopeful that this diversity will grow as our industry continues to mature.

So, why does Sean Newell program?

My Reasons

To Learn
To solve problems
To help people
To exercise rigorous creativity
To explore

Boom. Blog post over.

Let's start a discussion on each of these reasons since discourse is how we refine one another.

To Learn

I am a voracious learner. A livid learner. (Insert your profound two-word phrase here). In fact, it gets me into trouble sometimes. Case in point, refer to the previous blog post - I probably was minutes away from getting my nginx config to work, but then I learned about Caddy, then traefik... When does it stop? When do I stop hopping the tool or framework train and ship? Here's the deal though.

When I have to ship, I don't stop learning.

Shipping doesn't mark an end to the cycle of exploration and discovery, but rather shipping itself provides a rich set of instructive experiences that can direct my learning further.

"Experience is the best teacher."
-Cicero, Oration for Rabirius

This cycle is inherent in programming. And not just because of tooling / framework churn, but also because of the nature of our craft. In the book "The Mythical Man Month", the author characterizes programming as dealing with "pure thought stuff". This means we can learn as we work. Not just through mastery of our skill, but by thinking and iterating on our thoughts. Composing new ideas, and seeing how functions combine in new and interesting ways.

That's exciting! And it drives me deeper into nooks and crannies of programming to shed light on the parts that I don't quite understand fully yet.

To Solve Problems

At my core being I'm probably three things. A sleepy man, a learning man, and a problem solver. It's my default when I'm presented with emotional, relational, or analytical problems. It's just what I do.

And programming, specifically being a programmer, demands that I have my problem solver cap on all day.

Sometimes the problems are rote, have been solved before, or have already been solved and I simply need to implement the solution. Other times, there are interesting twists, constraints, or other circumstances that drives me to think a little deeper, or ask more questions to get to the heart of the problem.

Either way, a problem is solved, and my brain has to flex. Whether that's categorizing the problem into an existing box, or transforming and composing a problem domain into a workable solution.

This is where my exploration of functional programming has paid large dividends, because the 'known problem space' now, for me, keeps expanding as I learn about problems other people have been solving for the last ~50 years in category theory, general maths, and other programming communities.

To Help People

Helping people is a core component of relating to others in a healthy and productive way, and teaching is often the best teacher, as it forces one to refine ideas and find concise language to deliver an idea well. So being a programmer allows me to flex these relational area well, whether that's teaching or exploring with a co-worker or delivering a feature or product to a customer.

It's important to note that this is what drives UX and other user-centric methodologies, that's what makes those careers so rewarding. It's a great feeling to know you made a site more accessible, reliable, or usable for real people.

To Exercise Rigorous Creativity

Programming, math, and engineering are a special kind of art. These disciplines all deal with certain laws, invariants, or conditions and constraints, but require some desired output. It is then our job to massage the inputs and get the desired output, or prove some desired property (like "this bridge will hold X cars").

We have to apply a rigor and care to the laws and maths that define our environment, but we have freedom in how we mold and use those laws to bend to our will. It takes practice, discipline, and a certain bull-headed-ness that I find in many programmers. We just don't give up. We press into the discomfort of a tangled problem.

Then magic happens, a la a creative leap or insight, or a plain educated (or not) guess. Then an idea becomes a reality.

That's beautiful!

To Explore

This may seem redundant - and if so then all I have to say is that repitition is the friend of the adult learner. But really, I think exploration warrants a different discussion.

You see, it's expensive to experiment in most industries. That's why there are RnD departments. In software, going back to that pure thought stuff idea, we can iterate and experiment as cheaply as we can type git checkout -b new-experiment.

Or rather, it can be cheap to experiment in our craft. As long as we are responsible and aware of how our experiment affects the project and team. Often an experiment can improve an existing tool chain or arcane build script, or provide a new, useful abstraction around some mundane work.

Fin

So hopefully some of that resonates with you - feel free to drop a comment via disqus down below and tell me some of your perspectives.