Passion is essential; Dogma need not apply

I was listening to a conversation between Roman Mars (99 Percent Invisible) and Ryan Coogler (In Proximity) talking about a collaboration. Towards the end of the conversation, Roman said something that rang true to me. He said:

“… there’s a million ways to make something good. Like, I’ve reached this point where I was like… I think there’s the beginning of your career, you feel like you don’t know how to make something good. And then the middle of your career, you’re like, “I’m the only one who knows how to make something good.” And you know the perfect way. There’s, like, one way to tell a story. And then later on in your career, you’re like, “There’s a million ways to make this good.” Like, I’ve heard and seen people do it so good, and you could do it differently or you could choose this one or you could say it this way. You just have to write your way out of it to make it make sense for the audience. And you’re serving an audience. But there’s, like, a million ways to make a good radio story. There’s a million ways to make a good movie.” – Roman Mars

That instantly made me recall one of the first things that attracted me to programming. Unlike most of the math classes I was taking at the time (the limit of a function as it approaches infinity still hurts my brain), in programming, there is more than one way to get to the “right” answer. That was such a freeing concept. You could find your own way to solve any problem. You could be as creative (or not) as you wanted.

All of my beginning programming assignments regardless of language or platform were graded not on how the program was constructed, but on whether it would process a set of inputs into an expected set of outputs without error. (It compiled, ship it) I can’t imagine having to read through hundreds of students programs to critique their style (all while working on your own dissertation).

As I progressed in my career, I had the good fortune of working with very clever, very passionate programmers. I learned more “elegant” ways of solving problems. I learned:

  • more languages

  • more operating systems

  • more editors

  • more domains

I became passionate and embroiled in efficiency and structures and form and messaging and OO and Patterns and data and …

The dogma had crept in. I knew the best way. I would argue endlessly about very important things like:

  • functional decomposition

  • message structures

  • vi vs. vim

  • variable naming

  • indentation

  • curly brace alignment

  • tabs vs. spaces

I worked with people who truly believed, that if it was hard for them to figure out, it should be hard for you to understand. Clever was better.

It took me years to learn that simple code that was easy to read and easy to maintain was good. (And allowed me to move on to other challenges). To recall something that one of my instructors said early on, “Write every program like your boss is going to have to debug it in production at 3:00 in the morning on a Sunday while you are on vacation, and you like to still have a job when you return”. To learn that being the cleverest is not always the best.

This is why at Idea Harbor, we are passionate about our craft, but not dogmatic about its applications. We are truly technology agnostic. We have opinions about tools and processes, but we have the experience to help you make whatever tools you have already selected work and accelerate their value. While we believe in agile (notice the lack of capital letters) ways of working, we can help you make your version work for you and not you for it.

Get in touch and let us help you rekindle your passion, all while making your deliveries better, faster, and more reliable.

Previous
Previous

Secure Software Supply Chains - Regulations, Frameworks, and Standards

Next
Next

Navigating Secure Software Supply Chains