61–70 of 110 posts
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"
Same for cars, an unsafe product by definition.
Reads like a recipe intro.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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 d…
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 d…
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.
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 som…
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?"
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.
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!
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 som…
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 b…
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.