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 even to life itself.

Here are the 10 important lessons developers, project managers, and stakeholders would do well to keep in mind during the project lifecycle.

1. Understand and accept that you will make mistakes.
   Mistakes are rarely fatal in our industry, so find them early, before they make it into production, learn from them, and move on.

2. You are not your code.
   The point of a review is to find problems. Don't take it personally when one is found. Remember my words, “To err is only human, repeating it is what makes you either evil or insane”.

3. No matter how much "karate" you know, someone else will always know more.
   Seek and accept input from others. You can learn new techniques if you just ask. Always remember, it is never too late to learn.

4. Don't rewrite code without consultation.
   It is always a good idea to pair-up and have conversations on the code that you are tempted to re-write because you think it is bad. Your risks are much lesser if the code is backed by Unit tests. The least you can do is get it code reviewed before pushing code to main-stream branch.

5. Treat people who know less than you with respect and patience.
   Don’t be a bully. Seriously, just don’t be one. Grow up!

6. The only constant in the world is change.
   Things change, sometime for better and sometimes for worse. There are some things in your control which you can leverage to change things for better. Be the change that you wish for good. Also be willing to accept change for the overall good of the team.

7. The only true authority stems from knowledge, not from position.
   Don't wield a title like a badge of "rightness." If you want to be loved and respected in an egoless environment, cultivate knowledge. It may or may not lead to authority, but sure leads to love and respect from others.

8. Fight for what you believe, but gracefully accept defeat.
   Open culture is not being polite in the front and back-bitching in the back. Rise up, voice your concerns, be heard, and make your point of view by doing your homework, all with an intent to help and learn otherwise. You can’t accept defeat, if you carry the burden of your ego.

9. Don't be "the guy in the room".
   There are so many beer buddies, movie mates, cigarette companions, and what not, who can come together or fight fiercely on any non-professional topics by respecting each other; but definitely not discuss and debate openly, work related matters for team’s betterment. Just don’t be that guy in the room.

10. Critique code instead of people – be kind to the coder, not to the code.
    Pour your frustration on lifeless things instead of on emotional beings. Corollary, if someone were to show his frustrations on you instead of your work, be a little polite to him, discounting it as emotional down syndrome. I have been on both sides, and so will you sometime. Let us support one another and grow together.

Just to re-iterate, these commandments are still incredibly relevant. Put it to deliberate practice and with time they will bring out a better developer and co-worker in you.

You can get this book from Amazon.

Tensegrity In Microservices Architecture

Tensegrity or Tensional Integrity is also known in layman words as Floating Compression. In engineering field, it is the science of building a structure of isolated "compressed components" like bars that connected by "pre-stressed tensioned loose components" like cables or tendons. Any disturbance to a component in the assembly not just alters but brings down the entire structure.

Below is a picture of one such engineering model. Take a deep breadth and try to identify the connectors that help maintain the beautiful engineering model that you are witnessing.

Think of a table engineered by applying Tensegrity principles, like the one above. You may love looking at those crafty products but when it comes to buying it for your daily use, you think of  durability, don't you?

Tensegrity in software product/services is taboo, for it is not a deliberate engineering but a result of neglect or poor engineering. It's manifestation crops up so often in today's buzz-word architecture -- microservices. Every company dreams of building and connecting together a loose set of services as one application overlooking the cons in distributed architecture. Some of the examples of its manifestation are:

• Consumer service go down when its Producer service is unreachable.

• Consumer service go down when its Producer service is times out.

• Consumer service go down when its Producer service returns unexpected response.

I have voiced openly against startups going micro-services first architecture during my consulting days. I still warn them. I am a big advocate for monolith first and then tearing it down into microservices, after you got your domain modelling right and have well defined bounded context. And when you do break it down into microservices, it gives you enough leeway to accommodate your learnings from your short-comings in building distributed architectures. Tensegrity is the very basic thing, that you should watch out for and solve in your engineering microservices architecture by not re-inventing the wheel but by making use of available libraries that resolve these kind of issues.

Remember this as you refactor your monolithic architecture to microservices one,

Moving from monolithic architecture to microservices architecture is shifting complexity from your application to orchestration. Know your strengths and find your balance. 

Book Review: Red Yellow Green: What Color is Your Money?

What color is your money? by Noah Gift @ Lean Pub

The book titled, "Red Yellow Green: What Color is Your Money? The survival manual for gig workers and consultants" by Noah Gift is a good and engaging read. I personally have experienced and was diligent enough to escape many a potential predators. Actually, I have come across those predators that are super sweet in talk, popular (don't know if this is a paid for PR thing that is so common these days) for his other works than what he is doing (for example if he is a founder of a tech consulting company, he would have been popular in authoring a book or two), etc. Consulting is definitely a high-risk, high-reward endeavor. It is the same with doing a co-founding venture in a start-up. I would say this is THE MOST  IMPORTANT thing to watch out for during the course of your engagement. The author is in fact polite but firm in pointing this one out, which is my favorite of all. I wish the author cites an example or two of the things on how one could be deceived, to make it more sticky in the minds of a reader. I do think that the author needs to add more content on the later chapters in similar lines with some examples to make it more motivating and interesting.

All said, I would recommend you give this one a read, for it is worth your time and who knows, it might save you from the possible predator. An experience with a predator can be so unnerving or at the very least bitterly frustrating experience. I have always managed to escape this making Legal as integral part of my ventures.  

Lastly, this review is based on the rough-cuts of this work-in-progress book that was made available in O'Reilly's SafariBooksOnline.

My Experience With Expo For React Native

Note: I'm assuming Managed Workflow with Expo to leverage the max out of their services.

Expo : The Good

+ Great for boot-strapping react-native development for cross-platform mobile app development.

+ Possibly a good choice for PoCs to quickly showcase a concept.

+ We get to see the console logs of app in Expo's browser or terminal. This one is a big plus!

+ The documentation is good but could be better.

+ Expo's snack is the code playground in the web browser that will come handy when you want to try out its components from the web-browser and see how it appears in android/ios/browser, before you use it in your project. 

+ Leverage Expo platform for sharing the app in development to Business to get their feedback and adopt accordingly. Agile isn't it?

Expo : The Bad

- Limited choice of reusable React Components that has dependency on native components. Expo is getting better by the day in this, though!

- Their free build service is time consuming (you number in waiting queue could be over 20 with waiting time of over 20 minutes) and paid ones are way too pricey.

- Not all iOS and Android APIs are supported. That said, a great chunk of most used APIs are supported, except for things like Bluetooth, or WebRTC if that matters to you.

- No support for background audio with OS playback controls.

- Doesn't have FastImage incorporated into it and guess is working on its own version of FastImage, calling it expo-image. For the uninitiated, FastImage is to ReactNative, what Glide is to Android and SDWebImage is to iOS; it is a performant image loading and cacheing library.

Expo : The Ugly

- The app size is no less than 60 MB by default. You can reduce about 20 MB by using a property like `enableDangerousExperimentalLeanBuilds: true` in `app.json` for android; but that still keeps the app over 40 MB, which is ridiculous in my opinion. So where your app could do away with just 4 MB in plain Android development, using Expo is an epic failure.

- Expo by default adds way too many unwanted and unwarranted permissions as requirement to the app being published. For instance, it by defaults adds requirement for camera permission. In days of malicious malware being shipped with apps published even in Play-Stores, this will only raise the users' suspicion discouraging them to try the app.

- Connection to Expo dev server gets disconnected after some idle time hampering your hot-reload functionality. When this happens, you will have to reload the app. I experienced this quite often, and it is annoying.

My Verdict

Productivity gained in one thing, is lost in many other things by using Expo. Expo is beginners friendly entry to embracing React Native and may be do a quick PoC. Until things change for better with Expo..

When your Business says, "Tech ain't Rocket Science"

As a Tech-Leader, how do you respond when business smirks and dismisses your challenges in tech saying, "it ain't rocket science"? This post is my attempt of story-telling the complexity in Tech to the ruthless and impatient Business that dismisses it as just being CRUD and is no rocket-science. 

I am a tech-entrepreneur who has made bets on tech, business ideas and its intersection. I have failed for various reasons which is out of scope for this post. Now that introduction is to tell the Business that I understand where their frustration comes from. So I think it is important that they believe in Tech Leadership and its challenges. Not always can this leadership be right. It will go wrong in its bets from time to time. But, hell Business too gets things wrong from time to time, don't you? We should learn to see failure as not the end of a road but only a bend, albeit a hairpin bend at times that if not given due diligence, it can be catastrophic. So what is so crazy about the Tech World that the Rocket Science isn't having? My answer would be EVERYTHING! In Rocket Science the problem space is fairly well defined in that it is mostly science. In the Tech Space, it is oscillates between being an art at one point in time and being science in another circumstances. In Tech Space the choices are umpteen, the shines are mostly mirage and the pitfalls are hardly visible until experienced. Now that is the shortest way in which I could describe the challenges in Tech leadership. 

I can illustrate the tech landscape with my very own little experience in the realm of mobile app development. I had built a couple of Android applications as test of my ideas to understand its market. The Apple iOS ecosystem was a beast on its own and so was Android; each accelerating at a far greater pace in evolution than it is anticipated to be. Additionally the mobile ecosystem in itself had too many variables that you could hardly bet on. 

Take the tangent of, platform for developing mobile mobile applications -- a couple of years back it was native Android/iOS, or cross-platform mobile app development frameworks like Ionic, jQueryMobile, Adobe's PhoneGap, Sencha, Xamarin etc. Today, the very native platforms evolved so much that yesteryears app is just dated to be polite. Add to it Kotlin became popular in the native Android development space, because it is a much better language than Java in terms of maintainability and brevity. The iOS space witnessed Swift replacing Objective C. The community adopted these for good and this was fairly predictable.

But not always is the community adoption a predictable thing. And not always it is wise to go with the crowd, for it might turn out to be a pop-culture thing. This is sort of a high-risk high-rewards sort of thing, in the business parlance. Take the case of community adoption in the cross-platform mobile application development platforms/frameworks. The Facebook's introduction of ReactNative for cross-platform mobile app development became a game changer in this space. Frankly, I didn't bet on it and I was so wrong about it. With the community going ga-ga for it, I had dismissed it as pop-culture; call me a conservative for that and I take it. But wait, this time around, the community made a huge difference by coming up with a ton of open-source tools and components, that I would say had surprised Facebook too. Or Facebook perhaps was anticipating this development from its earlier success with open-sourcing ReactJS. The adoption rate and good produce, prompted Google to come up with Flutter wanting to disrupt this space. While ReactNative (aka RN is based on React.js), Flutter is based on Dart programming language. Taking a stop to reflect back, as things stand today, yesteryear's cross-platform frameworks (like Xamarin, Sencha etc) is just gone from the scene of relevance. Had you invested in those tools years back, you would have had to re-invest in learning the new ways of development in this space. This is tech; the crazy tech, where the craziness of the tech wave comes from the community, which literally can change directions of the wave. You got to ride the wave, float to flaunt, flop but float, fasten and flip, fence from fall, and fall but survive! 

I can share a similar story in the realm of backend development, devops, frontend, etc. but hope this story is more than enough (at least it worked for me in the past) to convince our Business about what it means to ride the Tech wave.

Tech is bloody hard to keep up with. Tell this story of evolution to anyone who is comparing it to Rocket Science. Tell them that Rocket Science don't change as much as tech do. In Rocket Science, you learn that there is so much more to discover in a supposedly closed domain. In Tech, you got to both learn and adopt within the constraints of time, opportunity, challenges and God damned people politics. The bad news is we do fail, and fail often. The good news is we can go past it learning our lessons.