Skip to main content

Deals You Can't Miss

1 Year Subscription

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.

My Popular Posts

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