Who is a Zen programmer? – Someone who can write incredible solutions by getting into the zone, at any time, at any place.
Is programming really an art? How do you get ‘into the zone’ while programming, and is that consciously possible to achieve? How do you write the best solutions that you can be proud of? ... Ever had such questions? I don’t know about you, but I had such questions, a ton of them over the years as I grew as an engineer and a programmer. In this multi-part blog series, I will go over some tips and skills to focus on mastering the art of simple programming and becoming the best version of yourself - a Zen programmer.
Start with the end - Visualize the end product and result
Start with the end! Excuse me, you say, what does that mean? You heard it right the first time – Start with the end! Visualize your creation before you even write your first line of code. There are tons of books written across subjects, from philosophy to politics, which emphasize the art of visualization. Like any art, visualization needs conscious learning and practice. Some people have a natural edge when it comes to visualization, but don’t worry if you aren’t one of those lucky ones, yet, as you can still learn and practice this art.
Let’s say you are working on creating a website to sell art pieces listed by various artists. You may have zero knowledge of painting or relevant arts, but you can still visualize your final solution. Imagine a live website where an artist logs in and adds his paintings for an auction and part of them for fixed price sell. Then there are end-users, art-lovers, should we say, who log in and try to find the art piece they want to purchase. Assume now a user logged in, he is searching for a specific artist and then wants to see all art pieces from a particular artist listed by popularity. Then, the user picks the top-most rated one for direct purchase. Now, did your mind paint the picture of this site as you read this - That home page with login window and page listing art results as thumbnails? Congratulations! After all, you can visualize very well. Just you never thought you had it in you. Maybe colors for pages and theme may be different than me imagining the same site, but we are heading the same direction of thoughts here. If you and I were working together, then isn’t that nice to have?
“To bring anything into your life, imagine that it’s already there.” Richard Bach
As babies, we were always curious, always creatively imagining new things, but then we grew old and put aside this most wondrous gift of curiosity. Visualization is an art and a technique, which opens a window of curiosity. As you start visualizing your end-product or solution, you will get more curious about the final result and start asking these questions – like in the above scenario, how the home page should look like? What will the page title be? How many entries should we list on the page? Given artists will log in to your website, what theme should it be? And so on. And those are good questions! Sure, you might not be able to answer those right away, but essentially, those questions are showing you the next steps (mostly research steps) to get the design right.
So simple rule to remember is to start with the end – visualize your end solution. It will not only help perfect the design for your solution but also help you sharpen your visualization skill. After all, like any other art and craft, practice will make you better.
Understand the targeted product/solution's domain
Imagine you are becoming a trader with manufacturing nuts and bolts. Your product material quality is by far superior to any other competing product in the market. You set up a fancy shop in a very happening area of the city, as you believe in yourself and giving it your 100%. You are in it to become master of that trade. There is, however, only one problem – your nuts and bolts don’t fit any industry standard.Your first customer is a company which is into manufacturing some machines. They trusted you and placed the first big order with you with a trust that they will get the finest quality nuts and bolts, as, after all, that’s what you want to do to become giant in this trade, and that is what your passion is.
Now, what do you think will happen when this first customer receives their first batch of orders? Good, you imagine possibilities ahead, see getting better! There are a couple of potential possibilities – the customer will call you back and say that nuts don’t fit any sockets, so you got to rework them. You cannot fix existing delivery as you also employed a no-return policy, so you say no, or worse, argue that the customer doesn’t know the basics of using the product. Customers will make do with what they got finally, as they have their schedule to meet, so they just add some packaging with your nuts and bolts, or worse, throw away your product altogether and buy new ones. While concluding this story, do you think the customer will return to you again to buy more?
So, what went wrong here? You had an undoubted passion for what you were going to deliver as the final product. You believed in it, so you even gave your 100% to it (monetarily and much more). Your quality was also on par with anybody in the industry. Only one minor issue was that you didn’t master the skills of the trade! Sure, you learned how to make nuts and bolts, but you missed the standard for making those used by the industry where your product ultimately got employed. Now, that is part of trade skills. And though small looking, it threw away all your passion, dedication, efforts, and ultimately, carefully crafted end product.
This example is easily mappable to software engineering and programming. If you ever had a customer for your solution with hair-pulling moments, or one who had to make do with your product, for whatsoever reason, then essentially all you did in those cases was to deliver them wrong nuts and bolts! You carefully crafted the highest quality solution, with 100% passion and dedication, just it was not what the customer was looking for, and so the effort was a waste. It is essential to learn the trade skills first before entering into any new trade. Don’t shy from learning the new domain before you start your solution design.
“People do not care how much you know until they know how much you care.” - Teddy Roosevelt
If you don’t want to learn the domain of your solution, then don’t get into it in the first place. In every programmer’s life, there comes a moment when she will know nothing about a domain and be supposed to write a solution for it. View it as an opportunity to learn it. You never know; you may even become a master in it one day. So keep an open mind and understand the domain and trade skills for it upfront, as much as you can. After all, you wouldn’t want to deliver the wrong nuts and bolts from now on, would you?
Complete research upfront
Let’s go back to the art selling website example from earlier. That is your professional assignment, and you are supposed to deliver the website in the next month, as that is what you committed to the customer with your gut feeling that you can pull it off. Okay, so you visualized the result, good, so you know what pages to add and what customers and artists will have as an end experience. Great! So, you did some page designs on a notebook, or maybe with some professional wireframes tool. Everything ready to start coding, right? You jump right in. And before you know, your home page is up and running, shortly users and artists menus are up. Then shortly after that you even have dummy artist listings, and dummy user accounts up too. Awesome, you think, I am on fire and here to kill it. You play your Spotify song playlist and take a cup of coffee. Back to coding again, page after page, getting ready.
As you are progressing, you realize that you don’t have the payment menu ready yet, so you decide that you complete that part first before wrapping other pages. After all, the payment menu and options are critical parts of this solution. You add the payment page, as you found a widget for credit card inputs, so awesome. But how do you test this? Okay, you google – “how to integrate payments in a website?” You learn that there is a concept of payment providers and payment APIs. You also understand that to integrate with those APIs, you have to create an account with one such provider and do a formal Know-Your-Customer (KYC) process, so your website can be whitelisted for API access. So you Google the entire process of how to do this – each step figured out. Awesome, again! However, there is one problem – the formal onboarding process for payment providers is lengthy, as it needs many documentation steps. The entire process will take four weeks to complete, and payment provider review of the account poses a risk of you not being approved for access. Oh, snap! You committed for a month to deliver this solution to your customer, and you are already halfway in that committed month. What do you do? Should you tell the customer that you completely missed this critical research for payment integration?
Over the last two decades, I have seen many engineers and programmers who sit for programming without any prep. Sometimes, some drawings are in the notebook, and a significant product feature starts only on that note. Then as these folks get deeper into completing the solution, they have these multiple roadblocks and so hit on the delivery schedule for the entire team. Those roadblocks were really the day-1 problems. Worst then is that under panic, these very same programmers target solution completion than quality with whatever workarounds possible. The most common symptom of a panic-stricken delivery is a solution or product which needs a lot of tuning to get it to work for its customers (Remember wrong nuts and bolts?). It results in a poor customer experience and, worse, affects your and your company’s reputation.
A Zen programmer visualizes the result, but once there, she will also figure out individual logical components for that visualized solution, their interactions, and all minute details for each. The visualization art empowers you to find logical parts of the solution, then put some time thinking about each component and how it will work and integrate with everything else in the solution. Effective research is art too, and it goes hand in hand with the visualization skill. When done consciously, typically effective research will show you new design skills to learn and language techniques to practice. Don’t shy away from sample coding too. The old 80-20 principle with 80% of the time for design and 20% for code still holds true even in the agile world! The more thorough the research you do after visualization, the more seamless the execution experience you will have as a programmer. You will indeed have those in-the-flow Aha moments more often in execution then.
Master easy-maintenance designs
Once, someone asked me - why should I care about maintenance? Shouldn’t I target rather zero-defect design and execution for a solution? The answer to that is - Absolutely! But maintenance, apart from traditional bug fixing, also includes extensions (and rarely and less preferably modifications) for your solution. So the focus for a solution should be on extensions of the solution than mere bug fixing.
In Zen and most Buddhist philosophies, there is an insistence on impermanence. Every single thing around you is changing – you and your family is growing old, nature is changing, the company you work for is growing (or shrinking), the weather every day is different, and so every single thing in your life is changing. This impermanence also extends to software solutions too. Once I worked in a small company that had a product targeting specific use-case in the telecom domain. The day-to-day work of creating software features wasn’t anything different than you would imagine. Now fast-forward a decade – I no longer work for the company, the company got acquired, the product is still around, the most team worked on it is still around there. The small group that worked on this solution became a mammoth business unit within the acquiring company, as the product grew leaps and bounds in both customers and revenue. Now put yourself in my shoes and assume you worked on such a product. If you were to go back and do those solutions again (but this time, you have enough future knowledge of how big this would grow), then do you think you would do a different design for the exact features you wrote? I am sure you would, as I would too.
You can apply the impermanence principle to pretty much any product feature or solution you write in your current company and job. Think this way – if the piece of code you are about to write now will live and grow in the next five years, will your future self be happy with the design you are doing now? Some people may think that – okay if this stays five years in the product, then it must be a good design and correct code, right? Not necessarily. It could also be that the feature code, though hard to maintain, simply couldn’t be replaced due to too much tight coupling with other vital components. So your future self may be maintaining this code just because it can’t be replaced without significant product impact.
So how do you create easy-maintenance designs? The first step in creating such a design is to accept the code-impermanence principle – every single line of code you write will be changed. The change can be to make it better, fix bugs, or extend the feature, which all accounts for maintenance. When you start thinking this way, you automatically start thinking about scalability, performance, bug-fixing cycles, etc., which will make you cross-question your design decisions before actual execution. That is a good thing, as it will help you solidify the design.
Learn to be empathetic to your future code maintainer as if it will always be you (Wouldn’t you be kind to yourself?). Smaller things – like better variable naming, consistent code structure and syntax, extensible design with time-tested design constructs (like design patterns) use, are a few things where you can start.
Just ask yourself this before you stamp your design as good – Will your future self maintaining the code like this design and still find it relevant with less maintenance work? The key to easy-maintenance design lies in the answer.
(To be Continued)