This reminds me a lot of the advice of John Perry Barlow.
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.
> Avoid the pursuit of happiness. Seek to define your mission and pursue that.
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?
I'm not sure that happiness == hedonism? I would contend that most people spend too much time and effort chasing eg "being an expert in field x" or "getting a job with consultancy k" because they mistakenly think it's a good thing in and of itself.
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.
it's been my life experience that trying to be happy is like grasping sand, the harder you try the more it eludes. While living with a purpose, or for the sake of others it seems to come naturally.
Because happiness is not something you can 'have', it's something that happens. If you pursue happiness as a goal in itself, you may find that whatever you thought would give you happiness is not enough. On the other hand, if you have a mission and pursue that, you might not accomplish your mission, but happiness, or at least contentment that you are making progress, may happen in the process.
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."
I think my argument runs counter to this. Stop chasing things you think might give you happiness/contentment in some long run, as though it is some intangible second order effect.
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.
Uh okay. Pls tell me how to deal with, negligence, incompetence, lack of work ethic, complete disregard for other people's time and work.
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.
Honestly, some work environments are just shit. If you don't have a sizeable stake (co-founder), start looking around.
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.
Is there any detailed explanation on these points? I only find this exact quoted list in my searches. Seems that the original was also only a list of these points.
"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.
Yes, good thing we are past that and on to "game of thrones" or whatever the current nudity + violence trend is.
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 way I've understood 'blood sport' was that the particular sport never matters, the important parts are the viciousness and cruelty involved. so for me, martial arts = sports, and cockfighting = blood sport.
I like this list but I wonder when this type of gentleman behaviour is really applicable in today's world. You would probably just be stepped on in the workplace and relationships most of the time, you'd have to look really hard to find other people who are also following this high standard
It would be unfair to expect more from others than you can give, it would be reasonable to understand that not everyone can deliver at the same level.
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.
Why is it that someone that delivers 10x units of work calls everyone else lazy when they only deliver x units of work? Some people can deliver more for a while and then burn out, while some people can't or won't do either.
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.*
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.
I LOVE this frame of mind and I love this statement but it is usually only used in the negative alignment of expectations: don't take critique personally.
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.
>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.
Computer Games are art and games are one result of computer science. Can a science create an art? I guess color theory can explain why we enjoy colors. But the science came after the art.
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.
Good point about also extending some grace when doing a review. In my experience insensitive and unnecessary, pedantic and overall shitty critique is a much bigger issue and I'd rather see people push back more on it actually.
> The umbrella "you are not your code" would dismiss improvement as well. And praise.
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.
I agree. People are not robots, this is just silly. You'd never get a good effective team by taking this extreme stance that nobody ever has any feelings about their work.
I think I'd have nodded and read on a couple years ago when I'd only had thoughtful/well-informed/diversely-experienced developers review my code. I've learned since that it's also possible to have your code reviewed by someone without particularly deep understanding (nor awareness of what they lack), who would insist that responding to a critique of (what they think is) a problem is essentially being argumentative because they are certain they've already got the 'correct' answers (in a similar way that a first year philosophy student might think they've already got the answers).
> ... 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.
Yeah, the person who thinks a mistake is "you aren't writing the code my way" in itself is an ego trap. A lot of programmers get trapped in their viewpoint and think everyone should write code like them because it would make more sense to them if everyone did, when it isn't objectively better.
> 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.
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.
"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.
Another way to say this, which should be common sense, is don't call people out in public unless the intent is to embarrass them. Which is, of course, an asshole thing to do.
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.
I really don't understand the attitude of getting frustrated when people correct mistakes in your code review. I would so much rather have a coworker catch my bug in a cr than have it make it to prod. One is mildly embarrassing (if you tie your ego to your code) the other has an actual impact.
The overwhelming majority of comments I read, and I wish that was true just for my company, it applies to majority of OSS as well rarely if ever catch a bug.
I see most of the discussion involve preferences, practices and names, rarely api and architecture, even less bugs.
It's very hard to catch bugs in a code review. I manage it occasionally, but it's much more common that I'll be working on something else that touches on some piece of code that already passed review, and then I'll notice a bug, because I'm already thinking about how that module should work -- I have already loaded the relevant context into my head. Loading that context just to do a code review takes too long.
I very commonly catch inadvertent quadratic or even exponential algorithms in code reviews. The code normally will produce the right answer ... eventually.
It all depends on the delivery. Criticising someone's work is sensitive and you need to consider this. My number one problem is always that not enough positive feedback is given, you work really hard and make a great solution to a really important problem, give it to the team, and all you get back is someone aggressively and stubbornly picking on it for minor details.
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?
I agree in a way, but also disagree. Programming is probably the only job where you'd expect someone to be completely emotionally detached from your work. Everyone has feelings of pride and accomplishment for work that they have made, and you always need to consider this when you give criticism. It makes a world of difference if you review in a friendly and constructive way, or in a mean and aggressive way. There's no way people can just "not have any feelings" about work that they have put a lot of effort into.
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.
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.
One problem with "we" is when you work with people who aren't yet used to american corporatisms. You say "We should change this" and it doesn't get changed because you assumed they'll understand that you meant they should change it. But they think you just offered to change it for them and sit back waiting for you to do what you said you would.
Not so much a cultural difference as a language barrier. “We” is unclear. It diffuses responsibility. Makes it easy for everyone to think someone else is owning $thing.
Agree very much on this. Try to talk about the code, not the person writing the code. Talk about the code has errors, not that the programmer made an error writing the code.
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.
I assume you've read the book, what form, if any, do they appear in? I just skimmed through the text very superficially and didn't find anything that looked like these 'commandments'. Is the original Atwood post as iffy as this makes it seem or did I just miss relevant parts?
I have read the book several times, Atwood offers more of a artistic interpretation of Weinberg's insights. It's no accident that no quote marks appear in his version.
Thanks, I suppose I'll read it myself to get a better idea of the degree of interpretation involved. There's a comment on the Atwood article which makes a point similar to yours above and Atwood's reply is very odd:
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.
That's weird isn't it! In a quick search, I couldn't find any occurrence online of the phrase "Don't rewrite code without consultation", one of those commandments, earlier than Atwood's article. This[0] was the earliest other one I could find, from a few months after Atwood's, which says "What Weinberg wrote in that book was a set of guidelines for developers working in a team environment to keep their egos separate from their code. In fact, I think these 10 guidelines.." - but in the book, although Weinberg talks frequently about "egoless programming", I can't see any (isolated) principles or guidelines, much less a list of commandments. I can't find an online version of McCarthy's Dynamics of Software Development to check what's in that.
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?
I think a plausible explanation that fits all the bits and pieces is that Adams wrote this as a kind of riff of his own, inspired by the concept of 'Egoless Programming'. At some later point Atwood ran across some version of the 'commandments' list, thought they were quotes from the book and wrote his blog post. Thinking they were quotes, he probably didn't feel the need to cite where he found them. It's just a somewhat silly mistake, it happens - although it inadvertently spawned a mighty stream of Internet Wrongness.
He should have probably updated and corrected the blog post when someone pointed out his mistake to him in 2016. He probably still should.
No no, I understood what you meant! It's just that Atwood seems to think they are quotes, at least in part - the lack of clarity is entirely on his end. In fact, just about everyone on the internet who's ever mentioned these, with or without attribution to Atwood seems to think they are Weinberg quotes or at a minimum that these 'principles' are enumerated in the book. It looks, on the surface at least, a fairly major and uncorrected widespread misunderstanding.
Atwood's OODA Loop article at https://blog.codinghorror.com/boyds-law-of-iteration/ is another example of a widely shared misunderstanding of an important insight. Here he copies an article by Roger Sessions that distorts several of Boyd's key insights. See also
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?
It needs to be reinforced by the team, and not left up to the individual. A team or manager can encourage the behavior (even by just setting expectations at the time of hiring) and based on that, hopefully, some technical leaders are encouraged to lead by example.
I also think it has to be part of a bigger strategy of egoless collaboration, and not hiring assholes.
"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.
(EDIT: Oh, I whooshed myself pretty hard on this. "contrast on egoless", yes, absolutely >_<)
> 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.
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?
None of these are personality traits IMO, they're more rules/guidelines.
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!
It's simpler than that. When a cop pulls you over you have a mental script for how to talk to the police. When some dude in a bar bothers you then you have a different script. When you are at work discussing your code with people, Dad and the ten commandments are suggesting you rewrite your script so you can be more effective and behave in an acceptable manner.
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.
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.
Meditation is a process that works to block all "external" stimuli so that one can focus on the "self"... not sure how that works with minimizing the ego?
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.
#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.
>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.
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.
These are excellent skills and it would benefit both the developer and their team. In practice, it is very hard to follow them and emotions always overpower humans. The ability to keep them in control is everything.
He came home and his dad printed out a list of random programming tips to discuss with his not-a-programmer son who then remembered them enough to write a blog post about it?
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)
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.
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
> 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
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).
Ok, I didn't meant to introducing unsolicited advice, more like illustration to make sure that leaving ego didn't meant anything about caring or not, but mostly _how_ you do express your carefulness, especially converting into a constructive loop.
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.
Two of my comments were purely expressing how I feel. Third one was tldr of my past experiences. Only the part under lines seems confronting, which is not that much and hardly a whole thread. I am really unsure about what corner I am supposed to lock myself in with these.
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.
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.
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.