Cubicle Buddha“Wow. Look at this code, it looks so nice! And it’s so clear and easy to read!” Clarity and readability are admirable things to aim for, but is it possible that the quest for “perfect” code is preventing you from actually RELEASING real functionality to the user?
When my perfectionism is owning me more than helping me, I remind myself:
“Yesterday is already gone. Tomorrow is not yet here. Today is the only day available to us; it is the most important day of our lives.”
– Thich Nhat Hanh
What Thich Nhat Hanh is referring to is the Buddhist concept of Impermanence.
“Impermanence..?!?” What a crazy thing to be talking about in relationship to software. “Aren’t we trying to build something that will stand the test of time?” is something a rational human might say. But what impermanence refers to is the fact that all things decay and/or change. Maybe that notion is scary or sad to you, but that’s not what we’re trying to do– CubicleBuddha.com is all about lifting you up! So instead of being sad about the staleness of yesterday’s effort, remember that your users want the code to change to support new use cases. So why not focus on what your users need today– after all, “[today] is the most important day of our lives.”
How Do I Know When Fear Is Preventing Me From Helping My Users?
It doesn’t take very much time to find a company that is afraid of change. Here are some clear markers of that “fear of change” and how it can lead to a slow development process:
- Products that are delayed because “it wasn’t all ready.” (Who cares if it’s not all done? Release what you have!)
- Code that never gets released because of poor understanding of the requirements/ acceptance criteria. (If you’re trying to add value for your users, you should probably ask them what they want. And better yet, try to limit the number of people that the message has to flow through between the user and the developer. Whisper down the lane is a killer.)
- A product that never gets released because the contract was canceled before it had a chance to “go live” to the customers. (This means that the company clearly waited too long to get the work out to the users.)
- Code that is rewritten all of the time because new requirements come in all the time– i.e. “swirl” or “churn.” Again, this is a clear sign that it took too long to get the product out to the users. Software isn’t made out of stone like I used to think– it’s very easy to change. And if you don’t think it’s easy to change, then you’re not writing with an eye towards refactorability. Think about it this way: a contractor who is building a porch or a roof can’t build it quickly and then ask the home owner if he likes the work. They’d get fired and/or taken to court if their work was deficient. But a house contractor can draw up plans and get feedback on these low-fidelity mockups of the work. We have almost no excuses in software since not only can we have the users review our plans, but we can also get the work out and then change it almost immediately.
What do these scenarios have in common? They’re all examples of how embracing change would have made for more pleasurable experiences for all involved.
So, How Can I Embrace Change?
Maybe you’ve recognized that you want to make the jump, but you don’t know how. You ask, “what does embracing change mean in software?”
- It means writing code that lets you make quick changes without breaking the past. This means using good design patterns (like we’ll discuss in future articles).
- It means writing unit tests so you can make new updates without worrying about whether or not you broke your last updates.
- It means removing “Dead Code” so that the past doesn’t slow you down and creep up as unexpected bugs.
- It means worrying less about the “beauty” of your code and more about if it makes your users happy and if it makes future developers happy to build upon it.
- It means loving and understanding your peers, even when your Product Owner comes to you and says that we misunderstood the customer and therefore we have to remove the code you just worked so hard on. That’s change. And as long as your listening to the needs of the customer, you’re changing for the better.
We’ll be touching on many of these solutions in future articles, but let’s unpack that last point a little bit:
How I Learned To Be Happy Deleting Code
In my years of professional programming, I have had to delete functions, features, and entire products countless times when my bosses “refined” their understanding of the customer’s needs or the market’s needs. So when that happens, did I get sad over the loss of my code? Heck yea I did! I’m only human. But eventually you realize that every time we write code, we’re producing our best guesses of what the customer needs. As we refine that guesstimate, we have to remove or delete the parts of the product that were bad assumptions. Sometimes that means deleting your favorite parts– yes, even the parts that you really thought were beautifully written. But was it really beautiful if it wasn’t helping the customer?
You might have read my critique of “beautiful code” and thought, “is he asking me to not worry about readability?” Of course I’m not! I am simply recommending that you don’t let yourself become slowed down or paralyzed by thoughts on how the code should be structured.
The best way I find to unburden myself from these thoughts is to ask myself, “Do you think that future developers will see your code and think this is beautiful?” The answer is almost certainly “no.” The dirty secret about software maintainability is that most of us only like the way our code looks.
Ignoring “pretty” and perfection
What we’re trying to do is make a tiny amount of room for acceptable failure so that perfectionism doesn’t control you. When you’re thinking from the perspective of balance you can consider thoughts like “I want the code to be maintainable but I also want to get value out to the users today!” We would be wise to remember the words of Confucius who said:
“Better a diamond with a flaw than a pebble without.”
So my wish for you is that you accept and learn from the flaws so you can grow your work into a diamond day by day. And if your peers have flaws, accept them too– they’re also trying to grow and learn too. If you don’t let go of the past, then you can’t make room for what really matters today.
—————————————
If this article helped you, you might interested in other articles from CubicleBuddha.com such as:
Thanks again for reading. I’d love to know what has helped you to accept change in the workplace?
