Philosophy and Coding
“Is your value system producing the results you want?”
My last post touched a little bit on philosophy. It talked about changing the way we think about unit testing. If you have watched my presentations on Refactoring or TDD, you’ll notice they also talk about changing the way we think.
I used to think that philosophy was just for college kids who have too much free time. Who has time to think about thinking when there is so much work to be done? I was wrong. Philosophy is a very powerful tool that we can put to work for us.
We already use philosophy in coding. We just don’t call it philosophy, but we have certain mantras that we use. These are to remind us of certain principles, values, and ways of thinking about things. I just picked a new one up the other day from Sarah Zalusky’s CLA Summit Presentation: Leave a Legacy, not Legacy Code. There are plenty out there that I am sure you will recognize:
- Code to the interface, not the implementation
- Favor composition over inheritance
- Encapsulate the part that changes
- Write the test first
- Be kind to future you
- Be the developer everyone wants on their team
Each of those could probably be a blog post in its own right, but that’s not what I want to talk about today. I want to talk about why I think it is important to take some time to self-reflect on our values and the way we think about coding.
Act is the blossom of thought, and joy and suffering are its fruits
This quote is from a short yet powerful 25-page book called “As a Man Thinketh”. I highly recommend it. The idea behind this quote is what convinced me that studying philosophy is a worthwhile endeavor and not just something for college kids with too much free time. The idea is that the results we get are usually the results of the actions we take (or don’t take). Most people understand that, but that is not the interesting part. The interesting part that many people miss is that our actions are driven by our thoughts.
As a software example, go back to my previous article. If we think about unit testing as an integral part of writing software, then when under pressure we will still take the time to write tests. The result is that we end up all the benefits of having unit tests. If we think of writing unit tests as some extra add-on activity, then when under pressure we won’t write the tests. The result is that we end up with freshly-minted legacy code that people are afraid to change. It’s not about simply changing the action, it’s about changing the thought patterns. Changing the actions might work temporarily when things are easy, but under pressure, we revert back if our thoughts are not aligned.
I like to take this analogy a step further. If thought is the tree that bears the blossom of action, then the root system of that tree is our value system. Our value system forms the foundation that our thoughts are built upon. Take a look at the Agile Manifesto. It doesn’t talk about specific actions or thought patterns. It says: “… we have come to value …” The authors of the manifesto understood that values drive behavior and in turn results. There are many different flavors of Agile yet many of them share some common actions. Why? Because they all flow from the same values.
What are your Values?
Take some time and reflect on your values (and the values of your organization). I think you’ll find that you will see your codebase in a new light. What connections can you draw between those values and the resulting code? If you are not happy with what you see, then the reaction should not be to simply to change individual actions but to examine what you value.
What should you value? This is a highly personal question and there are many possible answers to this. The Agile Manifesto provides some examples. There is not necessarily a right or wrong answer. The Manifesto even hints that sometimes values can clash and then it becomes “which one do you value more?”. Therefore it is is important to not think about an individual value, but a system of values. The question that really needs to be answered is “Is your value system producing the results you want?” The follow-on question is “If you are not happy with the results, what are you going to do about it?”
Are you ready to examine your values and the way you think about code? Are you ready to commit to making some changes? It’s not easy, but it’s a lot easier if you have a community of people with similar goals to support you. That’s why we are starting a LabVIEW MasterMind Group. It’s a group of LabVIEW professionals who are committed to helping each other grow so they can produce the results they desire. If you are ready to commit to making a meaningful change and joining us on the journey, fill out an application.
