src: google images A few days back I stumbled upon a tweet read something like below: src: twitter feed The above tweet is the theme of this post. And this theme is more of a birds-eye view of software product delivery, on the state of developer maturity from business stand-point. Easier : writing code The first step to becoming a programmer is obviously — writing code. It takes a lot of brain wrecks and deliberate practice to think and write code. No denial on that count. This effort from the developer is what makes him falls in deep love for “his” code. It’s sort of a love lock. What makes it easier then? Read on.. Harder : deleting code In typical life of software delivery functions there are umpteen occasions of going back and forth on features, workflows, fonts, colors and what not. Now that means lot of undoing what you did in the past. For a developer in love lock with her code, it is way too hard to even think of deleting her code, no matter what the reasoning is. It takes a lot of emotional discipline for a developer to let go of her emotions for her code contributions, and be willing to delete her code if that doesn’t make business sense at that juncture. And because this has got to do with the emotional quotient, this phase is indeed harder for a developer to overcome. Expert : not writing code in the first place Even as one disciplines her heart to detach herself emotionally from her code, there is a surprising side-effect. The human mind wires itself to think before coding the next time around, to ask relevant business questions, more as a self-defensive way. Self-safety is so instinctive by nature. With the passage of time, the mind matures from self-defensive style to appreciating the sanity behind asking relevant business questions before jumping into the coding. You become an expert when you realize that as a developer your job is to just not write more code but to first understand and then solve business problem by way of maintainable code. Of-course, if you’ve always been into stressful work-environments without taking time offs for RRI — Relaxation, Rejuvenation and Introspection — chances are you’d never mature to this phase. So if you have not reached this state yet, take a break for RRI. When you did reach this state, you’ve become a Zen Developer. Kudos to you! Master : convincing others to not write code But because software development is a team effort, your becoming a lone Zen developer wouldn’t help you long enough in your professional team-oriented journey. You have a crazy deal of a challenge now staring at your face. And this is to convince and uplift other developers in your team to attain this phase of maturity. Often, the success in this phase not only depends on your technical and soft skills, but also includes a variety of circumstantial economics. Lastly, if things don’t go well for you in your pursuit to help business by helping your fellow developers in your team, don’t you worry too much, for there is only so much within your control. What matters though, is to keep persisting and keep trying, to influence fellow developers in a variety of ways, for there are lessons waiting for us to be discovered. 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. Enjoyed reading this post? Express your appreciations by liking/clapping and sharing it to your friends/followers. Read the story by going to the post titled, . A tale of a lone Zen Developer among Code Factories This post is also reproduced in other platforms below: https://www.linkedin.com/pulse/embrace-evangelize-zen-coding-karthik-sirasanagandla/ http://blog.codonomics.com/2017/12/embrace-and-evangelize-zen-coding.html
