Skip to main content

Deals You Can't Miss

1 Year Subscription

A tale of a lone Zen Developer among Code Factories


This post is a sequel to my earlier post - Embrace and Evangelize Zen Coding. The earlier post paints a picture of who a Zen developer is. But who are Code Factories? Code Factories are those developers that take pride in churning lots and lots of code, bloating the product with features and bugs, with the vested interested of becoming a team's irreparable liability.

"Liability" is too harsh a term? Well, code is liability thus are code factories. Let's get this right. "Less is more", be it product features, team size, or code. Irrespective of your role, learn to get the bigger vision of the business right and work your way backwards, for every task that you undertake. Becoming a Zen Developer helps you in this journey, although becoming a Zen Developer is a journey in itself.

And truth be told, being a Zen developer in a zen team is an ideal state that can hardly be experienced. Being a Zen developer in the pompously 10x-developer teams has its own challenges waiting to be resolved. It's hard, very hard, but well worth your time, effort, and lessons-to-be-learned.

What follows is a story based on a real-life workplace incident to substantiate this philosophy: Any relevance of the event with your team is purely co-incidental and it only shows the prevalence of this pattern in the software development teams.

There was once a company called Ruthless IT Consulting Company that prides itself in contemporary way of delivering software. One of the gigs in this company was about building a product for a travel start-up. The product idea is to leverage millennial's social-media craze of sharing travel information, discounts and coupons with the side-effect of earn discounts in their future travel. This product is to be launched in a few Asian countries, where the national language, currency etc were just different from one another.

A small 3-member seed team was formed to begin building this product by pulling in Mr. Code Factory aka Mr. CF (having solid 10yrs experience in number), Ms. Zen Developer aka Ms. ZD (a developer with 6 yrs exp in number) and Mr. Fragile Newton aka Mr. FN (a freshman Indian under-graduate developer with the dream of wanting to do his MS in Computer Science in the US). It was CF's first project of leading a team and he desperately wanted to build a feature-rich product to wow the customers.

Sounds familiar? This kind of situation is very common and what really matters is how one responds to this situation.

Begin day one, Mr. CF changed gears very quickly wanting to churn as much code as possible to give him the confidence of building that feature-rich product he dreamed of? He literally slept in the office and left for his home in the early morning to freshen-up and be back to office sooner. Guess what the management felt about him? And I leave that to your imagination :) Guess what the other team members felt about him? While they appreciated his intentions, they also conveyed their concerns for him and his health.

One sprint passed by and Mr.CF started feeling a little too tired. He wanted to be an achiever, and read somewhere that achievers are irrational. (Wait, does that mean irrational folks are achievers?) Emotions clouded his sanity and he worked the same way for the second sprint. Mid-way through the sprint, he felt the weight of this new responsibility on his shoulders and couldn't even sleep well. During the day, he would share this pain to his team members and others in office.

Trouble, trouble and more trouble started to brew. Mr.CF now wanted his fellow developers to mimic the same behavior.

Ms. ZD, a mid-senior developer, happened to have seen a lot project failures under similar situations and had learned her way through to becoming a well-balanced Zen developer. So she kept her cool and wanted to alleviate the team pain and equally wanted to work for the success of end-business. She politely negated to Mr. CF's expectation setting, sharing her concerns for both Mr.CF and the end-business. She tried educating that overwhelming stress blinds one to hard work rather than smart work.

Mr. CF perceived this as resistance and threat to his personal success. He turned over his heat on the other developer asking for his compliance to his new expectations. Poor Mr. FN, the newbie developer was caught in the middle of this war. Fearing threat to his personal dreams, he agreed to comply. Ms.ZD is on a sure loosing side of the game. She knew it well. She preferred taking the risks at her personal costs in the hopes of convincing the team of its folly.

ZD in the meantime decided to stay calm and work her way. Suddenly, she saw a glaring opportunity to prove her point. By the very nature of the product, there were a couple of user stories on cross-border currency transactions. Thankfully this was part of the current sprint development work.

She proposed that both CF and herself pick that story and do the development work individually to see how each approaches the problem. To her surprise, CF agreed; for he thought he could drive his point across. This is an unusual twist in tale that is unlikely to happen in this kind of team environment. Luckily it happened in this steam. ZD asked him how he would approach this work. CF was excited at this question but drifted to self-praising his worth. He was actually attempting to build internal confidence, by loud self-talk. After patient hearing, ZD then asked for a solution to this problem. CF thought about it and listed the following tasks:

Do POC for a currency-converter service to translate USD to/from local currency.
This product is built on top of underlying web-services that are being developed by the client's development team. CF felt it as a waste of his time to understand the APIs until it is fully developed by the client's team. So he proposed to go about mocking it with a random contract.
Code for i18n
ZD felt relieved. In her opinion, both the above tasks are likely unnecessary and is more a liability. She felt a strong need to understand the contract on integration-points to better appreciate overall business work-flow. She felt a strong need for collaboration here. But then this is her golden opportunity to help him understand her POV.

She tried having a conversation with CF to explain the need to talk to the teams building the web-services, to understand the API contract, stitch the workflow and then decide on the next steps. There was no agreement but fortunately both agreed to work on their ways to solving this problem for a couple of days to see where it takes them.

In a couple of days, CF with renewed vigor worked hard and completed the work sharing a demo of how well the product feature is completed. (But is the product feature really ready and done?)

In the same couple of days, ZD spent time going through the API contracts from the web-services downstream team, talking to them, understanding it and stitching a workflow on it. But shame she didn't write a single line of code. How dumb a developer can she be? Let's see.

After CF show-cased his demo, he teased ZD to showcase her piece of code work.

ZD politely nodded her head and responded that all that is needed to get the user story done was to call the corresponding APIs from the web-services per the contract. And that the need for any currency-converter service is not required, for it is taken care of by the underlying web-services being developed. She shared her lessons from collaborating with the other team, on how thin a margin the travel industry lives by, how every cent matters in every transaction and how employing 3-rd party service for currency-conversion hurt them, let alone having one more dependency component and unknown bugs in the process.

That is only a couple of lines of code taking i18n into account, in comparison to the 100s of lines of code that CF had written.

CF felt ashamed and angry at the same time. While he agreed to and deleted his lines of code and apply the new found learning, he did term this as exceptional circumstance and wanted ZD to comply to his expectations of working really really long hours. Phew, reality bites! 

For the rest of the story, I leave it to the imagination of the reader.

I would truly appreciate to hear from you sharing your experience under this theme. And don't you forget to like and share this blog post before you forget :P

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t