Dad and the ten commandments of egoless programming (2012)
blog.stephenwyattbush.com
blog.stephenwyattbush.com
1. Be patient. No matter what. 2. Don’t badmouth: Assign responsibility, not blame. Say nothing of another you wouldn’t say to him. 3. Never assume the motives of others are, to them, less noble than yours are to you. 4. Expand your sense of the possible. 5. Don’t trouble yourself with matters you truly cannot change. 6. Expect no more of anyone than you can deliver yourself. 7. Tolerate ambiguity. 8. Laugh at yourself frequently. 9. Concern yourself with what is right rather than who is right. 10. Never forget that, no matter how certain, you might be wrong. 11. Give up blood sports. 12. Remember that your life belongs to others as well. Don’t risk it frivolously. 13. Never lie to anyone for any reason. (Lies of omission are sometimes exempt.) 14. Learn the needs of those around you and respect them. 15. Avoid the pursuit of happiness. Seek to define your mission and pursue that. 16. Reduce your use of the first personal pronoun. 17. Praise at least as often as you disparage. 18. Admit your errors freely and soon. 19. Become less suspicious of joy. 20. Understand humility. 21. Remember that love forgives everything. 22. Foster dignity. 23. Live memorably. 24. Love yourself. 25. Endure.
One clarification I would make:
> 21. Remember that love forgives everything.
We all need to remember that forgiveness does not mean acceptance, or trust, or that it means you need to interact with someone. It means that you let go of a grudge.
This is an important note that took me a while to learn - forgiving is a gift to yourself, not the person you forgive.
"Give up blood sport" - Why? Did martial arts for 10 years, helped a lot with some other points in these list, especially the self-awareness and decency (humble-ness?). Or do i misunderstand this point?
"Live memorably" - That's straight up a wall tattoo quote, isn't it? /s
I think he is suggesting not to watch blood sports, that is to say not to spend a lot of time watching a human beat up another human for your enjoyment. Considering that it's Barlow I suppose the time it was written at was one where boxing was more relished as a viewer past-time in the U.S.
Try an experiment-- count how many people you saw killed by other people in the last week across all of the media you "consumed" (include the ones where the camera cut away at the last second)
The problem is I can deliver a lot and others can't so I quite often expect more of them since I expect them to deliver as much as me.
It is required not to be unfair, while it preferable to be reasonable.
You don't need to demand people work at your level, but you do need to demand that they work at a level that they can do if you are working at a higher level.
This all goes back to all the recent posts about lazy people in offices should be allowed to be lazy and unproductive.
Sure - within reason.
on edit: the demand that they work at a level that they can do only pertains when it is a task you care about - like child rearing. If one member of a couple is not able to contribute as much but does not contribute what they can this would create a rightful and detrimental resentment.
on second edit: changed if one couple to if one member of a couple otherwise didn't make much sense.
It would be best to realize that not everyone is lazy just because they won't deliver the same ammount of work units as you. We are all different, with different needs and handicaps.
1. Be patient. No matter what.
14. Learn the needs of those around you and respect them.*
1. Be patient. No matter what.
2. Don’t badmouth: Assign responsibility, not blame. Say nothing of another you wouldn’t say to him.
3. Never assume the motives of others are, to them, less noble than yours are to you.
4. Expand your sense of the possible.
5. Don’t trouble yourself with matters you truly cannot change.
6. Expect no more of anyone than you can deliver yourself.
7. Tolerate ambiguity.
8. Laugh at yourself frequently.
9. Concern yourself with what is right rather than who is right.
10. Never forget that, no matter how certain, you might be wrong.
11. Give up blood sports.
12. Remember that your life belongs to others as well. Don’t risk it frivolously.
13. Never lie to anyone for any reason. (Lies of omission are sometimes exempt.)
14. Learn the needs of those around you and respect them.
15. Avoid the pursuit of happiness. Seek to define your mission and pursue that.
16. Reduce your use of the first personal pronoun.
17. Praise at least as often as you disparage.
18. Admit your errors freely and soon.
19. Become less suspicious of joy.
20. Understand humility.
21. Remember that love forgives everything.
22. Foster dignity.
23. Live memorably.
24. Love yourself.
25. Endure.
Someone is going to need to explain to me why focussing on being happy is a bad idea. My historic view was "I'd rather chase being content and comfortable" as it's less of a sugary high and more of a stable base. However - I do not think that is what is being said here?
Maybe I'm wrong! Maybe our goals should be lofty and our own happiness tangential - but I don't buy it. If anything I think more people should think about things that make them happy, rather than focussing on abstract life goals that may or may not do that.
Related: "What is the meaning of existence? To stop searching for the meaning of existence" (paraphrased from somewhere).
I like Alan Watts' talk on 'discipline'[1]. tl;dr: "It's enormously important, especially for American people, to understand that there is absolutely no possibility of having any pleasure in life at all without skill."
[1] https://youtu.be/RNn1FB-Yn2M - put it in a background tab to avoid the silly graphics.
I have been Jesus like up until now, but that's only led me to end up with the shit end of the sick, managing people who do less than me , while making more money than me. I've been grinding so hard( for my own selfish gain) that when deadlines creep these people feel okay to slack, and turn in shit code, cuz they know me or of the other guys will pick is up. Meanwhile they get time to schmooze and work ok side degree or something and when promotions come around they get em cuz they are "more experienced" and now have better credential s.
I really think it's time to change my ways.
If however you find the same situation repeatedly at different jobs, then you're either 1) too critical, 2) your ego falsely wants to believe no one else is working as hard, or 3) would rather run your own show. Worst case scenario it's #3 because running your own show is hard, exhausting, fun, etc. and you'll never be happy working for someone else.
> You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
In my career, I have had to deal with other senior developers who would throw tantrums whenever I pointed out something problematic about their code.
Over the years, there's something all those people seem to have in common - they are stuck in an endless loop of making mistakes and refusing to learn from them.
I feel this sadly describes many partnerships, as well as great parts of society and humanity as its whole. But I am optimistic, that this can change, without a big catastrophic event needed for people to wake up.
I see most of the discussion involve preferences, practices and names, rarely api and architecture, even less bugs.
It's just a really negative attitude, you go to see the Sistine Chapel with someone, and the only thing they have to say about it is that there was a crack in the ceiling, and just repeat that the crack should be fixed. Would that not affect your experience?
No disagreement. But let's get pedantic:
The umbrella "you are not your code" would dismiss improvement as well. And praise.
Ok, so I am not my code. But if I don't learn from my mistakes my code will not improve.
I... I... I...
Anyway, I much prefer to reframe it this way:
Programming is a very intimate experience.
The same as creating art. It is the manifestation of your thoughts and opinions, small and large, put out in to the world. So sure, don't be offended by critique. But also remember to extend some grace when doing a review.
I don't see why you think this is the same thing.
Improvement in someone's coding skill is good from a business/colleague/project perspective. And from a "practice paid off" perspective. And positive feedback is always good to give, you certainly shouldn't only give negative feedback.
But you shouldn't get too attached to your code in either case. Today's good code is likely to be tomorrow's bad legacy code anyway. It shouldn't be an "intimate experience," programming for a company is an exercise in utility.
>The same as creating art. It is the manifestation of your thoughts and opinions, small and large, put out in to the world.
I respectfully disagree. This thought process is why other people are left holding the bag at 11pm on a Friday fixing the 'art' of someone else. Computer Science is a derivative of mathematics. Math is not art. Math IS beautiful, explicitly because it is NOT ambiguous or subject to interpretation. Math is right or wrong. It works or it is flawed.
Programming isn't art.
edit: forgot a >
I agree that data structures and algorithms are not art, but when combined in unique ways they create art.
I think the problem is the field is so new and these terms aren’t well defined.
Unless you consider anything less than perfect to be wrong, but that’ll just make nobody want to work with you.
You have twisted my words.
I equated it to art as the physical manifestation of something that represents someone's mental imaging / modeling.
> ... they are stuck in an endless loop of making mistakes and refusing to learn from them
I am probably overfitting to my own recent experience, but to me, while this could be a legitimate problem with the reviewee, sounds equally plausibly like a red flag on the part of the reviewer: someone who has settled into a set of "correct" answers and now sees other people not adopting their personal outlook on code as a failure to learn.
It is not a simple matter to (definitively, non-subjectively) find a 'problem' once the criteria become anything more nebulous than "does it produce the correct result".
There's an analogous situation I've noticed in more casual conversations: someone is describing a problem they have or a situation they're in, and the person they're speaking to keeps smugly offering "solutions" that only sound good because they haven't listened closely to the other person, took a superficial glance and assumed the issue was some common one and so offered a facile/common solution—and then don't understand why the other person isn't appreciative.
Real example #1:
I warn John Doe that his new endpoint will crash in a specific scenario. John Doe dismisses the warning since "it's not likely to happen in the wild". QA call it out soon after it's uploaded to our test environment. The error has a chain effect where it prevents them from testing other stuff.
Real example #2:
I warn John Doe that we just committed a flaky test to the develop branch, and I submit a PR to fix it. John Doe closes the PR since "for now we must accept tests fail in mysterious ways".
Soon after, Doe Johnson who works in another team is blocked by said test. He spends an hour or two coming up with the same solution I did.
In both cases we burnt money needlessly, because John Doe is too stubborn to accept our team's code is not perfect.
Obviously how and when you point it out matters. Like in the middle of a user demo.
"Why does it let me enter Feb 30th?" "Oh, Dave wrote the validation on that. What was your thought process on that one Dave?"
If you spot an issue, you raise it in the appropriate forum. This could be a one-on-one, feedback through whatever review system you use, or feedback in a review meeting if that's used. But calling it out in public, especially in front of a manager (more than one level above) or a customer is a great way to demonstrate that you are, well, an asshole.
Having to participate in a development team has made me a bit of a nicer person, as my default reaction is to blame. But that's completely inappropriate.
It sounds like "this one trick" but it truly is that effective.
This: Returning a string from this method is an error because ...
vs: You made an error by returning a string from this method because ...
The second one is more likely to make people defensive, IMHO.
These rules do not appear in this form or as a list of "10 commandments" in "Psychology of Computer Programming."
https://discourse.codinghorror.com/t/the-ten-commandments-of...
He seems to think these are, in part at least, quotes. And it's not just the "guy in the room" bit - when the commenter points out the book contains no 'commandments', Atwood doesn't say 'Oh, I just summarized it in list form'. He says he doesn't know where the text came from (?!). It's like the Atwood piece is itself derivative of something and it's not just the book and Atwood's own writing? Weird.
[0] https://www.techrepublic.com/article/the-ten-commandments-of...
This is the earliest google hit for "Ten Commandments for egoless programming".
Curiously, the author, Lamont Adams, does not explicitly state that the commandments are from the book. Maybe "I present The (Almost) Ten Commandments for egoless programming" means that it's a summary by Adams?
p.s. I just wrote to him now asking about this! Maybe the truth will surface...
He should have probably updated and corrected the blog post when someone pointed out his mistake to him in 2016. He probably still should.
There is an updated version from builder.com in 2004 that adds a 10th commandment that matches the Atwood list see https://web.archive.org/web/20040603055200/http://builder.co...
(uncovered via http://blogs.ugidotnet.org/geniodelmale/archive/2006/01/03/3... )
https://smoothspan.com/2010/09/15/jeff-atwood-is-not-quite-g...
https://www.skmurphy.com/blog/2015/07/26/planning-and-reflec...
Your hypothesis that he copied the points from somewhere else is certainly plausible, much of the phrasing in his "10 commandments" does not match Weinberg's diction although Weinberg did use the phrase "egoless programming."
As simple and important as this is for productive code reviews, I observed in my experience that it’s not as common a trait as one expects it to be. I can maybe attribute it to the stigma that is more deep rooted. In setups where rigorous code reviews are not norm, I notice, many if not most people, take the comments on their code as comments on self. Given how rampant this is at several workplaces, what ways/processes can be recommended to be adopted in such setups to have more productive, open and meaningful reviews and ease breaking the stigmas associated?
I also think it has to be part of a bigger strategy of egoless collaboration, and not hiring assholes.
There's a corollary to that: when you are working on someone else's code, don't restyle or re-architect to fit your vision. Don't even use your style or preferred architecture or design on your own additions; try to blend in with the rest of the code.
"THE DAWN PROJECT: Making Computers Safe for Humanity. We Demand Software that Never Fails and Can’t Be Hacked"
> Dan leads The Dawn Project. He knows more about developing software that never fails and can’t be hacked than anyone else. He has designed, managed, or directly implemented all The Dawn Project technology and he makes all the decisions regarding technology development. The managers below Dan have been steeped in this technology for over 20 years. They know far more about software development than the people below them in the organization chart. And so on down to the lowest level. But even at that level, we have nothing but Special Forces class programmers.
I... I can't find anything that's not simply boosting Mr. O'Dowd. This is clearly a B2B marketing website, not a technical resource. More power to them, but there's nothing here for outsiders.
It's also kind of concerning that software like CompCert and seL4 isn't mentioned anywhere. Academic work in software verification is making steady progress; it feels really dirty to pose as the lone group that cares about this stuff.
I don't really disagree with the ethical or factual material; there's just nothing actionable.
Same for cars, an unsafe product by definition.
Dad and The Ten Commandments of Egoless Programming (2012) - https://news.ycombinator.com/item?id=9203634 - March 2015 (75 comments)
I don't think psychology has ever ruled on personality being immutable either. I mean, if you're reluctant to change, you probably won't do. But wanting to change is surely at least half the battle!
They literally have Codes of Conduct now because some people don't know how to behave. They might be from a different culture, be differently mentally abled, etc... and need some guidance.
> 9 Don’t be “the coder in the corner.”
I understand the spirit of it, but I'm sure you can think of great programs written by one person. We had an example of that on the front page of HN yesterday, "Essence: Desktop operating system built from scratch" [3]. I'm currently learning Elm and that project has also had issues because the lone creator maintains tight control and doesn't handle feedback the way people would like him to, "Why I'm leaving Elm" [4].
So while I think Gerald Weinberg's book "The Psychology of Computer Programming" [5] is really great for interacting with your team (don't personalize, don't get defensive, or worse, offensive) you still need some ego to interact with people.
To me "Egoless programming" is more about getting yourself out of the way when coding, much like a basketball player loses him or herself in the game. If while I'm writing code, in the back of my mind I'm thinking "Oh, this is dumb, people are going to criticize this", like I have a backseat driver, then that's ego getting in the way.
The flow idea is to get your ego out of the way. That's the best egoless programming.
[1] https://en.wikipedia.org/wiki/Egoless_programming
[2] https://www.goodreads.com/book/show/66354.Flow
[3] https://news.ycombinator.com/item?id=29950740
[4] https://news.ycombinator.com/item?id=22821447
[5] https://www.google.com/books/edition/The_Psychology_of_Compu...
Presumably the realization that "my code is not me" could be a connection to more spiritual realizations like "my ____ is not me", but still it's not exactly minimizing the ego in the usual sense.
It took me even more years to master- because sure, not being in the corner is one thing, but getting out of it is another. It took a manager who listened to me and thrust me out to fix it.
This! But I learned the lesson as the person who took the idea and ran with it. The "coworker in the corner" got pissed off and snapped at me one day in front of a few people. I wasn't the only one to have the experience and got to have an awkward conversation with our manager about having to walk on eggshells around certain coworkers. The end result was I didn't care what he worked on. Code reviews? Approved, no questions. Your ideas? Awesome, but you're on your own for getting them into production, bye.
Don't be like that. You will suffer. You will know you are suffering too, when you compare yourself to your "lesser" peers who are getting more traction with their ideas while you become resentful.
Was common in the XX century to start having children at 20s, though.
Thanks so much for sharing it, and it was a great story.
Reads like a recipe intro.
If I have ego in it, I care more. I will do more, test more, refactor more, design better.
In other words, do not stop to care about the product, the customer, or the user. Stop caring about __your ego__, when other developers criticize you (in contrast to not caring when they criticize you)
I have also found that accepting all criticism from other developers makes me the submissive one. They are not always correct, pushing back when they are not matters a lot. Otherwise you get more and more absurd complaints.
Examples
• I don’t like this code style , I’ll post mine -> I’ll replicate the code style, maybe I’m missing something, and if not I’ll discuss it and propose my pref on next review
• reviewer suggested a change that would introduce an error, or something smelly -> treat it as welcomed feedback, make sure to perfectly understand the seemingly subtle difference in approaches, and with a thorough explanation.
Your general antidote against bad effects of ego is to convert the emotion into a genuine effort to demonstrate your point. It’s hard, and failure to explain properly backfire, but it’s probably visible in your work too, so it’s great reality check to measure where your ego or humility should be
I used to do that. The team dynamic went wrong every time. I ended up being the one people picked on the most, complaining about things they had no issue other people to do. And half the time it was not genuine code quality anything. It was asserting dominance or thinking I like it. The team dynamic is a thing. And all of this "be thankful" may be good advice for very aggressive people. I am not, for someone like me it is very bad advice.
When I was younger I read and followed advice like this. It was literally opposite of what I needed. Fact is, people react to what you do.
The thing that helped me was starting to push back on these systematically. Even when I feel bad about pushing bad. Or if it feels rude. And it really helped.
-----
If it is subtle difference in approach, then my way is as good as yours. If you want to change team approach, open it on meeting, get freaking consensus from all. Don't sneak it in my code reviews without any prior discussion. And do it for everyone, not just for the most accommodating person on team (which I am no longer and intend to never become again).
That being said, your default mode of conversion on this whole thread is confrontational, that facilitate self-cornering a lot, especially that leaving no open end in the conversation, forcing uneasiness. It's one burden to make sure the conversation goes well when one speaks.
I don't know you or your team, maybe nothing in this can help you, or maybe you are in a dysfunctional team, or even the fit is not good, but accepting things in a forever silence, without discussions, might really lead you into bad places. Leave some space in your mind for improvement, even if you're not ready right now, no reasons give up forever.
Also, it was repeated experience that has nothing to do with my current team. I am not in my first team and learned those lessons in the past ones.
And really, not every code review comment will improve you. Acknowledging that significant amount of them are pure preferences or even someone being wrong is not refusal to improve. And yet another category of them are half baked ideas. Just that, people give comments for variety of reasons and you have to manage them all.
When giving feedback, I try to do the same: Instead of just saying what is bad/wrong/smelly etc. and telling how to change the code I’ll also give the reasons why I think so.
The discussion afterwards should clarify the remark and I am open to the possibility that I am wrong. But you are right, at the moment I feel like currently I am giving up my approach/code too easily. This is partially because my colleagues are quite experienced and I’m very lucky to be able to learn from them.
Edit: Improved the punctuation.