Hacker News
3 months ago by thakoppno

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.

3 months ago by DoingIsLearning

In HN formatting you need newline for paragraph lists:

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.

3 months ago by Ntrails

> 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?

3 months ago by MagnumOpus

What he means is to avoid making hedonism your only goal in life, but to have some goal beyond that...

3 months ago by michaelbrave

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.

3 months ago by TOGoS

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."

[1] https://youtu.be/RNn1FB-Yn2M - put it in a background tab to avoid the silly graphics.

3 months ago by Shared404

I love this list.

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.

3 months ago by llamajams

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.

I really think it's time to change my ways.

3 months ago by rapind

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.

3 months ago by the_cramer

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

3 months ago by bryanrasmussen

>11. Give up blood sports.

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.

3 months ago by mellavora

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)

3 months ago by jvm___

Give up unnecessary conflict, or, give up conflict where the goal is to make the other person suffer or bleed.

3 months ago by 8bp

To be out for blood is to seek revenge. I read "Give up blood sport" as a caution against doing so.

3 months ago by southpawflo

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.

3 months ago by mkl95

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.

3 months ago by leetrout

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.

3 months ago by dgfitz

> 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.

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 >

3 months ago by reidjs

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.

3 months ago by Aeolun

Code exists on a continuum. It’s not correct or incorrect. It is better or worse.

Unless you consider anything less than perfect to be wrong, but that’ll just make nobody want to work with you.

3 months ago by jseban

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.

3 months ago by majormajor

> 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.

3 months ago by jseban

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.

3 months ago by westoncb

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.

3 months ago by snapcore

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.

3 months ago by sethammons

"Given the choice between my opinion and yours, I'll take mine. Got any data?" -former boss

3 months ago by mkl95

> 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.

3 months ago by hnfong

Sounds pretty bad if they didn't have a reason to not take the fixes. But ... where's the tantrum though?

3 months ago by hutzlibu

"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.

3 months ago by ourmandave

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.

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?"

3 months ago by kwertyoowiyop

“Making sure our QA Department is worth their budget, Steve.”

3 months ago by Jtsummers

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.

3 months ago by whatshisface

"Future-proofing for the introduction of leap months."

3 months ago by epolanski

Why's there so many devs at a user demo?

3 months ago by Mageek

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.

3 months ago by wnolens

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.

3 months ago by merlincorey

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.

3 months ago by Swizec

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.

3 months ago by wnolens

Lol that's pretty funny to view as a cultural difference.. in my experiences it's mostly unwillingness to take responsibility.

3 months ago by graton

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.

3 months ago by epolanski

I would never use "this should be changed", that would trigger 99% of devs with the same seniority.

3 months ago by skmurphy

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."

3 months ago by pvg

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?

3 months ago by skmurphy

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.

3 months ago by pvg

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:

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.

3 months ago by undefined
[deleted]
3 months ago by 541

> 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?

3 months ago by sverhagen

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.

3 months ago by mcguire

"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.

3 months ago by ianbicking

For a contrast on Egoless Programming: https://dawnproject.com/

"THE DAWN PROJECT: Making Computers Safe for Humanity. We Demand Software that Never Fails and Can’t Be Hacked"

3 months ago by Twisol

(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.

3 months ago by astrange

Surely fighter jet software makes things less safe if it "never fails".

Same for cars, an unsafe product by definition.

Daily Digest

Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.