[HN Gopher] Dad and the ten commandments of egoless programming ...
___________________________________________________________________
Dad and the ten commandments of egoless programming (2012)
Author : grzm
Score : 73 points
Date : 2022-01-15 05:38 UTC (1 days ago)
(HTM) web link (blog.stephenwyattbush.com)
(TXT) w3m dump (blog.stephenwyattbush.com)
| abotsis wrote:
| #9 took me years to realize. Even more when you have an idea,
| share it, someone who's not in the corner takes it and runs with
| it. That experience is even more isolating because the immediate
| reaction is to just not share any more ideas.
|
| 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.
| dang wrote:
| One past thread:
|
| _Dad and The Ten Commandments of Egoless Programming (2012)_ -
| https://news.ycombinator.com/item?id=9203634 - March 2015 (75
| comments)
| mcguire wrote:
| " _Don't rewrite code without consultation. There's a fine line
| between "fixing code" and "rewriting code." Know the difference,
| and pursue stylistic changes within the framework of a code
| review, not as a lone enforcer._ "
|
| 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.
| skmurphy wrote:
| This article is a direct lift from
| https://blog.codinghorror.com/the-ten-commandments-of-egoles...
| the bulk of it is a verbatim copy of Atwood's summary without
| credit.
|
| These rules do not appear in this form or as a list of "10
| commandments" in "Psychology of Computer Programming."
| [deleted]
| 541 wrote:
| > You are not your code...
|
| 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?
| Mageek wrote:
| This is a great list - thank you. I learned a long time ago to
| not use "you" or similar in code reviews, as it is too easy to
| associate a critique of code with a critique of the coder.
| Changing "You should change this" to "This should be changed" or
| even "We should change this" can make a world of difference.
| wnolens wrote:
| Yes, the "we" in place of "you" is a meaningful difference I've
| noticed in code reviews.
|
| 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.
| merlincorey wrote:
| The power of "we" in not just Code Reviews but in
| Architecture, Design, and even Mentoring is quite strong in
| my experience.
|
| It sounds like "this one trick" but it truly is that
| effective.
| mkl95 wrote:
| I agree with all of it. I find commandment 2 to be the most
| enlightening one.
|
| > 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.
| hutzlibu wrote:
| "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.
| ChrisMarshallNY wrote:
| I absolutely _love_ that!
|
| Thanks so much for sharing it, and it was a great story.
| mwattsun wrote:
| I've been familiar with the concept of egoless programming [1]
| since early in my career (mid 80's). I was drawn to it because I
| was also attracted to Eastern philosophies about minimizing your
| ego and identity to be more aware and in the moment (mediation,
| mindfulness). There was another idea that I was drawn to at the
| same time "Flow: The Psychology of Optimal Experience" by Mihaly
| Csikszentmihalyi [2]. Egoless programming and flow became linked
| for me. I think for this reason I've always had trouble with 9
|
| > 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...
| vanusa wrote:
| Many timeless truths in this piece. Thanks for posting.
| watwut wrote:
| For me egoless programming means I just cease to care. I do it
| for money and I am glad when the day is over.
|
| If I have ego in it, I care more. I will do more, test more,
| refactor more, design better.
| metters wrote:
| The article does not mean being ego-less about the product, the
| customer, or the user. It means being ego-less about yourself
| as a developer, at least that's how I understand it.
|
| 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)
| watwut wrote:
| That is how I mean it too. For me it means not caring, as I
| said.
|
| 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.
| tuyiown wrote:
| Maybe by seeing it that way: imagine you are emotionally
| invested, <<caring>>, but the only thing that change is the
| way you interact with others, directly, or through the code
| you push.
|
| 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
| metters wrote:
| This is a good point and a perspective I neglected.
| Usually, when receiving feedback on my code I solve this by
| discussing the _why_ after receiving a _what_ as feedback.
|
| 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.
| amelius wrote:
| Sounds like a bunch of personality traits which are good to have
| in theory, but hasn't psychology taught us that you can't change
| personality even if you try very hard?
___________________________________________________________________
(page generated 2022-01-16 23:00 UTC)