This post is a sequel to my earlier post — . 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. Embrace and Evangelize Zen Coding “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. And let us see how CF 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?) Sure the achievers are irrational. But the converse is not true. Emotions clouded CF’s 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. Aping the achievers.. Trouble, trouble and more trouble started to brew for the team. 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! Or is it plain old office politics? 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 This post is also reproduced in other platforms below: https://www.linkedin.com/pulse/tale-lone-zen-developer-among-code-factories-karthik-sirasanagandla/ http://blog.codonomics.com/2017/12/tale-of-lone-dev-among-coding-factories.html
